Negative lux value

Add-ons Bindings
1

@chris

Is this a bug in the processing of the luminance report or a bug in the device firmware (Neo Coolcam 5in1 sensor NAS-PD07Z) or is it caused by a gap in the Z-Wave specification (signedness)?

grafik
grafik1211×548 42.5 KB 

2021-11-05 13:30:28.363 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=56, callback=0, payload=00 38 06 31 05 03 0A DB A0 
2021-11-05 13:30:28.364 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=56, callback=0, payload=00 38 06 31 05 03 0A DB A0 
2021-11-05 13:30:28.364 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-11-05 13:30:28.364 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 56: Application Command Request (ALIVE:DONE)
2021-11-05 13:30:28.364 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 56: resetResendCount initComplete=true isDead=false
2021-11-05 13:30:28.365 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 56: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
2021-11-05 13:30:28.365 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 56: SECURITY NOT required on COMMAND_CLASS_SENSOR_MULTILEVEL
2021-11-05 13:30:28.365 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 56: Received COMMAND_CLASS_SENSOR_MULTILEVEL V10 SENSOR_MULTILEVEL_REPORT
2021-11-05 13:30:28.365 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 56: Sensor Type = Luminance(3), Scale = 1
2021-11-05 13:30:28.365 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 56: Sensor Value = -9312
2021-11-05 13:30:28.365 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 56: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2021-11-05 13:30:28.365 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 56: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=-9312
2021-11-05 13:30:28.366 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 56: Updating channel state zwave:device:b1ca481a57:node56:sensor_luminance to -9312 lx [QuantityType]
2021-11-05 13:30:28.367 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 56: Commands processed 1.
2021-11-05 13:30:28.367 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 56: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6794006c.
2021-11-05 13:30:28.367 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-11-05 13:30:28.367 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-11-05 13:30:28.367 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-11-05 13:30:28.368 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2

From a quick look, it seems that the binding is decoding this ok - the top bit of the value is set, so it is a negative number. I would say that this is an incorrect implementation in the device.

I don’t think there’s a “Gap” in the spec - the spec is quite clear that this is a signed value -:

image
image1250×428 33.1 KB

This statement is still there for the latest version of the command class.

I was thinking this could be solved in the converter with an option there, but that’s not so easy as it also needs to know the size of the original value (ie it’s two bytes long here) in order to know how to transform it. We could pass that through as well, but maybe the easiest solution is to simply use a transformation - if it’s less than 0, add 65535.

3

Size (3 bits)
This field is used to indicate the length in bytes of the Sensor Value field.
This field MUST be set to 1, 2 or 4.

So the device manufacturer should have used 4 bytes for the luminance value … Clearly an implementation error on the manufacturer’s side.

4

Yes, I guess either 4 bytes, or less precision to make it fit into a signed 2 byte value.

5

An implementation of a workaround: