Extreme unrealistic values from sensors like temperature & humidity

Setup, Configuration and Use Beginners
, ,
1

  • Platform information:

    • Hardware: Raspberry Pi 3 Model B Rev 1.2
    • OS: Raspbian GNU/Linux 8 (jessie), Linux 4.4.0-1-rpi2
    • Java Runtime Environment:
      • openjdk version “1.8.0_152”
      • OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
      • OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
    • openHAB version: openHAB 2.2.0-1 (Release Build)

  • Issue of the topic: Since the update to the newest openHab Version, lots of sensors have extreme unrealistic values like 390 degree Celsius. These values stay for some minutes up to some hours. These items were added via the configuration.

    2018-01-01 12:32:06.063 [vent.ItemStateChangedEvent] - ZWaveNode7010F0B01100200_SensorTemperature changed from 20.17 to 390.0

The sensor from the example:

image
image.png1038×631 23.2 KB

image
image.png704×344 22 KB

2

Hi!

Got some similar issues - like energy values of -214748356 kWh from an Everspring AN158 or constant 120 W power value from a qubino rollershutter.

Regards,
Herbert

3

Please check the debug logs to see what is coming in from the sensors. I think it’s pretty unlikely that this is caused by the binding.

4

@chris
are these logs some, we have to enable or are they enabled by default? Which logs do you need specifically?

Is it enough to set the log-level of org.openhab.binding.zwave to debug?

5

Yes - if you set this, then you will get the debug information added to the standard openhab.log file - this will be fine. You can use the log viewer here to view the logs (I think it will decode multi-level-sensor data).

6

@chris

So I had some luck to receive a further unrealistic value with debug logging. Maybe you can help me here.

2018-01-03 14:51:56.734 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Incoming command class SENSOR_MULTILEVEL
2018-01-03 14:51:56.736 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 10: Received COMMAND_CLASS_SENSOR_MULTILEVEL command V5
2018-01-03 14:51:56.737 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 10: Sensor Multi Level REPORT received
2018-01-03 14:51:56.739 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 10: Sensor Type = Temperature(1), Scale = 1
2018-01-03 14:51:56.741 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 10: Sensor Value = 515
2018-01-03 14:51:56.743 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMultiLevelSensorValueEvent
2018-01-03 14:51:56.745 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2018-01-03 14:51:56.747 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_MULTILEVEL, value = 515
2018-01-03 14:51:56.750 [DEBUG] [erter.ZWaveMultiLevelSensorConverter] - NODE 10: Sensor is reporting scale 1, requiring conversion to 0. Value is now 515.
2018-01-03 14:51:56.752 [DEBUG] [converter.ZWaveCommandClassConverter] - Converted temperature from 515F to 268.3C
2018-01-03 14:51:56.754 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:controller:node10:sensor_temperature to 268.3 [DecimalType]

Addditional to the excerpt above, I’ve attached the file here: https://hastebin.com/duputoxasi.cs

7

So, hand decoding the following message, which is the raw data from the message you posted above -:

2018-01-03 14:51:56.724 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 0A 06 31 05 01 0A 02 03 C5

The command definition is as follows -:
image

31 = command class (sensor multilevel)
05 = command (report)
01 = sensor type (temperature)
0A = size=2, scale=1 (degF), precision=0
0203 = value (515)

Converting 515 with precision 0 is still 515. Scale = 1 (F), converting this to C is 268.

So unless I missed something, it looks to me like the binding is correctly interpreting the data. Either the sensor send the data incorrectly, or the message got corrupted somewhere. We can say that it was correctly passed from the controller to the binding as the checksum on the packet is ok.

8

Hi,

thanks for the great clarification. But now I still have the issue with these values. What could be the next step to find the issue? With the old version I never had something like that. I’m sure of that because the charts with the persisted data were readable. Now I have a long line with some spikes (these high and low values)

Thanks!

9

I would reset the device to see if it solves it. You could check to see if there is any correlation with polling as we’ve seen int the past bugs in some Aeon devices where polled responses are corrupt but unsolicited responses are ok (this wasn’t the case with the log you sent yesterday as I checked that).

This isn’t a binding issue, so it’s not version related.