Need clarification what "Cancelable" does.
Does it do this: During the delay time for an IF or ELSE if the condition is no longer true does it cancel the action, exit the routine and wait for the trigger to activate again?
Im using the phone presence driver to change modes, thinking about adding a 10min delay with cancelable if I get out of wifi range for a minute or so then come back.
It adds a handle to the delayed action, so another rule can trigger and cancel the action of the 1st rule.
The delay is only canceled if you run a "Cancel Delayed Actions" (and have "cancelable" marked on the delay). This works only from within the same rule. Alternatively, you could use the "Cancel Timed Actions" action on that rule from any rule, but that cancels a bit more than just delays that may or may not matter for your specific rule (and will include any delay, not just those so marked). There are lots of examples in the docs.
Or in case this isn't clear, the andwer to your question about conditions is "no." 
Got it, will mess around with it. Thanks for the link.
cancelable delay is useful for motion lighting.. see this rule.. this is so that if the motion sensor turns off before the light delay expires and the light turns off , and then the motion is retriggered the cancel will stop the existing turn off delay and start the countdown over..
it that any better performance wise or easier on the hub? it is a little different in that it will always cancel 3 minutes after motion ceases vs 3 minutes after last trigger. also based on timing of your motion sensors couldnt you have like a bunch of those all stacked up at once in the wait condition? Say if your motion sensors turns off at 1 minute vs mine where there should always only be one instance waiting or i am misunderstanding?
Which is probably what you want. If motion goes active, and stays active, you don't want the lights to turn off after 3 minutes. You don't want them to turn off until after motion has stopped.
mine does not turn off if motion stays active either.. as long as the delay time is longer than the mtion sensor reset which it is.
That's not true. Motion can stay active as long as someone is moving about, without a new trigger event.
This rule is a bit odd: if your motion sensor stays active for more than three minutes (i.e., you don't stop moving enough or its timeout interval isn't short enough for you to get an "inactive" event during that time), then your lights will still turn off. This is a common trap that new users fall into when manually writing lighting automations in Rule Machine (and one of many reasons I often suggest SAR or Motion Lighting if they haven't already tried). The classic paradigm suggested in the docs would work better for most people:
Alternatively, Bruce's example above solves that problem and also re-writes basically this same flow in a way that staff have been suggesting recently (and that lots of community members have been following). Either would have identical outcomes, and both avoid this problem. I can't speak to "efficiency" in terms of hub load between the two (aside from the fact that I suspect the difference is negligible), but many humans might find the second/newer one easier to write.
[EDIT: the first thing is basically what he said as I was writing 
]
thanks i like your rule better will change it to that.. i think that is better than a wait which as i said in my case can have more than one waiting at a time. However my rule is really only for going out of the bedroom in the middle of the night to get something from the kitchen and we are always done within the 3 mintes so no biggee. however i would reverse your on; and cancel, I have seen weird race conditions where the light goes on a millisec before the waiting cancel fires and it turns right off.
There can only be a single wait pending at a time.
The point of the discussion is that you have to condition turning lights off based on motion inactive, not motion active, irrespective of the means of timing it.
In the case of what I've shown above, this could only happen at the end of the 3 minutes, and pretty much any approach to this can have a motion active event occur almost simultaneously with an independently timed off action. This has nothing to do with Wait.
not talking about your example but berts.
for yours how do your guarantee only one in wait state..
take this example
motion fires.. lights go on.. it is waiting for it to turn off..
motion turns off after one minute...
now we are in a wait for 3 minutes to turn off.
now before that happens motion fires again..
now we have a second instance wiating for motion to end along with the original one waiting for 3 minutes? what am i missing?
Rule Machine only allows one wait. Any pending wait is cancelled by any trigger firing. It's effectively an auto-cancel, as in cancellable delay.
only one wait per rule i take it.. good to know.. was worried about them stacking up.. thanks
i think too much like a programmer.. lol. I have seen those edge cases in real life and they can quickly bring a system down if you are not carefull.
There actually is a sort of perverse race condition that is possible, and I have a rule that exploits it. A trigger cancels a pending wait, right? But what if the wait is for the same event? Ha, now that's a race condition! In my rule, both the wait starts running and the rule is triggered again (both from a button press). But, what happens on those two now simultaneous instances but different actions is benign, and I'm actually counting on the actions after the wait to run. It is possible due to the indeterminacy that this rule could fail -- in practice it doesn't, but it could.
cool your right. it is indeterminate.. depending on cpu one or the other could be put to sleep with the other runs unless you use semaphores or some locking mechanism to guarantee and atomic operation.. and give a priority to either the wait or the initial trigger over the other.
None of which makes sense to try to do in RM. It's a quad-core CPU, only 2 people in the house, odds are pretty good 2 cpus are available when this happens (once a day). Seems like some grad student could calculate the odds of this failing....
Download the Hubitat app
