I was stumped this before 4.0 was available, and remain stumped. Very simple automation, but I'm unable to make it work.
I have a simple contact sensor affixed to my refrigerator door, with the proper operation confirmed. All I want is a notification to be spoken through my Google Home devices if the fridge door is left open longer than 90 seconds. If the door is opened and closed within 90 seconds, the automation should be canceled, and no message should be spoken.
I thought I was home free, but I'm still not getting what I want. I saw the "Delay" button interface in the Action configuration, which when activated madness appear a button labeled "Cancel". When I activate that "Cancel" button, no explanation is provided, but I assumed it means that if the trigger is no longer true within the delay time, the rule cancels and the action will not occur.
However, when I tested it, I opened the fridge door for 5 seconds before closing it, then was disappointed 85 seconds later when the notification was still sent for speech to my Google Home, and I was told the refrigerator door was left open.
If that doesn't make any sense, could someone simply explain to me how to make this work?
Here is one I have to send me a notification if any of my garage doors or gate has been left open for 1hr. EDIT: It also keeps repeating every hour until all doors are closed.
This should give you a good idea on what to do.
This is RM4.
The trigger is fridge door opens. If it's closed the delay is cancelled and then that is no longer true, so it doesn't speak the message. Just tested this several times and it worked perfectly every time.
The delay isn't really cancelled--you have to have a "Cancel delayed actions" action somewhere to cancel anything with the "Cancel?" flag set. Bruce explains how that works in this post: [Released] Rule 4.0
Your rule will mostly work because, as stated above, you're testing whether it's still open after the delay. This creates almost the same result (except possibly more scheduled jobs that will just do nothing when they're run instead of getting un-scheduled when they are known to no longer be needed--probably not a problem), but I see one important difference. Suppose you do the following:
Time 0:00 - open door (triggers rule)
Close door (does nothing)
Time 1:29 - open door (triggers rule again)
Wait at least one second, then close door
In this case, it seems to me that between steps 3 and 4, you'll get the notification from the first triggering of the rule because at time 1:30, the IF in that rule will evaluate to true. The example from @bjcowles above that uses a "Cancel delayed actions" when the door closes fixes this problem by truly un-scheduling the execution (at step 2 in my example sequence) instead of just testing the state when it it scheduled to be run again.
Yeah you are both correct. I forgot about testing opening the door again before the delay is over, so I see where that's wrong. However, I'm baffled how to make this work properly. Can you show me an example (gonna have to clean it up for my brain @bobbles! )?
@bjcowles has an example above that works, but a more general explanation of delays and cancelling in RM 4.0, I'd look at Bruce's original post in the thread: [Released] Rule 4.0. He has one example with motion-based lighting, but the whole section called "What became of Rule Truth and Cancel on Truth Change?" is quite ... illuminating.
I've been schooled. The example @bjcowles gave works great. I was trying a delay before the speak with ELSE Cancel Delayed Actions after it was pointed out that my first example had a problem, but that second attempt would speak no matter what.
Also wanted to thank @pete3500 for the post. So silly I never thought of this use. We sometimes overpack the freezer and it doesn't close properly or bounces back open when you close the fridge door (it's an old fridge). That costs us quite a bit when we discover hours later that the freezer is slightly open and everything is covered in frost/half defrosted.