This is a hard problem. As with all hard problems, you need to break it into multiple parts.
- As rossko57 indicates, you need to figure out how to know that a sensor is not working. Then write code/configuration to reliably detect this in your Rules. You will probably need to use a Proxy Item and a Rule. And of course how you do this depends greatly on the behavior the sensor exhibits when it is not working correctly. Does it stop reporting? Does it momentarily report an unreasonable value? What constitutes an unreasonable value? If it just stops reporting then you can use the Expire binding to set that Item to UNDEF if it doesn’t report for awhile. If it reports one odd value then comparing the current reading to the last reading might be sufficient. But you might need to use a bunch of complicate math and Markov chaining and the like to estimate where the temp reading should be based on past readings and if the actual is too far beyond the estimate then you reject it.
To start, just write a Rule that logs out when it senses a bad sensor reading and double check that it is right.
rule "Filter out likely bad readings"
when
Item t1 received changed or
Item t2 received changed or
Item t3 received changed or
Item t4 received changed
then
if(Math::abs(triggeringItem.state as Number - previousState as Number) < 50)
postUpdate(triggeringItem.name+"_Proxy", triggeringItem.state)
else
logWarn("temp", triggeringItem.name + " returned an unreasonable sensor reading: curr = " + triggeringItem.state + " prev = " + previousState)
end
The above Rule triggers when any of the sensors changes. Only if the change between the current reading and the previous reading is less then 50 is the sensor reading forwarded on to the Proxy Item.
-
Once you can reliably detect a bad sensor reading you need to figure out what is the correct way to handle it. Do you just ignore it? Do you estimate the value based on the other sensors (e.g. assume it’s the average of the other ones)? Do you shut everything down? etc.
-
Finally, you need to implement the Rule that combines 1 and 2 as appropriate.
Honestly, having done this with my own heating to just handle the case where a sensor goes offline, it will be far far less work and far more reliable to fix the problem in hardware if that is an option.