Event Online/Offline
I don't think they are logged.
i don't know if can see image bellow.
There are so much lines here..
https://drive.google.com/file/d/0B9EmZsBPozxGaHRjaFd1S3BCelE/view
You can select event types in the report.
Yes I know but it is unnecessary information being recorded in the database. I thought maybe there was a way to avoid these logs. The table will grow without having to. 1 minute x 2logs x 100 devices = 200 entries per minute x 60 minutes x 10 hours = 120.000 records per day is huge amount of data logged.
Thanks in advance
There is no way to disable it at the moment. Why does your device disconnect every one minute?
I don't know. I've Ruptela ECO 4 Light connected to port 5046.
Sim Data usage is also high. Can be related?
My log seems like this:
2016-09-30 04:53:04 INFO: [C0929248] connected 2016-09-30 04:53:05 DEBUG: [C0929248: 5046 < 188.65.190.2] HEX: 0062000315bc7133fb4201000157ede1680000fab0a63017517e3c03762d0a13000006070c05011b17020003001c012020ad0086008700880082028f00071d6bbb1e0fe216000b1700158b00228900008300000341000ad58496000068b1af0002960e002533 2016-09-30 04:53:05 DEBUG: [C0929248: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 04:53:05 INFO: [C0929248] id: 868324027398978, time: 2016-09-30 04:52:08, lat: 39.12167, lon: -8.90864, speed: 0.0, course: 115.3 2016-09-30 04:53:14 INFO: [C0929248] disconnected 2016-09-30 04:54:19 INFO: [81748DD2] connected 2016-09-30 04:54:21 DEBUG: [81748DD2: 5046 < 188.65.190.2] HEX: 0062000315bc7133fb4201000157ede1a40000fab0a6d617517e5d03882d0a13000006070c05011b12020003001c012020ad0086008700880082008f00071d6bec1e0fe216000b1700158b003c8900008300000341000ad58496000068b1af0002960e003b5b 2016-09-30 04:54:21 DEBUG: [81748DD2: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 04:54:21 INFO: [81748DD2] id: 868324027398978, time: 2016-09-30 04:53:08, lat: 39.12167, lon: -8.90863, speed: 0.0, course: 115.3 2016-09-30 04:54:30 INFO: [81748DD2] disconnected 2016-09-30 04:55:01 INFO: [002D1486] connected 2016-09-30 04:55:03 DEBUG: [002D1486: 5046 < 188.65.190.2] HEX: 0062000315bc7133fb4201000157ede1e00000fab0a7d017517d3103c567d413000006070c05011b13020003001c012020ad0086008700880082038f00071d6bd11e0fe216000a1700158b003c8900008300000341000ad58996000068b1af0002960e00a152 2016-09-30 04:55:03 DEBUG: [002D1486: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 04:55:03 INFO: [002D1486] id: 868324027398978, time: 2016-09-30 04:54:08, lat: 39.12164, lon: -8.90860, speed: 0.0, course: 265.8 2016-09-30 04:55:12 INFO: [002D1486] disconnected 2016-09-30 04:55:24 INFO: [711CD0C4] connected 2016-09-30 04:55:25 DEBUG: [711CD0C4: 5046 < 188.65.190.2] HEX: 0062000315bc7133fb4201000157ede1fc0001fab0a7d017517d3103c567d413000007050c05001b14020003001c012020ad0086008700880082008f00071d6bae1e0fe416000a17000f8b001c8900008300000341000ad58996000068b1af0002960e008688 2016-09-30 04:55:25 DEBUG: [711CD0C4: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 04:55:25 INFO: [711CD0C4] id: 868324027398978, time: 2016-09-30 04:54:36, lat: 39.12164, lon: -8.90860, speed: 0.0, course: 265.8 2016-09-30 04:55:34 INFO: [711CD0C4] disconnected 2016-09-30 04:59:23 INFO: [52761212] connected 2016-09-30 04:59:24 DEBUG: [52761212: 5046 < 188.65.190.2] HEX: 00b9000315bc7133fb4201000257ede2e90000fab0a7c017517d3103c167d412000008070c05001b15020003001c012020ad0086008700880082008f00071d685c1e0fe216000b1700158b00008900008300000341000ad58996000068b1af0002960e0057ede2ea0001fab0a7c017517d3103c167d412000008050c05011b15020003001c012020ad0086008700880082008f00071d68361e0fe216000b1700158b00008900008300000341000ad58996000068b1af0002960e00c521 2016-09-30 04:59:24 DEBUG: [52761212: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 04:59:24 INFO: [52761212] id: 868324027398978, time: 2016-09-30 04:58:33, lat: 39.12164, lon: -8.90860, speed: 0.0, course: 265.8 2016-09-30 04:59:24 INFO: [52761212] id: 868324027398978, time: 2016-09-30 04:58:34, lat: 39.12164, lon: -8.90860, speed: 0.0, course: 265.8 2016-09-30 04:59:34 INFO: [52761212] disconnected 2016-09-30 05:00:05 INFO: [293BB3F2] connected 2016-09-30 05:00:07 DEBUG: [293BB3F2: 5046 < 188.65.190.2] HEX: 0110000315bc7133fb4201000357ede3120000fab0a8ec17517cff03c9213e12000506090c05011b15020003001c012020ad0086008700880082058f00071d6bc61e0fe216000d1700148b00288900008300000341000ad58a96000068b1af0002960e0057ede3140000fab0aae017517d2003d1157c12000806090c05011b15020003001c012020ad0086008700880082088f00071d6bd91e0fe216000f1700118b00028900008300000341000ad58e96000068b1af0002960e0057ede3150000fab0aba817517db603d10dac12000b06090c05011b15020003001c012020ad00860087008800820b8f00071d6bd91e0fe21600101700108b00018900008300000341000ad59096000068b1af0002960e0091b6 2016-09-30 05:00:07 DEBUG: [293BB3F2: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 05:00:07 INFO: [293BB3F2] id: 868324027398978, time: 2016-09-30 04:59:16, lat: 39.12164, lon: -8.90852, speed: 4.3, course: 55.0 2016-09-30 05:00:07 INFO: [293BB3F2] id: 868324027398978, time: 2016-09-30 04:59:17, lat: 39.12166, lon: -8.90850, speed: 5.9, course: 35.0 2016-09-30 05:00:07 INFO: [293BB3F2] id: 868324027398978, time: 2016-09-30 04:59:14, lat: 39.12164, lon: -8.90857, speed: 2.7, course: 85.1 2016-09-30 05:00:16 INFO: [293BB3F2] disconnected 2016-09-30 05:00:20 INFO: [B02AF44D] connected 2016-09-30 05:00:22 DEBUG: [B02AF44D: 5046 < 188.65.190.2] HEX: 0062000315bc7133fb4201000157ede3240001fab0b3dc175183a303c71ae011000006050c05001b15020003001c012020ad00860087008800820b8f00071d6b1f1e0fe216000d1700118b000e8900008300000341000ad5a996000068b1af0002960e0092e9 2016-09-30 05:00:22 DEBUG: [B02AF44D: 5046 > 188.65.190.2] HEX: 0002640113bc 2016-09-30 05:00:22 INFO: [B02AF44D] id: 868324027398978, time: 2016-09-30 04:59:32, lat: 39.12181, lon: -8.90829, speed: 0.0, course: 68.8 2016-09-30 05:00:31 INFO: [B02AF44D] disconnected
It looks like it disconnects after sending one report (like Teltonika). That's why you have this problem and also high data charges, because telcos round each connection or 1kb or 10kb, even though message is usually smaller. Is there a way to configure this behavior? If not, I would have to add an exception same as for Teltonika, to treat it similar to UDP protocols (no offline state).
Thanks Anton. I'm gonna ask ruptela support. Let me know.
Hi Anton,
So Ruptela support change my configs increasing their 'Link Timeout' parameter (3700s) to a value greater than 'Time without Engine' (3600s). Indeed improved but still seems high number of events online/offline.
Questions:
a) Ruptela GPS use DIN4 to Ignition Inputs. Is Traccar considering this changing? Online/Offline are related to this input or not?
b) Do you think will be even need to make such a change as the Teltonika?
Thanks in advance!
I want to add that disabling generating online/offline events is implemented and will be available in next release.
Ok thanks!
Engine Hours is always 0. I don't have events of Turn ON/OFF engine. Is this related?
Ruptela GPS use DIN4 to Ignition Inputs. Is Traccar considering this changing?
Regards
Yes, It is related. Engine hours used "ignition" attribute as well as Ignition event handler. If you see "ignition" row in State it should work. If not then should not.
There is no way at the moment to map inputs to some standard attributes.
Hi guys,
After change my configs increasing their ‘Link Timeout’ parameter (3700s) to a value greater than ‘Time without Engine’ (3600s) I've decrease number of sessions but I continue to high GSM Sim Data Costs consumption.
I contacted my supplier who gave me the following possibility
"According to screenshot bellow, taken from attached excel file, link got open 3 times within 28 seconds.
Device is not configured to work this way. Link Timeout is set to 3700s (1hours 2 minutes), meaning that device will keep link open for that period of time after sending data. Every time device sends data 'Link Timeout' timer will be refreshed and device will keep link open for another 3700s. In your device configuration Link Timeout 3700s is bigger than Time without engine 3600s and Time with engine 60s, this means that link will never be closed, because device will send data at least once per 3600s.
Most likely the problem is caused by the server in this case. Device is sending data to IP. Link can be closed from server side due to it's settings / configuration.
Alternatively link can be closed from GSM provider side, if they do not want to keep the link open when no data is being sent.
If you are convinced that problem comes from device itself, you can do a terminal log to make sure link is kept open."
Is there any possibility that the server is closing these connections?
Thanks!
It's possible if you have "timeout" or "resetDelay" configured on the server.
Hi,
Is there a way to turn off the online/offline log events?
I've these events every minutes and all the other events are important for me.
Thanks,
Bruno