From a "Wait" and motion perspective, that looks OK to me! (Again, I'll assume you know what you want with the contact sensors and the conditionals they're in.)
umm i dont think its working the light is not turning off basically if a door is open i want the light to still turn off after X minutes
the "wash room door" goes to the kitchen it is open most of the time, the "wash room doorhw" goes to garage and is close 99.9% of the time. (yes im going to rename it lol)
That won't happen as-is because your first conditional will be met, and the action contained inside it is the only thing that will run until another trigger happens. If opening the door would also create motion, you can rework the rule to just use any kind of sensor to turn it on and just motion to turn it off. Maybe that would work?
yeah im notice the logs aways "skip" the last rule (i have it set to activate on change) the ON is working great will come on if any door opens OR motion.
The off part is broken (by me not knowing what theck im doing)
Sorry @bertabcd1234, maybe I am not following but I’ve just been using an “on”, and then put my delay on the “off” (see attached example).
Now, I understand “wait for event motion inactive” before triggering an off but...
What is the advantage or purpose of “wait for event: elapsed time?” before the “off” command?
A "delay" will not be cancelled unless you mark it as such and also run a "Cancel Delayed Actions" action somewhere. A "wait" of any kind will be cancelled automatically when the rule is triggered. So, in your rule, if you press button 1, then wait four minutes, then press it again, the light will turn off one minute (not five) after that last press--nothing cancelled the originally scheduled delay. A wait would be cancelled with the second button press because that is a trigger event for your rule. Alternatively, the existing rule could be written with a "Cancel Delayed Actions" at the beginning and with marking "cancel?" (sometimes displayed as "cancelable") on the delayed "Off" action.
4 Likes
Awesome explanation, thanks @bertabcd1234, you rock!
Ok so my next question is, are there scenarios where either may be more advantageous than the other?
(Canceled delayed actions VS Wait)
Just depends on what you want the rule to actually do. 
But in most cases I can think of, the cancellation is the desirable outcome, and using the "Wait" means a few less clicks. It's a bit newer (at least the ease of using "elapsed time" is), so you won't find it in as many docs/examples.
1 Like
Are they actually always cancelled? What is the point of the "Cancel wait" action then? I simply say this because I recently found a bug in my rule that effectively brought my hub to it's knees where I was using "Wait for condition" and it had 81,000+ simultaneous wait conditions that was crashing my hub every 24 hours. After stopping and starting the rule and changing to "Wait for Event" everything seems to be fine now and the waits are properly being canceled, but I have a "Cancel Wait" at the start of the rule.
Given the behavior of waits, I'm not really sure what use "Cancel Wait" servers with a rule that has triggers, though there could be some use case I'm missing. I imagine it may have value if you have a "triggerless" rule that just gets invoked from others, assuming that doesn't count as a trigger, too...
Interesting, I was always going off the assumption that any rule that has a wait condition/event needed a cancel wait action first to avoid multiple instances, I was basing that assumption off of this thread:
I'm not sure what to make of that post, but they are definitely cancelled if the rule is re-triggered:
1 Like
I have wondered about this myself.
My assumption is that the behaviour of the wait has been modified and the “cancel wait” was present earlier on.
Waits are cancelled by the rule being triggered.
I don't think there should be a Cancel Wait action, as there is no context it which it does anything. That will come out in 2.2.5.
5 Likes
What will happen to rules that use the Cancel Wait action in them? Should I just preemptively delete them or would the update just delete them for me?
Nothing. Release 2.2.5 includes a new version of Rule, Rule-4.1. Existing Rule-4.0 rules will still function as before and don't need to be changed. Rule-4.1's main difference is Wait for Conditions, replacing Wait for Condition. This allows a full logical expression instead of a single condition.
3 Likes
i am so confused now
1 Like
Sorry, we got distracted discussing related issues. 
There are ways you can make it work, either by modifying your triggers or re-ordering your blocks of conditional actions (as you may know, only the first matching block in an IF ... ELSE-IF ... ELSE-IF ... END-IF will be evaluated) with other minor changes. But it might be good to have a clear idea for others of what you want to turn the lights on (or off) besides motion: either door opening or closing, or just one (or both) doors doing one specific thing? And you always want the timeout to start regardless of whether there's motion? (If you don't, that makes things easier since you could always "Wait for event: motion inactive.")
1 Like
Let me see if I can break it down.
Turn on if any door opens or motion
Turn off of both doors closed and motion stops 5 minutes delay, motion will reset delay
Turn off if one door is open and motion stops after 10 minutes
yeah i see that what i dont know is is there a command to make it go to the a final rule? in my field we have a "then next term" or "then term xxxx"
this would make it drop to the my last else-if ( or does that just need to an "else"
