Decoding fault in Huabao (JT808) protocol
We would need to check the protocol documentation, not examples.
Here is one upload of the protocol: https://www.roadragon.com/uploads/JT808-protocol.pdf
If i read it correctly I can see in 8.6 Terminal registration response that it should respond with the "The serial number of the corresponding terminal registration message", as in my example.
It looks like its in all response-message I'v looked at in the protocol.
Here's the breakdown I've done manually:
Device to Server:
7e - header
0002 - message id
0000 - message body length
035350409856 - device id
039e - message serial number
11 - checksum
7e - footer
Server to Device:
7e - header
8001 - message id
0005 - message body length
035350409856 - device id
0000 - message serial number
039e - response serial number (matches message serial number)
0002 - response id (matches message id)
00 - result (success)
95 - checksum
7e - footer
As you can see, the response serial number matches the one from the device, so it is correct and valid response, according to the documentation.
Yes, but its not the 8001 response I having trouble with, its the 8100 as in my example. But I realized I marked the wrong part. I marked the messege id, but actually the response id is missing complete. Or am I decoding the response wrong?
2025-02-19 17:15:10 INFO: [T3369a3f9: huabao < 95.193.14X.XX] 7e01090000035350409856*039a*1f7e
2025-02-19 17:15:10 INFO: [T3369a3f9: huabao > 95.193.14X.XX] 7e810000070353504098560000*07e90213110f0ae37eIs not 039a supposed to be between the message serial number and the date?
7e header
8100 message id
0007 body lenght
035350409856 device
0000 msg serial (why is it always 0?)
*039a* response serial id should be here
07e9 2025
02 02
13 19
11 17
0f 15
0a 10 (2025-02-19 17:15:10)
e3 checksum
7e footerBut that's not what the device is getting stuck on. I'm looking at the log and it sends message 0002 in a loop, not 0109.
The 0002 is the heartbeat and that is working. The decoder is getting stuck on the 0210 every hour and disconnects the device. I just copied in a full hour to show that its repeating.
When it then connects again right away it sends the request to synchronize the time with the server which is the 0109, it tries 3 times and then stops asking.
So there is two problems.
- The server seems to disconnect the device on
0210. - When connected the device can´t grab the server time as the
8100is not responding with the id from the request.
The main problem is no 1. No 2 is not a big deal really I got it working by just adding the timezone-attribute to the device instead.
I just got the JT808 protocol from the manufacturer and it is a newer version i think: https://drive.google.com/file/d/130rs3VYKC7LxWBkRfjuXkzBRYJA7cYFP/view?usp=sharing
So maybe the 0210 is not supported yet in the decoder?
I found the https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/protocol/HuabaoProtocolDecoder.java and i seems that the message codes are in there. But it seams to be crashing on the 0210.
As for the problem no 2.
In this newer version of the protocol it says that 0109 is supposed to receive a 8109 response. In my log it looks like the server is sending a 8100 response , but it is formatted as a 8109, so maybe that's why the device is not accepting it?
I'm really not good with coding, and never used Java so I'm way over my head and really appreciate the help :)
Why would it send heartbeat every 10 seconds? I think you're trying very hard to find some issue on the server side and ignoring some obvious issue with the device.
Actually I see it's every 5 minutes, but it still doesn't make sense why device doesn't report any other data when heartbeat is working.
In general there seems to be some messages that are not supported currently, so probably the decoder needs to be updated to handle those.
The car is just parked. When moving it sends every 30 seconds and that is working as I should.
The function is that when the ACC is off it sends a heartbeat every five minutes and every hour it sends a status of the battery status.
Okey, so probably it’s a newer version of the protocol than what’s supported and that’s why the decoder gets an error and disconnects the device?
As the messages seem to be in the decoder already, should I post a Issue on github so someone with more skills than me hopefully can update the decoder to support them fully?
There are three options:
- Implement it yourself and send us a pull request
- Submit a feature requests and wait for us to prioritize it
- Sponsor the implementation
Hello
I'm slowly learning this awesome thing but I have one error that I think is related to a error of some sort in the decoder. Every hour when in hibernate the device sends a battery status message but the decoder seems to be having trouble reading it so it disconnects and connects the device every time. And also the time synchronization seems to be having problem.
From what I understand when the device is asking the server for something it expects a answer with the id of the question in it.
When the device requests server time (0109) the server responds with the time, but in the response it does not include the devices "question id" so the device asks 3 times total and then seems to give up.
Here are the logs.
And here is the reason i think the device is looking for the "question id" in the answer:
https://files.imettax.com/products/protocols/JTT808_Protocol_Message_Examples.pdf
so the answer from the server should in this case be (* is used to mark it out):
but it is, as you se in the logs:
This is as far as I have come to explore this and now I need help with the next step. It this a issue with my devices implementation of JT808 or is it the server decoding that needs to be updated/expanded?