Neo Coolcam NAS-WR01ZE wall plug switch - kWh meter reports not parsed correctly

[m0rgano]

• OH Version: 3.0.0
• Binding Version (if SNAPSHOT, provide compile time as found on the filename in the console): 3.0.0

If the problem is associated with a device, please provide the following -:

• Device name: Neo Coolcam NAS-WR01ZE
• Device version: 6.4
• Link to [database]: https://www.opensmarthouse.org/zwavedatabase/1014
• If there is an XML being generted for the device (in the /userdata/zwave folder), please provide it. https://www.dropbox.com/s/7he52fq6zvjdojn/network_ea017cac__node_25.xml?dl=0

Debug Log for the relevant transaction:

2021-02-08 09:57:01.809 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Polling...
2021-02-08 09:57:04.361 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 04 00 19 0E 32 02 21 44 80 00 65 CB 00 3D 80 00 65 CB 90 
2021-02-08 09:57:04.364 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 0E 32 02 21 44 80 00 65 CB 00 3D 80 00 65 CB 
2021-02-08 09:57:04.365 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 0E 32 02 21 44 80 00 65 CB 00 3D 80 00 65 CB 
2021-02-08 09:57:04.365 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-02-08 09:57:04.365 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Application Command Request (ALIVE:DONE)
2021-02-08 09:57:04.366 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: resetResendCount initComplete=true isDead=false
2021-02-08 09:57:04.366 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: Incoming command class COMMAND_CLASS_METER, endpoint 0
2021-02-08 09:57:04.366 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: SECURITY NOT required on COMMAND_CLASS_METER
2021-02-08 09:57:04.367 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 25: Received COMMAND_CLASS_METER V3 METER_REPORT
2021-02-08 09:57:04.367 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 25: Meter: Type=Electric(1), Scale=kWh(0), Value=-21474575.89
2021-02-08 09:57:04.367 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveMeterValueEvent
2021-02-08 09:57:04.367 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_METER, value=-21474575.89
2021-02-08 09:57:04.367 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Updating channel state zwave:device:65ff760b:node25:meter_kwh to -21474575.89 [DecimalType]
2021-02-08 09:57:04.368 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Commands processed 1.

As you can see, the kWh meter report value is showing as a large negative number.

[cdjackson]

These sort of problems do occur occasionally and are normally caused due to corruption of data. There is really nothing that can be done to resolve this - it's not a binding issue as such.

[m0rgano]

It is happening consistently. It looks like the sort of behaviour when an Integer is being used to store the data somewhere rather than a Long.

[cdjackson]

Some of these devices have been known to have problems. It could be that the device device is sending the data corrupt.

You can see below that the data is invalid.

01 14 00 04 00 19 0E 32 02 21 44 80 00 65 CB 00 3D 80 00 65 CB 90

32 Meter 02 Report 21 Meter Type 44 Precision 2 decimal places, size 4 bytes 80 00 65 CB 4 bytes of data

800065CB is -2147457589 - with 2 decimal places, that is -21474575.89 as shown in the log, so this seems correct.

If we remove the high bit we have 65CB it would be 260.59. I don't know what you expect, but I believe that the top bit is probably not meant to be set.

[m0rgano]

Thanks for the analysis. I can probably fix that by manipulating the data myself.

This is happening on all my devices of this type so it seems to be a common problem. Is there any way of removing that spurious top bit in the binding, so that others can benefit? The number (kWh) should always be positive for this device.

[cdjackson]

There's not really any easy way to manipulate the data in this way. The binding tries to be generic rather than being built with specific bits of logic to work around bugs or whatever in devices which would make it hugely complex given we have about 1200 devices that are supported.

I think when we've had things like this in the past, people have used rules to filter this out - you'll find stuff on the forum about this. Normally it's more random, and I don't know if it's always this bit that's set if resetting the device might help. I know people have had various problems with these Coolcam devices.

[m0rgano]

OK I understand. I'll work around it myself and I'll endeavour to report it to Neo Coolcam.