I need an advice how construct rule to detect failure of the DHT22 temperature sensor, On my current setup I`m using DHT22 to drive wall heater in the bathroom (my previous thread posted below for information). Everything seems to be working fine, however occasionally I get situation when the temperature sensor stops responding (no reporting new value, will stuck on last reading - it could be 18C) and then the manual restart of the sensor is required. So in the situation when my heater been triggered to run and then sensor stops responding afterwards, heater would be running forever…
Ideally I need to create new rule alerting me when this happens.
Would anyone be able to throw some suggestions.
You could use a cron triggered rule to check if it has.not updated, or start a Timer after it has updated and then reschedule after subsequent updates. The first option is easier to implement.
This would be a bandaid though and you may want to solve the real problem.
Typically the expire binding can be used to detect failure to update within a time window.
You might use it with command=UNDEF and then a rule can easily detect change to UNDEF and ring bells, while your regular rules can avoid trying to work with UNDEF,
1.x addons are perfectly compatible with openHAB2.
expire is so well suited to this task it has not needed to be updated for OH2.
openHAB3 is not yet in use by anyone, nor even clearly defined.
There will most likely be some kind of OH3 equivalent feature to expire.
Is there any reason to think a cron or timer based rule written for OH2 will work without modification in OH3?
Either approach will work in this case, with more or less implementation difficulty today, and more or less difficulty if it ever needs to be carried forward to OH3 if the user chooses to use OH3.
“Tomorrow’s solutions today” is sometimes a marketing slogan more than practical advice.
Yes, but my point was that 1.x addons are not compatible with OH 3.0, so for the OP to implement something now that makes use of them would be creating rework when they plan to update OH. If the OP is planning to stay on OH 2.5 forever, then certainly the expire binding is also a suitable option.
I believe you are mistaken or do not have the full story on expire. A 2.x version of the expire binding has not been created because it was a mistake to have let a 1.x version into production in the first place. It’s pretty clear that a 2.x version would have not been approved. There are plenty of discussions about this in GH and the forum.
While it is unlikely to be in use in a production sense, it’s definitely being used in development. As for being clearly defined, a software product is only ever truly defined until after it is EOL. Coincidentally, the expire binding has only just become clearly defined ! OH 3.0 is in it’s infancy, but the major focal points are UI, automation, Java 11, and 1.x compatibility.
Yes, absolutely… cron triggers and the createTimer Action are both currently available in the new rule engine and I do not foresee or plan any change to that.
My point exactly… although knowing how to use cron triggers and Timers are skills that will still be useful in OH 3.0. There are several options that the OP can choose from, but the OP needs to decide whether they want to implement a solution using cron triggers now or when they chose to upgrade to OH 3.0. If the latter, they also need to put effort into implementing expire in the interim.
I don’t understand this… cron triggers and timers have been around much longer than the expire binding, and they have outlived it! They are solid tools to use for implementing this sort of solution, so I recommended the OP use one of them rather than something that will not be usable later this year.
While I am using a rule to only display changes to also display the last time of the change it should be possible to implement it in the other way around to check for missing changes.
To give my 2cents: I made it pretty simple, was a task of 2mins.
Whenever I want to track if something is not updated over a period of time, I implement a virtual switch to the tracked item (in this case temperature) and implement the expire to the switch to go off after XX minutes. Then a rule with if item temperature recives update, set the virtual switch to on. The expire resets and counts down again with XX minutes.
In the sitemap I then set visibility to the off state of the virtual switch an done. You can of course do more with a rule, which just listens to the switch going off.
This is pretty easy, takes less than 2 minutes and I have the sitemap alert via the visibility also integrated. Changing this logic for OH3 wouldn’t be a dramatic loss of time, because it just took very little amount of time to set up
! OH 3.0 is in it’s infancy, but the major focal points are 