Choose automation - was working, isn't working after Core update

Configuration
1

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?

alias: SoundRemote
description: ''
trigger:
  - platform: state
    entity_id:
      - sensor.soundcontrol_action
    attribute: action
condition: []
action:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.soundcontrol_action
            attribute: action
            state: rotate_right
        sequence:
          - service: media_player.volume_up
            data: {}
            target:
              entity_id: media_player.living_room_sonos_4
      - conditions:
          - condition: state
            entity_id: sensor.soundcontrol_action
            attribute: action
            state: rotate_left
        sequence:
          - service: media_player.volume_down
            data: {}
            target:
              entity_id: media_player.living_room_sonos_4
      - conditions:
          - condition: state
            entity_id: sensor.soundcontrol_action
            attribute: action
            state: play_pause
        sequence:
          - service: media_player.media_play_pause
            data: {}
            target:
              entity_id: media_player.living_room_sonos_4
      - conditions:
          - condition: state
            entity_id: sensor.soundcontrol_action
            attribute: action
            state: skip_forward
        sequence:
          - service: media_player.media_next_track
            data: {}
            target:
              entity_id: media_player.living_room_sonos_4
      - conditions:
          - condition: state
            entity_id: sensor.soundcontrol_action
            attribute: action
            state: skip_backward
        sequence:
          - service: media_player.media_previous_track
            data: {}
            target:
              entity_id: media_player.living_room_sonos_4
    default: []
mode: single

Thanks in advance.

2

Also, works normally when not using choose (i.e. one state trigger and one action) but I’d rather have one automation than 5.

3

There’s nothing wring with the choose action (I use it extensively and it is still working). Use the automation trace to see what is happening:

4

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?

5

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.

6

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.

1 Like
7

You don’t necessarily need a choose and you aren’t using the information that’s coming from your trigger. FWIW, without choose you can use templates:

alias: SoundRemote
description: ''
trigger:
  - platform: state
    entity_id:
      - sensor.soundcontrol_action
    attribute: action
variables:
  actions:
    rotate_right: media_player.volume_up
    rotate_left: media_player.volume_down
    play_pause: media_player.media_play_pause
    skip_forward: media_player.media_next_track
    skip_backward: media_player.media_previous_track
  service: "{{ actions.get(trigger.to_state.attributes.action) }}"
condition:
- condition: template
  value_template: "{{ service is not none }}"
action:
- service: "{{ service }}"
  target:
    entity_id: media_player.living_room_sonos_4

But if you want to use choose, your conditions would look like:

      - conditions:
          - condition: template
            value_template: "{{ trigger.to_state.attributes.action == 'rotate_right' }}"

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.

1 Like
8

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!

9

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.

10

Home Assistant got faster? :slight_smile:

1 Like
11

I don’t think anything changed. I think he was in a race condition and it intermittently worked correctly.

1 Like