Generally speaking you would need to set up a timer for this, there are plenty of examples for light switches and garage doors in this forum.
Just for reference, there is a Thread::sleep command that can be used to make a rule wait, but its purpose is only for very short waits, it should never be used for more than, say, a few hundred milliseconds.
please don’t let a rule “WAIT” for more than a few (really!) seconds. This has to do with CPU-threads and stuff - read: it’s bad, if you do it for a longer period - and hours are VERY Long, considering CPUs calculate in nanoseconds and less…
What I do with those kinds of tasks (no persistence):
create an status item for it
create a rule which will fire every xx min if the Status is ON
Switch catlitter "clean cat litter"
rule "Cat litter"
when
Time cron "0 * */2 * * ?" // every two hours
then
if (catlitter.state == ON) {
// do something
}
end
If you keep a few rules waiting through thread::sleep for more than that, you are very likely to run out of threads, and incur other problems…timers can do the same job without the risks
It is actually not that common, but most frequently it is used if you need a 100ms for the OH2 bus and persistence to catch up so that you have the right values in case there were some actions triggered; or if you need bridges to communicate with your devices and OH2 pushes out a series of commands faster than the bridge can handle it (my hue lights have occasional random dropouts if I send too many commands in a row); an extra 10ms pause in between commands can do wonders in these cases
But the risk is that you use up threads (and OH2 does not have too many of them) with rules; and thread::sleeps will eat up too many resources if used for a long period
i try not to use it myself there was a case where kodi cracshed because of sending too many commands this was solved by a thread:sleep i do try not too use it myself
If the wait is very short or if you understand your Rules well enough to know with certainty that you will not have Thread::sleeps piling up upon each other causing you to run out of execution threads. Those users who know and understand their rules well enough to use long Thread:sleeps are experienced enough and knowledgeable enough to understand the risks they are taking and how to recognize and solve problems when they arise. For the rest of us (myself included because I would rather avoid the potential problem in the first place) we should be using Timers.
This is a good case where Thread::sleep is appropriate. I even wrote a design pattern (Design Pattern: Gate Keeper) on that problem and I do use Thread:sleep. But it needs to be short.
rule "Litter reminder"
Time cron "..." or
Item LitterTimer received command OFF
when
if(LitterCleaned.state != ON)){
// send notification
LitterTimer.sendCommand(ON)
}
end
rule "Litter cleaned"
when
Item LitterCleaned received command ON
then
LitterTimer.postUpdate(OFF)
end
rule "Reset LitterCleaned"
when
Time midnight
then
LitterCleaned.sendCommand(OFF)
end
Thanks for that again rich yes i remember you saying last time i explained my rules too you and you said it was fine but avoid using them if you remember i was getting processor threads confused