What version of Traccar are you using?
It's a known issue with H02 protocol. I would need some server logs with the problem to investigate the issue further.
Hi Anton,
I investigated it further and found, devices send alarm event when this thing happens and most the time positionid and lastupdate fields in devices table become null. But in some cases, these fields doesn't become null but have some position id and never gets updated after that particular position id (although positions table gets updated with new position info after certain interval) .
Possible solution,
Your log file is more than 15 MB in size. Please provide a timestamp and device id to look for incorrect coordinates there.
Hey guys, was this issue resolved? I am having a similar problem on the H02 protocol
The problem is with message length. The solution is to specify it in the config file. It has been discussed in many other forum threads.
I fixed message length in config file this way<entry key='h02.messageLength'>45</entry>
but no luck, still I am getting devices in random continents and whenever this thing happens all of the devices disappears from the map, I have to restart the traccar service every time to show devices on map.
I need to see logs.
@Anton,
Here are some logs, all message decoded using https://www.traccar.org/hex-decoder/
2017-03-14 09:53:11 DEBUG: [2B142C20: 5013 < 42.111.23.135] HEX: 34323130313335373933 2017-03-14 09:53:23 DEBUG: [2B142C20: 5013 < 42.111.23.135] HEX: 2442101357930423321403173034921006076529640e000000ffffdfffff0002 2017-03-14 09:53:23 INFO: [2B142C20] id: 4210135793, time: 2017-03-14 09:52:51, lat: 30.58042, lon: 76.88315, speed: 3.0, course: 1.0
if last message was invalid, where this speed and other info coming from?
seems to be Working
2017-03-14 09:53:23 DEBUG: [648F63C1: 5013 < 106.67.189.187] HEX: 2442101357830423311403173026324006075419330e027074fffffbffff0068 2017-03-14 09:53:23 INFO: [648F63C1] id: 4210135783, time: 2017-03-14 09:53:16, lat: 30.43770, lon: 75.69713, speed: 24.0, course: 52.0 2017-03-14 09:53:21 DEBUG: [90D0BA28: 5013 < 42.111.30.165] HEX: 2442101424700423291403173035803006075515060e000000fffffbffff0049
seems to be invalid but decoding fine
2017-03-14 09:53:22 DEBUG: [21D189EC: 5013 < 101.57.254.211] HEX: 2442101350880423301403173139431006074509600e029151ffffdfffff0017 2017-03-14 09:53:22 INFO: [21D189EC] id: 4210135088, time: 2017-03-14 09:52:52, lat: 31.66080, lon: 74.84707, speed: 8.0, course: 147.0 2017-03-14 09:53:27 DEBUG: [A3F2531B: 5013 < 42.111.20.244] HEX: 2442101424600423361403173035797006075514270e000000fffffbffff00190d0000b7e00194580000000013 2017-03-14 09:53:27 INFO: [A3F2531B] id: 4210142460, time: 2017-03-14 09:53:36, lat: 30.59662, lon: 75.85712, speed: 0.0, course: 0.0 2017-03-14 09:53:28 DEBUG: [A3F2531B: 5013 < 42.111.20.244] HEX: 5800915025550423371403173035797006075514270e000000fffffbffff0014
all good
2017-03-14 09:54:01 INFO: [08743BDC] connected 2017-03-14 09:54:01 DEBUG: [08743BDC: 5013 < 101.63.181.32] HEX: 2a48512c343231303133353830312c56312c3034323431302c412c333034322e373130382c4e2c30373631312e373832362c452c3030302e30302c3030302c3134303331372c464646464642464623 2017-03-14 09:54:02 INFO: [08743BDC] id: 4210135801, time: 2017-03-14 09:54:10, lat: 30.71185, lon: 76.19638, speed: 0.0, course: 0.0 2017-03-14 09:54:03 DEBUG: [08743BDC: 5013 < 101.63.181.32] HEX: 2a48512c343231303133353830312c56312c3034323431312c412c333034322e373130382c4e2c30373631312e373832362c452c3030302e30302c3030302c3134303331372c464646464642464623 2017-03-14 09:54:03 DEBUG: [08743BDC: 5013 < 101.63.181.32] HEX: 2442101358010424121403173042710006076117820e000000fffffbffff004a
suspicious
2017-03-14 09:54:07 DEBUG: [A666A65F: 5013 < 49.14.18.177] HEX: 34323130313639353931 2017-03-14 09:54:08 INFO: [A666A65F] id: 4210169591, time: 2017-03-14 09:53:16, lat: 31.39028, lon: 77.19912, speed: 5.0, course: 345.0 2017-03-14 09:54:22 DEBUG: [A666A65F: 5013 < 49.14.18.177] HEX: 2442101695910424291403173123552006077117860e015069fffffbffff0003 2017-03-14 09:54:22 DEBUG: [A666A65F: 5013 < 49.14.18.177] HEX: 5800107762380424301403173123553006077117910e015071fffffbffff0004 2017-03-14 09:54:23 INFO: [A666A65F] id: 4210169591, time: 2017-03-14 09:54:29, lat: 31.39253, lon: 77.19643, speed: 15.0, course: 69.0 2017-03-14 09:54:27 DEBUG: [A666A65F: 5013 < 49.14.18.177] HEX: 2442101695910424341403173123555006077117990e005071ffffdfffff0005
I think things will be fine if every message has one of these lengths
2017-03-14 09:54:01 DEBUG: [08743BDC: 5013 < 101.63.181.32] HEX: 2a48512c343231303133353830312c56312c3034323431302c412c333034322e373130382c4e2c30373631312e373832362c452c3030302e30302c3030302c3134303331372c464646464642464623
or
2017-03-14 09:53:23 DEBUG: [648F63C1: 5013 < 106.67.189.187] HEX: 2442101357830423311403173026324006075419330e027074fffffbffff0068
All of my devices are from the same vendor and are connected to port 5013
Here is link to device http://www.lk-gps.com/e_productshow/?18-LK210-GPS-tracker-18.html
This issue must be addressed, let me know if you need anything else to investigate it further. I can configure my device to one of your testing server if you want.
I have removed your decoded lines. It doesn't make any sense to decode binary messages.
The problem is with this message:
2017-03-14 09:54:07 DEBUG: [A666A65F: 5013 < 49.14.18.177] HEX: 34323130313639353931
It doesn't comply with protocol. It's likely a device firmware issue.
but can't we just ignore such message by measuring the length of messages, if the length of the message is less than or way greater than usual messages then can't we can ignore such messages and halt further decoding and other stuff?
How would you even know where the message start and ends?
Wrong blog section please ignor
Hi, I have the same problem with the H02 protocol. If I look in the client I see that the last update of the device was on 2026-12-13 16:03.
Strange.
My log file also contains a lot of Debug lines with a long HEX value behind.
Isnt't it possible to ignore the debug lines if these cause the problem?
You should search on the forum. The problem with H02 has been discussed many times before.
Hi All,
I have 100+ devices of the same configuration and all of them are connected through port 5013 ( H02) protocol.
Here are my filtering and other settings from the configuration file.
Everything seems to be working fine except this issue, some devices suddenly jump over the continents and keep showing the wrong location on the map. However, device location never gets updated on the map but it does get new location after every interval. I confirmed this thing by checking database, lastupdate and positionid field in devices table never gets updated after wrong info (jump happens) but device positions keep updating in positions table.
Here are few screenshots to explain little more about the problem I am talking.
To solve things manually, I am running this query in database (after identifying devices with wrong info)
update devices set lastupdate=( select servertime from positions where deviceid=29 order by id desc limit 1) , positionid=(select id from positions where deviceid=29 order by id desc limit 1) where id=29
This query does update fields in devices table but even after running this query, device location is not getting updated on the map. I have to restart traccar service to update device position on map.
How can I configure traccar server to ignore these invalid locations ( I have already added distance filter but this filter is not seems to be working) anyone else solved this kind of problem?