Hi all, not sure if this is a 2022.6.0 issue or I’ve just managed to get this to work for a total of 12 hours…
I’ve got a Symfonisk volume controller from Ikea running through Zigbee2MQTT. It outputs an action when rotated or clicked e.g. ‘rotate_right’ which I then use to trigger a volume up on my Sonos.
This is the first time I’ve used Choose as an action and it worked last night with this code.
This morning having done the 2022.6.0 update no longer working.
I’ve done the 2022.6.1 in case there was anything in that (as I saw there’s some MQTT fixes) but still the same problem. Has anyone a similar setup or any explanation as to why this wouldn’t work?
Thanks @tom_l, unfortunately the trace isn’t really showing anything. It appears in the split second between the action triggering the automation and the choose actions taking place the state has defaulted back to ‘off’
I assumed that Choose took the state from the trigger as opposed to the state at the time that it gets to the Choose check, is that not the case?
I’m wondering about a helper that updates the last state before the ‘rotate_stop’ command is received might be the answer. Just weird it was working before the update.
If the state can change that quickly (between the trigger and the condition), perhaps inspect the trigger object directly in the condition. It will have the info at the time of the trigger and not some ms later.
otherwise, you’re relying on the state to be the same after it triggers. If the sensor is an event stream, you could run into issues where the state changes while the automation is running.
Thank you, I’d fundamentally misunderstood how the states were being used as part of the Choose option. Looks like my Home Assistant was just updating sufficiently slowly for it to work last night!
It would be interesting to learn what changed in 2022.6.0 that caused the change in behavior.
Using a State Condition like this is fine:
- condition: state
entity_id: sensor.soundcontrol_action
attribute: action
state: rotate_right
I’ve seen other examples do the same (even though my preference would be to use the trigger variable).
Thinking out loud:
Perhaps it’s due to a tiny delay between when the trigger variable is updated (when the trigger occurs) and when that new value is written to the state-machine (that’s where the State Condition gets the entity’s value).
A choose relying on anything that gets its value from the state-machine, like a State Condition, will be getting a slightly older version than what is contained in the trigger value.