Device Automations not consistently turning on or off all zwave devices

@jtp10181 There are subtle differences in doing a "Delay 2 sec" vs "wait for event - elapsed time 2 sec" vs. adding a "delay 2 sec" to each command.

From this link: [2.2.7.125] Rule Machine Using Delay vs Delaying an action - #4 by bertabcd1234

@bertabcd1234 said:

All "Waits," including "Wait for events: elapsed time," are cancelled if the rule re-triggers. I've started to use these in most cases over delays because it's almost always what I want, whereas delays must be explicitly cancelled (with the most common method being to mark them as "cancelable" and use a "Cancel Delayed Actions" somewhere else in the rule). Otherwise, they are quite similar to a standalone "Delay" action--which, as discovered above, is different from the delay option you can use on an action. A delay on an action schedules that particular action for the specified time in the future, then continues on with the next action instead of waiting there.

It seems the "wait for event/elapsed time" is most likely the best way for most situations (it will automatically cancel itself if the rule gets triggered again).

If you have a "Delay xx secs" and the rule gets triggered again, you can end up with the rule sorta running two places at the same time (in a very simple rule with no conditions/loops/etc), that might work--but it can really gum things up and create "unpredictable results" in a lot of cases. You need to make sure those delays have "Cancelable" selected & you need to do a manual cancel of the delayed actions to force things to stop.

If you put a "delay" on a command, that simply schedules that one command to run at some later time--but the rest of the rule keeps running without any delay. And, unless the other delays are cancelled manually, they will still run even if the rule is re-triggered.

Hope that makes some sense (and that I got it right lol)

6 Likes