How does the "Delay" rule work with Cancel Delayed Actions? I have a simple rule that doesn't get to completion:
It's triggered (by a real action or the virtual switch(#4) turning on)
Cancel Delay Actions is done to clear any previous delays
Then a single-rule Delay for 5min (not a delay on a rule - the delay-only rule) which is cancelable
Then turn off a virtual switch
Then turn on the virtual switch if a condition is met
The idea is that after an initial condition, the rule will check every 5 mins if that condition still exists and maintain a virtual switch to indicate if so / if not.
But even though the initial trigger happens (according to logs) and stays that way pas the , the virtual switch never makes. I'm guessing it's something with the Delay or Cancel steps. Anyone have any insight?
The "Delay" action pauses rule execution and schedules a resumption, starting at the next action, at the specified time (5 minutes in your case) in the future. A "Cancel Delayed Actions" will, if run, un-schedule this resumption (which means that any actions after the delay will also not get run). This is different from a delay on an action (where delays on an action just schedule that particular action for the future and continue immediately on with the next action), but I see you already understand that distinction.
It sounds like you want some sort of repeated check. That won't happen here. After 5 minutes, your rule actions will turn off "DH Check Door Deck" and then immediately check if "KN Door Deck" is open and turn on "HD Check Door Deck" if so. If not, it will not turn on that switch. In either case, the rule is completely done at that point and will not run again until some event happens that matches one of your triggers (which, if this wasn't already apparent, is what will cause your rule actions to begin running, starting from the top).
This doesn't seem like what you want. It sounds like you want some sort of loop to periodically check, which is possible (RM has "Repeat" that can create looping blocks of actions), but it's usually a bad idea to do time-based checks when you could instead just respond to the event that made the condition you're looking for possible. If you explain the automation you're hoping to achieve (in real-world terms, ignoring implemantation details that may be RM-specific), someone might suggest a rule (or possibly another built-in app if you aren't set on RM) that could do this.
It's really not clear what you're trying to do. Please explain in English what you want to do, leaving out the implementation using virtual switches, delays and what not.
Thanks for answering! Yeah, there might be a better way. I'll try to explain what I'm up to:
This door leads to an outdoor screenroom/deck that doesn't have much sensing. There is a contact on the door and a single motion sensor. I maintain an occupancy status based on those two things and control lights/fan/etc. with that. The occupancy expires in 20mins if nothing triggers it to stay on. I often find myself sitting out there (making little motion) and everything shuts down. Usually, the door remains open during this time (neither opening nor closing but just staying open).
The idea of this script is to create a trigger every 5 minutes that the door remains open that will tell the occupancy status that something is happening and to reset its 20-minute countdown. If the door is found to be shut at the end of the 5 minutes, then no trigger and the 20-minute countdown keeps going. In my automation, it has to be a trigger to make the 20-minute counter reset - the script to reset the counter doesn't know to run if it doesn't see a trigger happen. This switch that goes off and on again (unless the door is shut) is supposed to be that trigger.
I thought this was a good way to do that, but maybe I'm getting the Delay / Cancel functions wrong. I'm open to other ideas too.
Thanks!
I think the Wait for Condition will work better for you than looking at things every 5 minutes. The cool thing about a Wait is that every time the rule is triggered, the Wait is cancelled. Which means that it starts over. That's exactly what you are describing.
Something like this:
Trigger events:
deck motion becomes active
deck door becomes open
Actions:
Set Occupancy status true
Wait for Condition: deck door is closed
Set Occupancy status false
There is no timing involved. Assumes you that you only want occupancy to go false when the door closes after having been opened. I don't understand the point of the 20 minutes, so if that has some other purpose please explain...
Yeah, it was supposed to be changed. Iām in a rush but procrastinating packing.
Edit: I rushed it too much. The condition isnāt right either. I was looking at one of my rules that does something similar and I lost it in translation.
Ok, @bravenel, that Wait For Condition might work. I didn't realize that it got canceled when the rule triggered. I guess I thought it just kept waiting and I was afraid it would get stuck. That makes a big difference. I will try that out at least for this door check thing. Maybe for the occupancy statuses too, though I'm less sure about them since they can be altered by other things outside of the sensors. (The 20min, btw, is just so the room stays occupied when you leave and come back - don't want it to go dark and turn off the music and everything when you're just going to get a fresh drink).
Is there a way to cancel a Wait For Condition (or other Delay, for that matter) from a different rule than the one it is in? For example, if I manually trigger a 'scene' that sets lighting, music, and other conditions on the deck to some preset favorites, can I cancel the Wait For Condition so that the scene doesn't turn off when the door gets closed?
Either way, I think you've got me on the right track. Thanks for the help & ideas from you, @bertabcd1234, and @lairdknox!
So many options a break down of every rule in RM 4 would sure be nice in the documentation. Something that explains a bit more in depth what some of these do and/or when they actually function etc. But no one likes writing documentation!
I use the rule to turn on certain lights in the house during the day if it's cloudy or overcast out based on a Phillips Hue Motion Sensor illumination value.
It checks every 15 minutes to see if the condition has changed. If the sun comes out, it turns the lights off and resets.
Technically, this only checks once(-ish), 15 minutes after any triggering event--so lux <= 90, or whatever the value of the variable is at that time (assuming mode is day at that time). But, throughout the day, you're likely to get fluctuations in lux that will cause an event from the sensor, many of which will probably match your trigger, re-trigger the rule, and thus case the 15-minute-delayed check again. So, it will likely--and must if you haven't noticed any problems--work for your intended use either way.
For anyone who is curious, however, a "Wait for condition" would be one way to make a following actions happen any time the condition is true, not just if it happens to be true exactly 15 minutes later. The "duration" option in Rule 5.0, new since the rest of the above posts were written, can also help you prevent responding to short dips in lux. Maybe something like:
Trigger:Lux < 90
Actions:
IF (Mode is Day) THEN
Activate scene: ALL Overcast Lights ON
Wait for condition: Lux > 90 --> duration 0:10:00
Activate scene: ALL Overcast Lights OFF
END-IF
