You could drop the IF statements I would think, no?
The trigger executes because the generator sensor became Active. So there shouldn't be a reason to re-check if it's active again.
The "Delay" and "If" are because I was getting false positives from the vibration sensor. I blame the squirrels. 
Doing the second check makes sure the generator's actually running.
1 Like
@bravenel Bruce - In the spirit of KISS I’ve taken your suggestion to get rid of “changed” triggers to heart. I’ve started changing these triggers to trigger on the on or off event instead and then wait for the other event. However, I’ve got one question. How resilient is this methodology to a hub restart? If the rule is waiting for the next event to occur and the hub is restarted, will the rule go back to the same state of waiting for the next event, or will the rule “reset” itself and go back to waiting for the initial trigger again?
Rebooting the hub shouldn't matter unless the Wait event would happen while that was happening (time for example).
This is easy to test, just try it.
1 Like
Thanks for e quick reply. I was hoping that would be the answer 
I’ve given it a go before to test it but I thought I didn’t get consistent results from my testing. It could well have been that the event it was waiting for occurred during the reboot though. Thanks for clarifying!
If it is a device event, the rule creates a subscription to that event. Two things could cancel that subscription: the rule triggering again or the event occurring, fulfilling the Wait.
1 Like
So in the spirit of this I have been looking at my rules to try and simplify. This is one I changed but I am starting to wonder if it would be better flipped around to trigger on the open and wait for the close?
I reckon it’s better the other way around (trigger on open). As it is now, the rule is going to spend most of its life midway through, waiting for the open event. Not that there is anything wrong with that, I would just personally write the rules so that they finish as quickly as possible (I perceive there being a higher chance of failure the longer something runs, rightly or wrongly).
I would suggest that you trigger on open. Your rule would then look like:
Cancel delayed actions
Cancel any waits (just for good measure. There is a very low probability that the rule would ever get itself in to a state when this would be required)
Wait for event door closed
Delay actions 5 minutes
IF auto-lock on {
Lock door
}
I would put the wait before the IF just in case the state of the auto-lock changes during the 5 minute wait period.
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
