Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data decoding / payload format problem #2

Open
BookSwapSteve opened this issue Oct 21, 2020 · 0 comments
Open

Data decoding / payload format problem #2

BookSwapSteve opened this issue Oct 21, 2020 · 0 comments

Comments

@BookSwapSteve
Copy link

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?

// 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];

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant