Know which trigger triggered the rule?

Maybe, but you would at least need to prevent multiple executions of this in parallel for a rule that runs over a duration of time. Wouldn’t you ? It also means that if something change the switch state while the wait is happening, it… screws it up ?

I prefer having the waits before the trigger, and the rules to be instantaneous, rather than having the rule last a long duration and have to deal with concurrency within the rule execution

A trigger will cancel any waits. I'm not sure what concerns you would have for simultaneous execution based on that, or what you mean with "Wait before trigger" since you cannot start running rule actions (including waits) without a trigger.

Nothing is stopping any other app from running commands on your virtual switches, but that is true no matter what approach you take. But this rule doesn't care what the state of the virtual switch is--it just sends the commands specified by the actions.

See also:

Another idea: create such a rule, enable all logging, and see if it does what you want or could be modified to do so. :slight_smile: (Maybe don't use your "real" devices if you have concerns--or other apps/rules that would change their state.)

1 Like

Do you mean because the wait is on the same device ? Or do you mean that in general that if a rule is triggered while the same rule is running, any wait event will be cancelled ? That’s highly counterintuitive

You may want to read the document I linked to.

Any trigger event for the rule, regardless of whether it is the same as any device in your actions or whether it's a device at all, will cancel any "Wait" actions.

5 Likes

Ok, I learned something about wait events. Interesting, and it will simplify some of my rules. It does not address the other types of multiple triggers, but it is indeed helpful in that specific situation. Thanks

3 Likes

What do Wait statements (event or expression) do in case of a hub reboot ? Does it keep waiting in the rule upon reboot ?

Edit: I found the answer here Is there documentation on what type of wait events survive a hub reboot? - #11 by bravenel