Any chance of sanity checking in zWave stats?

It would be nice if we could clamp acceptable values… And throw away obviously bad ones… e.g. Temperatures < -273.15 deg C… Configurable would be nice, since I’m pretty sure we won’t see temps < about -20 in the SE of England…

2018-10-13 21:46:34.887 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2018-10-13 21:46:35.940 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 0E 06 31 05 01 22 80 00 68
2018-10-13 21:46:35.968 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0&lt;&gt;128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 06 31 05 01 22 80 00
2018-10-13 21:46:35.970 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 06 31 05 01 22 80 00
2018-10-13 21:46:35.972 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 14: [WAIT_REQUEST] priority=Poll, requiresResponse=true, callback: 19
2018-10-13 21:46:35.973 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:PING)
2018-10-13 21:46:35.975 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
2018-10-13 21:46:35.976 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY not supported
2018-10-13 21:46:35.978 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Received COMMAND_CLASS_SENSOR_MULTILEVEL V5 SENSOR_MULTILEVEL_REPORT
2018-10-13 21:46:35.979 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 14: Sensor Type = Temperature(1), Scale = 0
2018-10-13 21:46:35.981 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 14: Sensor Value = -3276.8
2018-10-13 21:46:35.982 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2018-10-13 21:46:35.984 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_MULTILEVEL, value = -3276.8
2018-10-13 21:46:35.986 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:783409c6:node14:sensor_temperature to -3276.8 °C [QuantityType]
2018-10-13 21:46:35.989 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2018-10-13 21:46:35.990 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@14302d9.
2018-10-13 21:46:35.992 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2018-10-13 21:46:35.994 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2018-10-13 21:46:35.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-10-13 21:46:35.998 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.

Temperatures of -3000 or so offend me…

I think OH just broke the laws of thermodynamics!!! Time travel, here we come!!

Unfortunately, occasionally devices send crazy values - and while I agree that -3000 is something that would be easy to remove, where do we draw the line? is -273 a good limit, or maybe -100, or something else? This could really add a lot of complexity to bindings if they have to add this sort of configuration and sanity checking.

We have seen that some devices will send values that are “ok” if applied to a simple limits check. Eg a temperature reading in the house might be reading 20C, and then suddenly have 1 reading where it reads 0C and then returns to 20C. This is obviously wrong, and it has upset people in the past, but it’s not easy to filter.

I guess that this is the case with different devices, not just ZWave ones and I think that this is not something that the binding should have to account for - the system should provide this as a service to all bindings. Otherwise we end up with lots of bespoke implementations in bindings to try and cater for different “crazy” responses. Maybe it’s worth raising an ESH issue for this?

1 Like

Now that’s no generically applicable sort of validation but needs to be tailored to every application.
It therefore should not be done in any binding. As @chris correctly mentioned there’s many more non-ZWave devices this applies to.
I’d write a lambda to validate every value before using it, applying knowledge you have about your specific deployment. That’s why I’d also say it does not make sense to raise an ESH issue here.

Agreed it’s not an easy issue. For the bulk of mine, I can simplify it. i.e. inside temps should be between 0C and about 40C. And outside between -10 and 40C.

But they do change… And the expected values can be trimmed even more if it were possible to insert a filter between the bindings that gather the sensor readings and the bindings that store them.

Is there such a callout in OH? Or is that a major change to the way it operates?

As I wrote: use lambdas.

How does this in itself solve the problem? You still can’t update the item value before it is propagated through the system can you? Using a rule in this way, you would need to update another item, right, and not prevent the original item being set to a bad value.

I didn’t think that was possible, other than possibly in transformations? (but you probably have more knowledge on this than me as I spend most of my time with my head in bindings :wink: ).

That’s right, you have to incorporate lambdas in your rules code, either you work on proxy items only (to get updated by some rule triggered upon changes to the original item) or work with variables like in
var myValidatedValue = validate.apply(myItem.state).
Or transformations, yes, but these also need to be called explicitly from rules.
So yes, it’s not exactly what the OP is looking for. I don’t know of any ‘implicit’ method you can use though.

What I don’t like about needing to use lambdas or Rules for this is that it require a whole host of proxy Items and such around it. It feels awkward.

This is another good use case for why I would like to see transformations pulled out of the individual bindings and make it a generic service. There are so many problems like this that would be so easy to solve with a transform but the binding in question doesn’t support transforms.

Of course the problem becomes more challenging since we currently need to define transforms on the Thing, not the Item, when using Channels.

But taking this case as an example, one could write a very simple JS transform that filters out the crazy values and not require new proxy Items and Rules. But since the Zwave binding doesn’t support tansforms in this way (as far as I’m aware) that isn’t possible.

Other use cases include:

  • Maybe I don’t want my motion sensors to be Switches, I could use a transform to populate a Contact Item
  • Maybe I don’t want to put the result of my Exec binding script into a String, I could use a transform to populate a Number Item
  • Maybe I need two or more transforms to execute in a chain (e.g. JSONPATH to extract a value and REGEX to strip off some more values).

and so on.