I hadn't considered this before. I use automation switches to turn off different automation depending on if we have guest or I have people here cleaning/doing work. This is making me think about how they work and as you point out what happens if I were to turn them off during the delay.
1 Like
It seems to me like this way is cleaner
and based on this:
If I'm understanding @mike.maxwell the wait for event is just subscribing to an event...so there's nothing "running".
Also you could put a timeout on that Wait. And make it for 5 min and 1 second. Therefore if the door isn't re-opened in the first 5 minutes then the subscription even gets removed because at that point waiting for an open and canceling does nothing.
Yes, you are 100% correct in that. There is nothing “running” but the rule is sort of put on pause while waiting for the event to happen. IMHO things should be completed as quickly as possible and not left “running” for long periods of time. That’s why I said that if it was me, I would trigger on the open and wait for the close, rather than the other way around because that is likely to complete he running of the rule quicker. Just to reiterate from my previous post, there is definitely nothing wrong with doing it the other way either.
I like your addition of the timeout to the wait! I didn’t think of that. That addresses my own personal concern of leaving rules hanging for long periods of time.
What is best and what looks the most logical is very much a personal thing. Some people like it one way, others another way. As they say, there’s more than one way to skin a cat. Being able to see another solution for the same problem will hopefully lead to us all picking up a thing or two that we hadn’t thought of and that just makes us all more well rounded individuals 
1 Like
I use this exact KISS structure on my rules that monitor open doors and such. So they all basically look like:
Trigger: Door Open
Actions:
Delay 10 Minutes
IF (Door Open) THEN
Notify "door open dummy"
Wait For Event: Door Closed
Notify "door has been closed thank you"
END-IF
Pretty simple. Here's the problem. I noticed it on my garage refrigerator a few days ago (we have a contact sensor on the door). Let's say one of my teens (we'll call him the Good Boy) opens the door, firing the rule, beginning the 10 minute delay, and then closes it fairly quickly. But then, about 9 1/2 minutes letter, another one of my teens (oh, let's call him my Bad Boy), opens it for a few minutes searching for Beer, the rule thinks the door has been open the entire 10 minutes because the Good Boy's close didn't cancel the first firing.
Can any RM experts help me understand how to cancel the 10 minute wait and kill the rule on door close so the second open restarts the rule from the beginning? TIA...
Are you sure that's actually what's happening? Because I'm having the problem you've described you want to have. In my case, it's a motion activated rule and it has a few waits in it like you do, but if motion is detected again, the rule starts back from the beginning.
Here's the rule I am using. Once he makes it to the bathroom and then goes back to his room, the rule starts from the beginning and cancels the current rule running. There's a few suggestions in my thread to prevent it that I haven't tried yet.
In my opinion, this is when one of the "pre-KISS-style" rules might actually make more sense, at least to think about initially. Here is an example of that paradigm, which I shamelessly stole from the docs:
For comparison, the "new" paradigm for this would look something like:
Trigger events: Motion active
Actions:
On: Kitchen
Cancel Delayed Actions
Wait for events: Motion inactive
Off: Kitchen --> delay 0:02:00 (cancelable)
No matter how you write it, the key to what you want is the "Cancel Delayed Actions" step. Without it, the scheduled job the delay creates (to continue with the remaining actions when the timer expires) will remain, no matter how many times the rule triggers in the meantime. This does not apply to "Wait" actions, which are effectively cancelled any time the rule triggers, so if you wanted the lights to turn off immediately when motion became inactive above instead of after 2 minutes, this would do and is indeed simpler:
Trigger events: Motion active
Actions:
On: Kitchen
Wait for events: Motion inactive
Off: Kitchen
When you start adding more, then I'm not sure anymore. But either style would get you the same outcome.
For your rule, I'd consider one of two options. One is rewriting to use the "changed" trigger from the original paradigm above, something like this:
Trigger: Door changed
Actions:
IF (Door is open) THEN
Delay 0:10:00 (cancelable)
Notify "door open"
Wait for event: Door closed
Notify "door closed, thanks"
ELSE
Cancel Delayed Actions
END-IF
If you wanted to use the "new" paradigm, one awkward way to make this work would be:
Trigger: Door closed
Actions:
IF (Private Boolean is False) THEN
Notify "door closed, thanks"
Set Private Boolean True
END-IF
Cancel Delayed Actions
Wait for event: door opened
Delay 0:10:00 (cancelable)
Set Private Boolean False
Notify "door open"
Note that it counter-intuitively triggers on door closing and adds Private Boolean to track whether the rule notified about the door, all while using more actions than the style of rule it was suggested to replace. Perhaps someone can figure out a way to do this triggering on opening, but I might suggest the "old" way here instead.
1 Like
I think you are almost there. Just make the 10 minute delay cancellable and then insert a “cancel delays” action as your first action in the rule.
Three answers, all good. Just different ways to skin the cat. Appreciate it, guys.
Hey Robert, thanks for this very thoughtful note. You see any reason (and this is just for my learning at this point) that I couldn't get rid of the If-Else-End-If lines, move CDA to the top, and change the trigger from Changed to Open, leaving everything else as you have it. Seems like that would work and be even simpler, no? Or am I missing something?
EDIT: Err, umm, guess that's the same as what @mattias was suggesting. Duh.
2 Likes
