I had the same problem and figured out what was happening.
The ZWave library makes an assumption about the format of all MULTIINSTANCEV2_ENCAP commands that is incorrect. This is fully expected, as documentation for ZWAVE protocols is awful. Fortunately, I found some good references and figured out the problem.
In the MULTIINSTANCEV2_ENCAP command handling part of Sensor.cs, message[13] is treated as a parameter type "key". According to the specs, when MULTIINSTANCEV2_ENCAP encapsulates a METER_REPORT, message[13] is really a set of bit flags indicating "Rate type" and "meter type". Since this index is not a key, Sensor.cs does not recognize it and treats it as generic.
EXAMPLE:
In the response of HEMv1 automated report of CLAMP 1:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
01 18 00 04 00 05 12 60 0D 01 00 32 02 21 74 00 03 28 7D 00 00 00 01 11 E9 52the byte at index 13 is "0x21". Sensor.cs treats this as a key, but according to specs, it is really a set of bit flags shown below:
0x21: 0010 0001
001` ```` => Rate Type = "Import (consumed)"
```0 0001 => Meter Type = "Electric meter"As a quick "hackish" fix, I just added an extra compare to the POWER parameter handling in Sensor.cs like below:
else if (key == (byte)ZWaveSensorParameter.POWER || key == 0x21 )
{In the long term, the ZWaveLib will need to be extended to support more of the protocol.
I found the "amazing" zwave docs below on GITHUB:
https://github.com/yepher/RaZBerry/tree/master/docsThe doc of interest is "SDS11060-7 Z-Wave Command Class Specification.pdf". It has everything we would ever need to decode ZWAVE!