0x31 Sensor Multilevel v5 CC - Parsing error


I have just notice that HE is not parsing the following CC, does anyone know what is wrong with this event?

parse() - Non-parsed - description: 'zw device: 3D, command: 3145, payload: 01 22 00 8F , isMulticast: false'

What driver are you getting this in?

1 Like

Context is king here.. If it is a community driver they likely didn’t specify what command class versions their driver supports.. which is important as the platform matures and supports newer command class versions..

If it’s a built in driver they need to know which one to fix it


command class 31 is sensor multilevel, however there is no command 45 for that class, so the parser is correct...

1 Like

Interesting.. what kind of device is this.. Because 45 is available in v11 and it is “heart rate lf/hf ratio”

I’m really curious now

the command isn't 3143 the command is 43 and the class is 31, the payload is meaningless as there is no such command 43 for command class 31...

SensorMultilevelReport which is what a device would send for a report is command 05


Yep.. See that now.. missed a byte wasn’t looking at the report packet format was looking at the sensor type list..



01000101 binary for hex 45
00000101 binary of hex 05

It looks like a single bit is flipped from what should have been sent.. But that is as far down this rabbit hole I'm willing to go..

1 Like

Thanks guys for having a look, the device is just a "Aeotec Water Sensor 6" and the driver is one that I have built. It's not a driver issue as the string I posted is literary that was send/received by HE..

I figured is was some kind us CC support or message issue, I figured this by simulating the event:

I'll keep an eye on this.

Thanks again,

I guess we've established that this isn't related to the problem now, but I just wanted to confirm my understanding of this: while behavior was briefly different in beta, my understanding is now that , say, a parse method for Basic v1 would also handle Basic v2 commands (if you don't have a method for v2) because they made the classes for newer versions subclasses of the classes for the older versions (or are otherwise using some Groovy magic to make it gracefully degrade/match if possible), though it's still a good idea to specify versions in parse regardless.

1 Like

Thanks for the tip, this was just to simplify the example the actual driver have the specific version for each CC: