Traccar (3.7) odd position/time issue

renaud6 years ago

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":"","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.

abyss6 years ago

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.

renaud6 years ago

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?

joseant6 years ago


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

renaud6 years ago

Since it did not happen with 3.6 and I am not alone, this might be a regression in 3.7.

Anton Tananaev6 years ago

I need to see HEX message for the incorrect position to check what happened there.

renaud6 years ago

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.

renaud6 years ago

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.

renaud6 years ago

Actually, I even have multiple wrong ones. If everything continues like this, I should be able to send a HEX message by noon.

joseant6 years ago


I send you my debug:

2016-09-11 15:11:50  INFO: [xxxxx] connected
2016-09-11 15:12:00 DEBUG: [xxxxx: 5013 <] 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 <] 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 <] 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
renaud6 years ago

They look like pretty garbled in
But to be fair, even my old logs are garbled there now

abyss6 years ago

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?

renaud6 years ago

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 <] HEX: 2a48512c343230393931343239372c5631392c3133353130382c562c353034382e393431312c4e2c30303431352e383638372c452c3030302e30302c3030302c3137303831362c2c303033323437353837343134312c383933323033303030303037383734343538383f2c464646464642464623
2016-08-17 15:50:34 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971351171708165048941004004158680c000000fffffbffff000d000000177300ce1400000000a9

Now, maybe I never saw it because it never updated to a date in the future.

abyss6 years ago


Could you check only messages that started from 24, are they was 45 bytes length month ago?

renaud6 years 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 <] HEX: 2442099142971351171708165048941004004158680c000000fffffbffff000d000000177300ce1400000000a9
logs/tracker-server.log.20160817:2016-08-17 15:50:56 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971351391708165048941004004158680c000000fffffbffff0010000000177300ce1400000000aa
logs/tracker-server.log.20160817:2016-08-17 15:51:18 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971352031708165048941004004158680c000000fffffbffff0012030000177300ce1400000000ab
logs/tracker-server.log.20160817:2016-08-17 15:51:40 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971352231708165048941004004158680c000000fffffbffff0012030000177300ce1400000000ac
logs/tracker-server.log.20160817:2016-08-17 15:52:02 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971352451708165048941004004158680c000000fffffbffff0013030000177300ce1400000000ad
logs/tracker-server.log.20160817:2016-08-17 15:52:17 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971352581708165049077004004160080e034064fffffbffff0013050000177300ce1400000000ae
logs/tracker-server.log.20160817:2016-08-17 16:18:11 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971418531708165039587004004210220e048091fffffbffff001b070000178d00ce14000000003c
logs/tracker-server.log.20160817:2016-08-17 16:18:22 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971419031708165039583004004212340e048091fffffbffff001b070000178d00ce14000000003d
logs/tracker-server.log.20160817:2016-08-17 16:18:33 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971419131708165039578004004214460e049091fffffbffff001b070000178e00ce14000000003e
logs/tracker-server.log.20160817:2016-08-17 16:18:44 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971419281708165039572004004217710e049090fffffbffff0014090000178e00ce14000000003f
logs/tracker-server.log.20160817:2016-08-17 16:18:55 DEBUG: [CDF19358: 5013 <] HEX: 2442099142971419381708165039575004004219860e048087fffffbffff000f080000178e00ce140000000040