h02 protocol - sos malfunctioning
You should check the source code to see which bit we are checking.
It is the same, bit 1.
And you are saying that the alarm is generated even if the bit is not set? It doesn't add up.
Yes, the bit is not set and alarm is generated. But for the bitmask, I am looking into the Status attribute of the position in Web-UI, I see it is not set for the SOS.
What I see in this log is the wrong date, location, speed and course. It means the reported location is invalid, but still don't know how Traccar is generating SOS from this? Any hint to test it with source code, how I can pass this data (which I received from device) to my local development instance? to debug and see how it is being interpreted and why Traccar sending the notification.
I am still struggling but no idea yet, any help will be appreciated.
I can explain the issue a little bit more as bellow:
The traccar decode the hex correctly while the device reports it by GPS, but when I put the tracker inside the room and it is trying to report it with WiFi, then this issue comes in.
I tried to manually assign the deviceId to longId in
H02ProtocolDecoder, withByteBufUtil.hexDump(buf.readSlice(8)).substring(0, 15);but that didn't help and all records filtered out as future.Here is the protocol documention from device manufacturer, I see a little difference in the hex length with those already implemented in H02.
I tried to log the
ByteBuffinH02ProtocolDecoder, I see the log results was a bit different with valid and invalid hex.
Valid Hex:
2022-01-26 14:44:10 INFO: [284680c8: h02 < 80.187.102.186] HEX: 2449001124971344002601225113750001006426475e002050ffffffffff001322000012380106010000000003d331
2022-01-26 14:44:10 INFO: ByteBuff: PooledSlicedByteBuf(ridx: 0, widx: 32, cap: 32/32, unwrapped: PooledDirectByteBuf(ridx: 32, widx: 47, cap: 64))
2022-01-26 14:44:10 INFO: [284680c8] id: 4900112497, time: 2022-01-26 14:44:00, lat: 51.22917, lon: 6.71079, speed: 2.0, course: 50.0
Invalid Hex:
2022-01-26 14:00:32 INFO: [363eff39: h02 < 80.187.118.126] HEX: 2449001124971300302601225113715701006425818e001021ffffffffff001425000012380106010000000003bed4
2022-01-26 14:00:32 INFO: ByteBuff: PooledSlicedByteBuf(ridx: 0, widx: 32, cap: 32/32, unwrapped: PooledDirectByteBuf(ridx: 64, widx: 94, cap: 128))
2022-01-26 14:00:32 INFO: [363eff39] id: 4900112497, time: 1999-11-30 07:01:00, lat: -5.18887, lon: -1.20829, speed: 3.0, course: 26.0
Even, if I translate above invalid parsed data manually, I will see the right date, while traccar parsed it invalid!
Manually extraction according to documentation: 24 4900112497 13:00:30 26-01-22 51137157 01 006425818e 0010 21 ffffffffff 001425000012380106010000000003bed4.
5. I tried to test the hex accross the unit tests, but it failed with bellow messages:
expected: UnpooledHeapByteBuf(ridx: 0, widx: 47, cap: 47/47) but was:UnpooledSlicedByteBuf(ridx: 0, widx: 32, cap: 32/32, unwrapped: UnpooledHeapByteBuf(ridx: 32, widx: 47, cap: 47/47))
Expected: UnpooledHeapByteBuf(ridx: 0, widx: 47, cap: 47/47)
Actual: UnpooledSlicedByteBuf(ridx: 0, widx: 32, cap: 32/32, unwrapped: UnpooledHeapByteBuf(ridx: 32, widx: 47, cap: 47/47))
java.lang.AssertionError: expected: UnpooledHeapByteBuf(ridx: 0, widx: 47, cap: 47/47) but was: UnpooledSlicedByteBuf(ridx: 0, widx: 32, cap: 32/32, unwrapped: UnpooledHeapByteBuf(ridx: 32, widx: 47, cap: 47/47))
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.traccar.protocol.H02FrameDecoderTest.testDecodeShort(H02FrameDecoderTest.java:19)
I am using latest traccar v14.5 as traccar server version.
Any help will be appreciated...
That's probably related to the message length. This issue has been discussed before.
I confirm that the issue was because of message length, the message length in my case was 47 which was different than the default one.
adding <entry key='h02.messageLength'>47</entry> solved the issue.
Thank you @Anton for your help.
Hello everyone,
From bellow log, I get a SOS event for each log-row (for each hex/binary data), while according to our device's manufacturer documentation, the SOS would be from the 1st bit of bitmask (the same which is implemented in Traccar), but I can see in the Status field of position in Traccar-UI that the bitmask is normal for all records and it is (4294967295). I also tested the standard SOS functionality of the device and it is working as expected, I mean, if there is SOS reported, it shows the bitmask as 4294967293 and Traccar also includes it in Position attributes and generate an event for it.
From Web-UI, in Notifications and Notification Type Alarm, only SOS is added and enabled for mentioned device.
So, I didn't get how Traccar generates SOS from this data?
Any idea that what I missing or what goes wrong?