I'm having a problem with the zigbee.parseDescriptionAsMap(description) command. When it parses the description below sent by a device I get the error
java.lang.StringIndexOutOfBoundsException: String index out of range: 70
The description sent to the parse command is
read attr - raw: 99380100004A01FF42220121BD0B03281E0421A84305219D0106240100000000082104020A21E54D641000, dni: 9938, endpoint: 01, cluster: 0000, size: 4A, attrId: FF01, encoding: 42, command: 0A, value: 220121BD0B03281E0421A84305219D0106240100000000082104020A21E54D641000
This is specifically the Xiaomi Leak devices so I'm not sure if its sending a non standard string. However other devices send similar strings that work fine.
An example of a working string is below. The only differences I really see are the size and value.
read attr - raw: 4B280100004201FF421D0121BD0B0328210421A8130521AC01062401000000000A21CC23641000, dni: 4B28, endpoint: 01, cluster: 0000, size: 42, attrId: FF01, encoding: 42, command: 0A, value: 1D0121BD0B0328210421A8130521AC01062401000000000A21CC23641000
Any ideas? Is the device just sending bad data?
I'm sure @mike.maxwell will chime in, but if I remember right when we talked about this, this is one more thing about the xiaomi devices that is non standard. They are sending back the wrong number of bytes in the message, ie saying that there are 70 bytes following and then only sending 69 bytes. and that is why these messages need to be parsed manually by the driver.
1 Like
That makes sense. When comparing the messages that is what I could see.
The only thing was that it only happened with the leak sensor I have when it process the button push. But I haven't seen it with any of the other devices.
The leak sensor is also the only one that sends a zonestatus too and that parsing method works just fine.
Thanks for the information.
Yeah, at the least with encoding 0x42 and probably 41, 43 and 44, basically all the variable length types.
The spec says that the first payload byte should represent the length of the subsequent data.
These guys included the length byte itself in the count...
When we made the change in 2.0.5 to deal properly with multi attribute variable length attribute reports we obviously had to observe and use this value to properly split the payload into its constituant attributes, hence breaking xaiomi.
1 Like
