First of all, thanks Anton for a fantastic job and a really good platform !
To my problem, I have an unknown device and have set it to port 5001 to see the HEX code, when I compare it with the protocol lists it fits in on the "Megasteak protocol".
My hex code
But then when I switch to port 5024 so ends the server receive data through the log file , when I then change back to port 5001 its starts receiving the hex data again. I have tryed with turn device off and on several times and reinstall traccar and tested with the old traccar 2.12 and 3.0 in which bonds with the same result. So in the end I tried to swap protocol gate and sat Megastek port to 5001 instead of 5024 and I got up this.
2015-08-14 11:25:12 INFO: [6573E3BA] connected 2015-08-14 11:25:13 DEBUG: [6573E3BA: 5001 < 22.214.171.124] HEX: 5354582c3836353036373032303433393039302c244750524d432c3137313031332e3030302c412c353931392e313431312c4e2c30313830342e313638312c452c302e3030302c3239342e34312c3134303831352c2c2c410d0a2c462c4e696c2d416c61726d732c696d65693a3836353036373032303433393039302c31312c39392e352c426174746572793d3835252c302c3234302c32342c383539382c423235453b31380d0a 2015-08-14 11:25:13 WARN: [6573E3BA] error - String index out of range: -18 - StringIndexOutOfBoundsException (... < MegastekProtocolDecoder.java:147 < *:345 < ExtendedObjectDecoder.java:39 < ...) 2015-08-14 11:25:13 INFO: [6573E3BA] disconnected 2015-08-14 11:25:13 WARN: [6573E3BA] error - String index out of range: -19 - StringIndexOutOfBoundsException (... < MegastekProtocolDecoder.java:160 < *:345 < ExtendedObjectDecoder.java:39 < ...)
Have been looking around here and found that more have had similar problems, but that they could be resolved with an update of the protocol just a few days ago. So I have made sure that I have the new updated protocol.
Thats makes me a little bit unsure is the loggfile only shows the device sends information when I use port 5001 or 5002, and nothing at all with the other ports. Has also tested with other devices that use other ports, and it works great.
Do you have any idea what I'm doing wrong ?
It looks like Megastek protocol, but the format is slightly different.
If it works with 5001, but not 5024 I suspect it might be using UDP protocol. Try port 5021 to see if you get any HEX data.
Hi Anton, and thanks for your quick answer - managed to get it to send to port 5024, but get this error message then.
2015-08-16 04:12:23 WARN: [4236AC21] error - String index out of range: -18 - StringIndexOutOfBoundsException (... < MegastekProtocolDecoder.java:147 < *:345 < ExtendedObjectDecoder.java:39 < ...) 2015-08-16 04:12:23 INFO: [4236AC21] disconnected 2015-08-16 04:12:23 WARN: [4236AC21] error - String index out of range: -19 - StringIndexOutOfBoundsException (... < MegastekProtocolDecoder.java:160 < *:345 < ExtendedObjectDecoder.java:39 < ...)
Suppose it means it is not a MegastekProtocol?
It is slightly different from the protocol that's implemented in Traccar. I need protocol documentation to add support for your device.
Thanks for your answer Anton.
I got exactly this from my seller: Protocol
And I think, unfortunately, it is that protocol traccar already supports.
My HEX data:
Message sent by your device doesn't match the protocol documentation that you provided. The main problem is with the "0d0a" delimiter in the middle of the message which breaks the frame decoding logic.
Okey, is it possible to modify the protocol so that it ignores the "0d0a"? https://github.com/tananaev/traccar/blob/master/src/org/traccar/protocol/MegastekProtocolDecoder.java
If it would be possible, how would this look like then - can I just only remove any piece of code in the file?
It is possible to ignore it in the protocol decoder, but before that we need to decode the frame. That's where the problem is. Current version decodes frames based on line break ("0d0a") and I can't think any way to solve this issue.
Could it be possibly to modify the incoming message (remove the extra odoa in middle) before passing it on to the decoder?
How would you know where a message starts and where it ends?
I might be completely out and floats, but could it be possibly to work with a complete message as a large string?
I guess I need explain in more details how the TCP protocol work. It's a stream protocol and messages can be broken or combined when they travel from device to the server. This means that we need a way to combine parts of the message into a single one on the server side if the message was broken into smaller pieces. Or if it was combine with other messages, we need to be able to split it into original separate messages.
To do that combining or separation, there is a special class called frame decoder. It takes a stream of data and on the output you have full original message. If the message was broken into pieces, it wait for all pieces to arrive and then combine it into one.
There are two main types of frame decoders out there. One is length based frame decoder and the other one is delimiter based. As name states, length based expect a length field at some fixed place in the beginning of the byte sequence and based on that value it calculates the side of the original message. Delimited based frame decoder breaks or combines messages based on a special character or sequence of characters in the stream.
In the case of Megastek protocol, it uses delimiter based frame decoder which expects "0d0a" delimiter.
I hope the issue is clear now. Let me know you have any questions or ideas on how to fix it.
Hi again Anton,
I decided to look at what is contained within the hex string right before the first "0d0a" delimiter.
It is this:
5354582c3836353036373032303431383836322c244750524d432c3137313434 342e3332392c562c353931382e393335312c4e2c30313830342e333436332c452c302e3132362 c302e30302c3233303831352c2c2c4e0d0a
Which is decoded into:
This message appears to contain the longitude and latitude, date/time and status according to megastek protocol.
Do you think that it would be possible to modify the megastek protocol in traccar to only read these properties, thus only injecting position, date/time and status into traccar?
The hardware engineer also suggested that we try using the semicolon before the checksum to close the message instead of the checksum itself. What do you make of that?
Thanks for your patience with me =)
I have implemented decoding of just GPS data. Let me know if you want me to provide a new build for testing.
Thank you so much!!
A new build for testing would really be appreciated.