I am trying to get a sticky trigger to work when multiple devices are selected for a given attribute (any) and I am failing to see the behaviour I expect. Imagine a sticky trigger tracking the "switch" attribute of devices A and B. What I'm seeing is that a first event from device A will start the "stays" timer. Another event from device B coming in during the stays timer effectively resets that timer. If device B fails to stay, the trigger fails.
I am seeing this behaviour in both Basic Rule and Rule Machine. I am also seeing a similar behaviour with Wait for Events actions (Simple Automations gives a slightly different result for some reason, only the timer resets, not the trigger).
Is this the expected behaviour? The documentation is not explicit about this scenario.
Here is a test rule to demonstrate the behaviour in question:
In this example, "Virtual Switch 1" will turn on and stay on for more than 30 seconds, but because Virtual Switch 2 will turn on and back off during the "stay" period, the Wait will fail to complete and ultimately time out.
Is this behaviour as designed ? I was expecting "any" of the devices staying for the whole period satisfying the wait/trigger.
Turns out that if any of the switches that are part of the wait have an on-to-off transition during the stays timer, it will fail, even if the switch that started the stays timer actually... stays.
The application of "any" in this context means any event from the list of devices; it's not making the distinction of the first device vs any device.
I believe you could accomplish the behavior you want (separate sticky trigger period for each switch) by having a separate sticky trigger rule for each switch, then an action for each of the separate rules to fire (trigger) your main rule.
1 Like
So, “any” is treating the events from all devices in the list as though they are from one “aggregate” device. The only difference between “any” and “all” for sticky waits/triggers is on the stay timer start condition: any can turn on, but all must not turn off. Not what I need but at least that’s clear.
I think you are right in the case of sticky triggers. Thank you for the suggestion.
For sticky waits, I think I’ll have to write my own virtual sensor aggregation driver.
1 Like
Looks like splitting up the devices each in their own event with stay doesn't change the behaviour. Good to know, but then the wait action doesn't read the way it works:
