So I set up a simple off-only motion rule to turn off a kitchen light after a period of inactivity. It's working fine (first 3 lines of the below rule). I don't generally want to sensor to turn the light on, but I wanted to add a "hey I'm still here" feature that ran for 30 seconds after the motion rule turns the light off, by which someone can trigger the motion and get the light back on. I thought this would do it:
But whenever it runs, once the light goes out, the rule immediately exits without leaving time for the wait for motion second half to run. Leads me to a couple of questions I couldn't find elsewhere (note I threw in the 1 second delay just to be sure the cancel ran before the next step):
1- Does the cancel delayed actions command pre-emptively cancel delays in the same rule that have not yet been started? (I think I've seen suggestions that it does). That would mean I can't nest delays in a single rule like this I guess.
2- Even if that's so, as the initial "light off" command is the only one set as cancellable, why would cancel rule delays cancel my exit rule delay (which is not set as cancellable)?
3- Is there something about the exit rule command itself that I can't use with a delay?
4- As usual, is there a more intelligent way to achieve what I'm going for here? Maybe a repeating loop checking motion condition for a certain amount of time? Either way I keep running into difficulty thinking of a way to add the binary paths of exit rule vs turn the light back on within an action list. If I run another "wait for" can I recheck newly refreshed conditions after it? That might do it I guess.
(waiting for the family to get out of the kitchen to test my next idea...)
Ok, I found my own solution. Using a second wait for and condition check works just fine.
I'm still curious why the previous attempt didn't work for the purpose of better understanding rule machine if anyone knows.
I wrote a simple rule to test your hypothesis that the "delayed" option may be ignored on the "Exit Rule" action:
Action logging says the rule is exiting immediately; a peek at the "App Status" page shows nothing scheduled; and the "Log" action I included after this never runs (as shown by either Action logging, which I have enabled, or the actual log entry it should generate). So, I believe there is some oddity there. Tagging @bravenel to investigate that much.
The sole log, generated immediately upon running the actions:
That being said, a delayed "Exit Rule" is a bit odd, so I could understand if that was a case that was never anticipated. Some people overestimate the power of "Exit Rule." It won't un-schedule any jobs that were already created (e.g, as the result of a previous delay), and in your case I'm pretty sure that it would still leave the subscription for your "Wait for event: motion active" action, though I can't actually test that to say for sure given that they delay doesn't work at all now. Basically, "Exit Rule" just stops actions after the current action from running (but, theoretically if the delay worked as expected, wouldn't affect actions that happen to have been written after it but already executed--and they will indeed execute to the fact that delays on an action simply schedule that action for that time in the future, while continuing with the next). Or, in fewer words, I don't think this would work as expected even if the delay oddity were addressed.
Other than that, you are correct: "Cancel Delayed Actions" affects only delays marked as "cancelable." (It should be noted that "Waits" are cancelled on re-trigger, and lately I've preferred to write what I used to write as cancelable delays as "Wait for events: elapsed time --> xx:yy:zz" instead whenever it works to do so.)
You don't need the ELSE Exit Rule. If the IF condition isn't met there aren't any other actions so the rule is finished.
You are correct about pretty much all of this. Exit Rule does just exit without processing any delay attached to it. Exit Rule is a special case action, and the nature of the action-taking logic would not support a delay on it. If a pre-exit delay is desired, it would have to be a stand-alone Delay Actions. The action creation UI should disallow a delay on Exit Rule, and I will look into fixing that (see below).
No, it is not possible to get to an Exit Rule with a pending Wait. The Wait itself causes the rule to exit, pending its triggers happening or conditions being met, so how could an Exit Rule happen 'after' that?
It is also true that Exit Rule does nothing to cleanup whatever is outstanding in the rule. There cannot be a pending Wait or Delay Actions, otherwise the Exit Rule could not happen. There can be pending Repeats and delays on individual actions, and these would still happen as scheduled -- the Exit Rule in such a case being a temporary thing. However, a delay on an individual action would cause only that particular action to be run, not the rule actions restarted. A Repeat, on the other hand will complete it's logic, so an Exit Rule buried within it effectively acts as a temporary departure.
Perhaps there could be a "Stop Rule" action, that kills all pending scheduled jobs and exits the rule. I don't know if this is useful, although it is easy to conceive and easy to implement as well.
Update: Next release will prevent the option of placing a delay on Exit Rule.
Thanks for the clarifications. My intent in using the delayed Exit rule in this fashion was to prevent the actions AFTER the second "wait for" from running if the wait for event did not occur, by exiting the rule before it got that far. It was essentially a work around to being unable to setup a conditional decision in the middle of a running rule (although looking closer I probably reversed my delay timers for that to have worked). In any case, realizing that I actually can have a change in condition evaluated after a wait for event is a much more elegant way to do the same thing, and appears to be working for me.
