You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The data I'm getting from the IM People Counter is only 13 bytes long which is resulting in a messed up decoding message as the decoder isn't using anything before byte 11.
Examples:
0B 01 35 00 00 00 00 00 00 00 00 00 00 (18:57)
00 01 35 00 00 00 00 86 00 00 00 00 01 (18:59)
0A 01 35 00 01 00 02 00 00 01 00 02 02 (19:15)
00 01 35 00 00 00 00 00 00 01 00 02 03 (19:30)
19:45 missed.
00 01 34 00 01 00 01 00 00 02 00 03 05 (20:00)
00 01 33 00 00 00 00 00 00 02 00 03 06 (20:15)
0A 01 33 00 01 00 03 00 00 03 00 06 07 (20:29)
0A 01 34 00 00 00 01 00 00 03 00 07 08 (20:30:04)
00 01 34 00 00 00 01 00 00 03 00 08 09 (20:30:37)
Clearly the last byte is a counter, so it looks very much like my data is missing 10 bytes from the start of the messages compared to what the decoder is expecting. I have no idea what the first byte is indicating.
I've modified the decoder we're using to the below which appears to work for us (battery voltage and counters are more sensible!)
var offset = 0; // 0r 10?
// Device stats
params.battery = ((bytes[offset + 1] << 8) | bytes[offset + 2]) / 100;
params.sensor_status = bytes[offset + 7];
params.payload_counter = bytes[offset + 12];
// There are separate counters for people travelling in each direction. These directions are marked on the units.
// There are also running total counts (one for each direction), useful if some packets are lost.
// Count of people travelling from counter_a to counter_b
params.counter_a = (bytes[offset + 3] << 8) | bytes[offset + 4];
params.total_counter_a = (bytes[offset + 8] << 8) | bytes[offset + 9];
// Count of people travelling from counter_b to counter_a
params.counter_b = (bytes[offset + 5] << 8) | bytes[offset + 6];
params.total_counter_b = (bytes[offset + 10] << 8) | bytes[offset + 11];
Not sure if enabling something on the device might caused that extra data to magically appear, or how to tell that the data is missing an offset - the documentation is very lacking and the "the units send well documented payloads that these decoders should handle." comment from the readme doesn't give any clue as to what the payload formats are, or any where to find the documentation for them, sadly just like the manual.
The text was updated successfully, but these errors were encountered:
Hi,
The data I'm getting from the IM People Counter is only 13 bytes long which is resulting in a messed up decoding message as the decoder isn't using anything before byte 11.
Examples:
0B 01 35 00 00 00 00 00 00 00 00 00 00 (18:57)
00 01 35 00 00 00 00 86 00 00 00 00 01 (18:59)
0A 01 35 00 01 00 02 00 00 01 00 02 02 (19:15)
00 01 35 00 00 00 00 00 00 01 00 02 03 (19:30)
19:45 missed.
00 01 34 00 01 00 01 00 00 02 00 03 05 (20:00)
00 01 33 00 00 00 00 00 00 02 00 03 06 (20:15)
0A 01 33 00 01 00 03 00 00 03 00 06 07 (20:29)
0A 01 34 00 00 00 01 00 00 03 00 07 08 (20:30:04)
00 01 34 00 00 00 01 00 00 03 00 08 09 (20:30:37)
Clearly the last byte is a counter, so it looks very much like my data is missing 10 bytes from the start of the messages compared to what the decoder is expecting. I have no idea what the first byte is indicating.
I've modified the decoder we're using to the below which appears to work for us (battery voltage and counters are more sensible!)
var offset = 0; // 0r 10?
Decoded message from 20:30:37
{
"battery": 3.08,
"bytes": "AAE0AAAAAQAAAwAICQ==",
"counter_a": 0,
"counter_b": 1,
"payload_counter": 9,
"sensor_status": 0,
"total_counter_a": 3,
"total_counter_b": 8
}
Not sure if enabling something on the device might caused that extra data to magically appear, or how to tell that the data is missing an offset - the documentation is very lacking and the "the units send well documented payloads that these decoders should handle." comment from the readme doesn't give any clue as to what the payload formats are, or any where to find the documentation for them, sadly just like the manual.
The text was updated successfully, but these errors were encountered: