Do (Re)Triggers reset Delayed Action?

If a motion trigger causes the actions Light On followed by Light off in 5 Minutes and a motion event is retriggered before the 5 minutes has elapsed, does the Light Off timer start over again?

Just to elaborate on the above post, for the cancel delayed action to work, you must also select 'cancelable' against the delay.

3 Likes

To add to the above, if you use a wait instead of a delay (which I'm assuming is what you meant given your thread title; the description of the action in the original post is unclear), then it is erased when the rule re-triggers. So basically, something like this:

Cancel Delayed Actions
On: Light
Off: Light --> delay 0:05:00 (cancelable)

is equivalent to this, as far as what happens when the actions are triggered to run:

On: Light
Wait for event: elapsed time --> 0:05:00
Off: Light

The second thing is newer--"waits" for elapsed time were either hard to write or not possible in the past; it's not something you'll see in most documentation yet--but it's likely to save a few clicks and possible mistakes. I've started suggesting this where it makes sense, but either way works. You'll also see things like this from people who figured things out by clicking around instead of reading the docs: :slight_smile:

Cancel Timed Actions: This Rule
On: Light
Off: Light --> delay 0:05:00

This works, too, and has the same outcome as the above in this case. But "Cancel Timed Actions" does more than just cancel delays--and also note that it doesn't care whether you have "cancelable" selected, so I didn't do so above and it doesn't matter either way--as it indicates in the UI when you choose this action (there are a few other things it stops/cancels). You can call it on other rules, which may sometimes be a feature you want. In most cases, I'd say it's overkill. But for the sake of complete understanding, here it is!

PS - The first example is also equivalent, in this case, to this:

Cancel Delayed Actions
On: Light
Delay 0:05:00 (cancelable)
Off: Light

...with the difference being that the standalone "Delay" actions stops there, waits for the delay to expire, then proceeds with the next action. If you have multiple actions after the delay that you want to wait for, then this (or the "Wait for elapsed time") is what I'd do. A delay on an action schedules that action for that time in the future, then moves on to the next action, which is why I specified "equivalent in this case" above since there are no actions after the "Off" and it doesn't matter here.

4 Likes

So I have the following rule:

But it seems the 5 min wait is not reset every time the switch is turned off/on. So for example:

  1. Turned on light switch
  2. Two minutes have passed
  3. Turned off light switch
  4. One minute have passed
  5. Turned on light switch
  6. Fan switch will be turned on in 2 minutes

Am I doing something wrong?

PS: I don't know if the private boolean is really necessary for what I need.

That should reset, but you can enable all logging and look at the output of Logs for your rule to discover what is happening when to be sure. You also probably don't need Private Boolean, though it doesn't hurt (a switch only has two states and with most devices would never get two meaningful events with the same state in a row, so the apparent purpose here of preventing re-entry into that first "IF" is unlikely to be needed).

There are other ways this could be done (e.g., using a "Wait for event: elapsed time," which doesn't need to be explicity cancelled since a re-trigger does that for Waits on its own), but Logs are the best starting point when a rule isn't working as you expect even though everything looks correct.

1 Like

So I tried to change the rule to be as simple as possible:
image

And I got this log:

  1. At 08:46 you can see the wait time for triggering the light started
  2. At 08:47 "Cancel Delayed Actions" was fired because I turned the light switch off
  3. At 08:49 the wait time for trigger the light started again because I turned the light switch on
  4. At 08:51 the fan was turned on (five minutes after the first Delayed Actions)

Do you have anything else I could try?

You should be able to use a re-triggering of a rule to reset timers. Here is a snippet from the rule that controls the lights in our guest bathroom. There is some more logic to it because a boolean variable that makes something different happen if our kids get up in the middle of the night to go potty, but it's not relevant. The trigger of this rule is simply motion being detected in the bathroom. I personally prefer this over using delays and canceling delayed actions.

image

So you only want the fan to come on if the light is on for more than 5 minutes right?

So I would write the rule to have Bathroom Light turns on as the trigger, and no changed. The actions would be

Wait for event --> Elapsed time 0:05:00
IF (bathroom light is on)
   Turn on fan

I don't like using "changed" as a trigger. It throws away information because now you don't actually know what triggered the rule. Also, in this version, no need to cancel anything.

What about turning the fan off?

After turn on fan (not inside the IF statement, outside), you could add

IF (bathroom fan is on)
   Wait for event --> Elapsed time 0:03:00
   Turn off fan

This timer would also reset every time the rule is retriggered if the fan was currently running.

Don't want the rule to run at night? Maybe the fan is a little loud. Add a required expression of time between sunrise and sunset.

But not by this rule, otherwise you'd have an "Action:" log that said so. You must have another app doing this. Check the Events button on the device detail page for the fan to see what else might be doing this if you can't figure anything else out from other app logs. Specifically, look for "command-on" in the "Name" column and see what appears under the "Produced by" column.

Alternatively, you could look at the "In use by apps" for this device on its device detail page and see if you can figure anything out from there on your own. If you have Alexa integrated and nothing else seems to be the cause, also consider looking into the "Alexa hunches" feature and disabling that in the Alexa app on your mobile device (but "Events" should give you clues if the command came from the Alexa integration), as it can sometimes do surprising things it thinks you want.

That's a good point and I believe you are right, I had another simple rule acting on the same switch. Some other things I tried to do to fix the issue. I did a test now and it seems to be working fine now. Thanks folks!!

1 Like