Selfhosted Traccar seems to prevent my CJ720 (h02) trackers go to sleep
To be more precise: 'sleep' means my gps tracker shuts down the gps and puts the gsm connection to a low power state, but it still is connected to the network. The problem is, the gps tracker keeps sending data every 3-5 minutes, despite the 'sleep123456 shock' command. It doesn't do that with the standard settings in the tracker (pointing to gpscj.net tracking website).
With the standard gpscj.net website , the tracker only sends data when it's awoken by shock, so when the tracker is stationary for days, no data is ever sent during those days. With it sending data every 3-5 minutes, my data costs rise. It's like Traccar keeps the connection open, preventing the tracker going to sleep. PS GPS-Trace.com poses the same problem.
I have set the server.timeout to a very low value (5 seconds), that way i have been able to determine the tracker connect every 13,5 minutes, see the log.
I have a question, when it says h02 < 172.17.0.1] , is that an incoming connection (a connection originated from the device to traccar server), or outgoing connection?
2020-09-26 17:00:41 INFO: [f1d8ae33] connected
2020-09-26 17:00:41 INFO: [f1d8ae33: h02 < 172.17.0.1] HEX: 2a48512c373230313034323832302c56312c3136353331362c562c353135352e343435332c4e2c30303433362e373838322c452c3030302e30302c3030302c3236303932302c46464646464246462c3230342c30382c302c302c3623
2020-09-26 17:00:41 INFO: [f1d8ae33: h02 > 172.17.0.1] HEX: 2a48512c373230313034323832302c56342c56312c323032303039323631373030343123
2020-09-26 17:00:41 INFO: [f1d8ae33] id: 7201042820, time: 2020-09-26 16:53:16, lat: 51.92409, lon: 4.61314, course: 0.0
2020-09-26 17:00:42 INFO: [f1d8ae33: h02 < 172.17.0.1] HEX: 2a48512c373230313034323832302c56312c3137303034312c562c353135352e343435332c4e2c30303433362e373838322c452c3030302e30302c3030302c3236303932302c46464646464246462c3230342c30382c302c302c3623
2020-09-26 17:00:42 INFO: [f1d8ae33: h02 > 172.17.0.1] HEX: 2a48512c373230313034323832302c56342c56312c323032303039323631373030343223
2020-09-26 17:00:42 INFO: [f1d8ae33] id: 7201042820, time: 2020-09-26 17:00:41, lat: 51.92409, lon: 4.61314, course: 0.0
2020-09-26 17:00:47 INFO: [f1d8ae33] timed out
2020-09-26 17:00:47 INFO: [f1d8ae33] disconnected
2020-09-26 17:14:16 INFO: [16a64425] connected
2020-09-26 17:14:17 INFO: [16a64425: h02 < 172.17.0.1] HEX: 2a48512c373230313034323832302c56312c3137303935372c562c353135352e343435332c4e2c30303433362e373838322c452c3030302e30302c3030302c3236303932302c46464646464246462c3230342c30382c302c302c3623
2020-09-26 17:14:17 INFO: [16a64425: h02 > 172.17.0.1] HEX: 2a48512c373230313034323832302c56342c56312c323032303039323631373134313723
2020-09-26 17:14:17 INFO: [16a64425] id: 7201042820, time: 2020-09-26 17:09:57, lat: 51.92409, lon: 4.61314, course: 0.0
2020-09-26 17:14:17 INFO: [16a64425: h02 < 172.17.0.1] HEX: 2a48512c373230313034323832302c56312c3137303935372c562c353135352e343435332c4e2c30303433362e373838322c452c3030302e30302c3030302c3236303932302c46464646464246462c3230342c30382c302c302c3623
2020-09-26 17:14:17 INFO: [16a64425: h02 > 172.17.0.1] HEX: 2a48512c373230313034323832302c56342c56312c323032303039323631373134313723
2020-09-26 17:14:17 INFO: [16a64425] id: 7201042820, time: 2020-09-26 17:09:57, lat: 51.92409, lon: 4.61314, course: 0.0
2020-09-26 17:14:22 INFO: [16a64425] timed out
2020-09-26 17:14:22 INFO: [16a64425] disconnected
2020-09-26 17:28:05 INFO: [3520aba8] connected
2020-09-26 17:28:05 INFO: [3520aba8: h02 < 172.17.0.1] HEX: 2a48512c373230313034323832302c56312c3137323433362c562c353135352e343435332c4e2c30303433362e373838322c452c3030302e30302c3030302c3236303932302c46464646464246462c3230342c30382c302c302c3623
2020-09-26 17:28:05 INFO: [3520aba8: h02 > 172.17.0.1] HEX: 2a48512c373230313034323832302c56342c56312c323032303039323631373238303523
2020-09-26 17:28:05 INFO: [3520aba8] id: 7201042820, time: 2020-09-26 17:24:36, lat: 51.92409, lon: 4.61314, course: 0.0
2020-09-26 17:28:06 INFO: [3520aba8: h02 < 172.17.0.1] HEX: 2a48512c373230313034323832302c56312c3137323433362c562c353135352e343435332c4e2c30303433362e373838322c452c3030302e30302c3030302c3236303932302c46464646464246462c3230342c30382c302c302c3623
2020-09-26 17:28:06 INFO: [3520aba8: h02 > 172.17.0.1] HEX: 2a48512c373230313034323832302c56342c56312c323032303039323631373238303623
2020-09-26 17:28:06 INFO: [3520aba8] id: 7201042820, time: 2020-09-26 17:24:36, lat: 51.92409, lon: 4.61314, course: 0.0
2020-09-26 17:28:11 INFO: [3520aba8] timed out
2020-09-26 17:28:11 INFO: [3520aba8] disconnected
peewee67:
Can check how to view these logs on a traccar in a docker image on Synology .
Must you change any command ?
Also would appreciate if you share the Local Port and Container Port used.
I used 55000 for Local Port and 8082 for Container Port.
@pewee67: The h02 < 172.17.0.1 means the server (172.17.0.1) received from the device (h02), and the > means the device received from the server.
I find this confusing too, because for me it doesn't make sense neither as an arrow ->, nor in the unix-style read-from < or write-to > sense.
So just remember: it's the other way around of what it says. ;-)
@prime132: docker logs -f <containername>
Remeber that you will need to expose more than just the port for the webinterface, e.g. if you have an H02-protocol device you'll also need 5013/udp.
Actually h02 < 172.17.0.1 means that server received a message on port h02 from device with an IP address 172.17.0.1. So, it is an arrow.
Damn, i haven't looked at my logs in some time. You're right, i mistook the Docker bridge IP for the server, not the device. Now that i see the public IP in my logs, it's making sense again.
But hey, Cunningham's Law in full effect! :-D
Thanks for the replies. To sum it up, i haven't been able to get to the bottom of this and stopped using traccar for this reason.
I installed traccar in a docker image on my Synology , and connected my two chinese gps trackers (CJ720, h02 protocol). All working well, but i notice the trackers stay online and keep sending location data, despite not moving and despite 'sleep123456 shock' and 'sleep123456 deekshock' and 'nogprs123456' commands texted to the trackers. When the trackers were sending data to the chinese gpsj.net tracing website, they went to sleep after 5 minutes. How do ik make them go to sleep again? It's like Traccar is keeping them alive.