Traccar (3.7) odd position/time issue
It is looks like it was last position. You also have to change "positionId" field in devices table for some existed position of your device.
It's not the last position:
select * from positions where deviceID=4 order by ID DESC limit 1;
| 139736 | h02 | 4 | 2016-09-12 16:19:49 | 2016-09-12 16:19:48 | 2016-09-12 16:19:48
And the wrong one was 139649
but in the devices table, the positionId seems indeed stuck at 139649
select * from devices where id=4;
+----+-------------+------------+---------------------+------------+---------+------------+ | id | name | uniqueId | lastUpdate | positionId | groupid | attributes | +----+-------------+------------+---------------------+------------+---------+------------+ | 4 | xxxxxxxxxxx | xxxxxxxxxx | 2016-09-12 16:19:49 | 139649 | NULL | NULL | +----+-------------+------------+---------------------+------------+---------+------------+
If I run "update devices set positionId=139736 where id=4;" and restart traccar, everything seems fine again, but why was positionId stuck at that wrong position?
Hello.
I have the same problem. I have two devices and only fail one that use the H02 protocol. If I search for the route it is ok. But the last position is in the middle of the sea and the date is 15-12-2018
Since it did not happen with 3.6 and I am not alone, this might be a regression in 3.7.
I need to see HEX message for the incorrect position to check what happened there.
Unfortunately, my logs were not in debug mode at that time. What I can do is switch the logs to debug mode and "hope" it happens again. But since I am now filtering invalid positions, I will have to check the logs manually.
The "good" news is that it seems it won't be too hard to reproduce as I already have a wrong one in my logs which were not yet in debugging mode again:
2016-09-13 06:37:25 INFO: [xxxxxxx] id: xxxxxxxx, time: 2010-01-26 13:04:37, lat: -16.84060, lon: -50.07085, speed: 140.0, course: 380.0
The bad news is that it's logged as valid. Which means filtering invalid waypoints isn't sufficient.
Actually, I even have multiple wrong ones. If everything continues like this, I should be able to send a HEX message by noon.
Hello.
I send you my debug:
2016-09-11 15:11:50 INFO: [xxxxx] connected 2016-09-11 15:12:00 DEBUG: [xxxxx: 5013 < 90.174.xxx.xxx] HEX: 2481605334181311591109163935634006002380838e026034ffffbbff000000000000000000d60317d424a16e 2016-09-11 15:12:00 INFO: [xxxx] id: xxxx, time: 2016-09-11 15:11:59, lat: 39.59390, lon: 2.63473, speed: 26.0, course: 34.0 ---> OK 2016-09-11 15:12:19 DEBUG: [xxxx: 5013 < 90.174.xxx.xxx] HEX: 2481605334181312181109163935729206002382036e023056ffffbbff000000000000000000d60317d40d526f 2016-09-11 15:12:19 INFO: [xxx] id: xxxx, time: 2018-12-15 06:34:18, lat: -11.15273, lon: -729.34334, speed: 820.0, course: 374.0 ---> Wrong, and this is the last update in devices table, but in positions table, is recorded ok the new positions. 2016-09-11 15:12:27 DEBUG: [xxx: 5013 < 90.174.xxx.xxx] HEX: 2481605334181312261109163935752906002382459e015003ffffbbff000000000000000000d60317d40d5270 2016-09-11 15:12:27 INFO: [xxx] id: xxx, time: 2016-09-11 15:12:26, lat: 39.59588, lon: 2.63743, speed: 15.0, course: 3.0
They look like pretty garbled in https://www.traccar.org/hex-decoder/
But to be fair, even my old logs are garbled there now
Anton, here is my investigation:
Looks like this device sends messages with non standart length=45, standart=32.
First message has marker 0x24 ($) at 43 byte, that confused frame decoder and it tried to decode
"24a16e2481605334181312181109163935729206002382036e023056ffffbbff" message. With lon: -729.34334 and future time.
Frankly, do not know what is right solution to fix it.
joseant and renaut, there was not changes in 3.7 that could cause such behavior, may be you have updated device firmware or they have such message length from the beginning?
I have not updated the firmware, I definitely did not see the behavior in 3.6 or former. And from my log, I can see it has always been like this. It sometimes send a short one, sometimes a long one. Also, it seems to do it on all my h02 devices.
2016-08-17 15:50:25 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2a48512c343230393931343239372c5631392c3133353130382c562c353034382e393431312c4e2c30303431352e383638372c452c3030302e30302c3030302c3137303831362c2c303033323437353837343134312c383933323033303030303037383734343538383f2c464646464642464623
2016-08-17 15:50:34 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971351171708165048941004004158680c000000fffffbffff000d000000177300ce1400000000a9
Now, maybe I never saw it because it never updated to a date in the future.
renaud,
Could you check only messages that started from 24, are they was 45 bytes length month ago?
Note: I had the logs set to info for some time, so only a subset of HEX logs are available.
grep 'HEX: 24' logs/tracker-server.log*
logs/tracker-server.log.20160817:2016-08-17 15:50:34 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971351171708165048941004004158680c000000fffffbffff000d000000177300ce1400000000a9 logs/tracker-server.log.20160817:2016-08-17 15:50:56 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971351391708165048941004004158680c000000fffffbffff0010000000177300ce1400000000aa logs/tracker-server.log.20160817:2016-08-17 15:51:18 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971352031708165048941004004158680c000000fffffbffff0012030000177300ce1400000000ab logs/tracker-server.log.20160817:2016-08-17 15:51:40 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971352231708165048941004004158680c000000fffffbffff0012030000177300ce1400000000ac logs/tracker-server.log.20160817:2016-08-17 15:52:02 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971352451708165048941004004158680c000000fffffbffff0013030000177300ce1400000000ad logs/tracker-server.log.20160817:2016-08-17 15:52:17 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971352581708165049077004004160080e034064fffffbffff0013050000177300ce1400000000ae ... logs/tracker-server.log.20160817:2016-08-17 16:18:11 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971418531708165039587004004210220e048091fffffbffff001b070000178d00ce14000000003c logs/tracker-server.log.20160817:2016-08-17 16:18:22 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971419031708165039583004004212340e048091fffffbffff001b070000178d00ce14000000003d logs/tracker-server.log.20160817:2016-08-17 16:18:33 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971419131708165039578004004214460e049091fffffbffff001b070000178e00ce14000000003e logs/tracker-server.log.20160817:2016-08-17 16:18:44 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971419281708165039572004004217710e049090fffffbffff0014090000178e00ce14000000003f logs/tracker-server.log.20160817:2016-08-17 16:18:55 DEBUG: [CDF19358: 5013 < 188.188.137.169] HEX: 2442099142971419381708165039575004004219860e048087fffffbffff000f080000178e00ce140000000040
One of my devices logged a very strange position state and I am unable to remove it from traccar DB, so now when I click on that device, I see it in the middle of the sea and following doesn't work anymore.
| id | protocol | deviceId | serverTime | deviceTime | fixTime | valid | latitude | longitude | altitude | speed | course | address | attributes | 139649 | h02 | 4 | 2016-09-12 16:05:36 | 2025-05-21 01:43:45 | 2025-05-21 01:43:45 | | -10.000031666666667 | -14.335 | 0 | 0 | 33 | NULL | {"power":-2,"alarm":"sos","ignition":false,"status":608307601,"ip":"213.137.13.4","distance":6991756.57,"totalDistance":7019030.12}I tried to issue "delete from positions where deviceId=4 and deviceTime>NOW()" and it deleted the entry, however traccar web interface still shows me the bad location data.
I restarted traccar (now with filtering rules against invalid positions) and I now cannot see the position of the tracker anymore at all.