search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

[Onewire] Filter bad VAD values for iButtonLink Multisensor devices #4761

Closed kabili207 closed 5 years ago

kabili207 commented 5 years ago

Expected Behavior

iButtonLink's MS-TL and MS-TV devices have a tendency to report VAD values that are over 10 when they should be reporting as 0 instead. These values should be translated to 0 so that accurate light, humidity, etc are reported correctly.

Current Behavior

The Onewire binding is using these incorrect values, which is causing their associated values to be wildly inaccurate. My MS-TL devices, for example, will report a light level of well over 500,000 lux in a pitch black room.

Possible Solution

When pulling the VAD values from either an MS-TL or MS-TV device, values that are clearly out of spec should be changed to 0 before using them to calculate other values. This discussion on the owfs mailing list suggests changing anything over 10 for both devices (which is what I did with the onewire 1.x binding), however I think limiting it to 5 instead of 10 for the MS-TL would make more sense since the iButtonLink's manual for the multisensor devices says 5V is the max value it will report.

Steps to Reproduce (for Bugs)

  1. Add an MS-TL device to a onewire network is place it in a sealed box to prevent any light from entering
  2. After a while, the device will start reporting extremely large lux values

Context

This has forced me to disable to or rewrite several rules that use the light or voltage levels I'm monitoring, such as turning off devices or dimming devices when it's dark in a room.

Your Environment

J-N-K commented 5 years ago

Is that always a single value? Or is it more like „20 minutes working, 10 minutes wrong“?

I‘m asking because a single wrong value could be ignored, if it‘s for a longer period of time the value should be set to UNDEF.

kabili207 commented 5 years ago

I've seen it go on for hours with slightly different values, all over 10.

I'm not sure if UNDEF is a good choice because it behaves more like the sensor is underflowing. It will slowly drop down to zero, then wraps around to something around 10.23, continue slightly down, and then go back up eventually wrapping around to zero.

kabili207 commented 5 years ago

I should add that I've never seen it drop below 10 when it does this, so I don't think that will be a concern.