How should I Ignore a value if its clearly incorrect

1

I have a nodemcu temperature sensor in my pool pump shed monitoring temperatures of water and solar and controlling the pumps etc. Every now and again the temperature returned for any of the three temp sensors is -127.0 instead of the correct value. I dont want to change the nodemcu config as thats all running where is the best way to capture these errors and ignore them leaving the current value in place? A REGEX on the query or a RULE?

2

I recommend using a rule. How is the data entering openHAB? If you have a binding updating an item (call it OriginalTemp), create a new item of the same Number type (call it FilteredTemp), persisted as you are currently persisting your existing item.

Rule (not tested):

rule FilterTemp
when
  Item OriginalTemp received update
then
  if ((OriginalTemp.state as DecimalType) > -127.0) {
    FilteredTemp.postUpdate(OriginalTemp.state)
  }
end
3

Thanks so much again watou i will give this a go tonight.

6

Thanks i didnt read it correctly at first but this is working well.

1 Like
7

i did something similar in another way, so i didn’t need another item:

rule "Korrektur Temperatursensor Flur"
when
    Item tmp_flur_wohnungstuer received update
then
    var Number T_new = tmp_flur_wohnungstuer.state as DecimalType
    var Number T_old = tmp_flur_wohnungstuer.historicState(now.minusMinutes(1)).state as DecimalType
    var Number T_delta = Math::abs(tmp_flur_wohnungstuer.deltaSince(now.minusMinutes(1)).intValue)
    if (T_delta >= 10) {
        tmp_flur_wohnungstuer.postUpdate(T_old)
        logInfo("Sensorkorrektur", "Flur-Temperatur von " + T_new.toString + "°C auf " + T_old.toString + "°C korrigiert.")
    }
end
1 Like
8

Thanks that’s a great way to stop bug variation, I didn’t know you could use now.minusMinutes(1) to get an old value.

9

You can, if you use persistence!

10

This approach works, but it also allows a “bad” value to be persisted for the tmp_flur_wohnungstuer item, and the rule will immediately set it to an old “good” state, so both the bad value and then good value are persisted (if it happens within the same second, some persistence services will overwrite the bad value, but this is a buggy side effect depending on the type and version of the persistence service). To keep the persistent store from ever receiving a bad value, my example will only ever store “good” values for the FilteredTemp item. But of course whichever way you prefer!

11

in my approach a bad persisted value doesn’t matter at all, it is more a value for a heating control, so the “now”-value is more important…
But yes, that could be a problem in some usecases…