Trigger Based Select: select_option not firing

Configuration
1

I’m playing with a template select entity to hold a value for a cetain amount of time before reseting to default value. The idea is to trigger it with an event that contains a new value and then use select_option: to check if the trigger contains the default value, and if not run a script that waits and then fires an event with the default value. However the select_option: doesn’t seem to go off.

I’ve managed to work around this using an action: after the trigger, but I’m baffled by the behaviour of select_option:, hoping for some insight on this.

Admitedly it took me a bit to realise that select_option: is for selecting an option, however should it not still run the actions defined there?

How I expected it to work:

template:
  - unique_id: access_request_user
    trigger:
      - trigger: event
        event_type: user_access_request
    select:
      - name: Access Request User
        unique_id: f5ea3a02-5c00-4828-aa8f-61a88c114735
        state: "{{ trigger.event.data.user }}"
        options: "{{ ['None', 'Owner', 'User 1', 'User 2', 'User 3'] }}"
        select_option:
          if: "{{ not trigger.event.data.user is equalto 'None' }}"
          then:
            - delay: 15
            - event: user_access_request
              event_data:
                user: 'None'
            # Also tried replacing above with calling a script to handle the delay and event, 
            # script never activated
            - action: script.turn_on
              target:
                entity_id: script.access_request_timeout

My work around, since select_option: is required I left a dummy event in there that I could listen for… it never fires.

template:
  - unique_id: access_request_user
    trigger:
      - trigger: event
        event_type: user_access_request
    action:
      if: "{{ not trigger.event.data.user is equalto 'None' }}"
      then:
        action: script.turn_on
        target:
          entity_id: script.access_request_timeout
    select:
      - name: Access Request User
        unique_id: f5ea3a02-5c00-4828-aa8f-61a88c114735
        state: "{{ trigger.event.data.user }}"
        options: "{{ ['None', 'Owner', 'User 1', 'User 2', 'User 3'] }}"
        select_option:
          if: "{{ not trigger.event.data.user is equalto 'None' }}"
          then:
            - event: test_select
              event_data:
                option: "{{ option }}"

Any insight would be appreciated, thanks.

2

Functional trigger-based Template Selects are quite new, so I haven’t had time to explore them as much as the state-based variety…

The configuration variable select_option holds a list of actions to execute when a new option is selected either from the frontend or through a script action… Based on how the state-based version has always worked, I would not expect the trigger to also fire the action in select_option.

3

This is an automation, not a template select.

Template select serves 1 purpose and 1 purpose only: Creating a select entity that can be used in the UI & in automations.

Notes about template select entities:

  1. The state is based on the template.

  2. Select option only occurs when the select_option service is called or the entity is used in the UI.

  3. There is no automated functionality that will cause the trigger to run the select_option action.

4

So, what gets updated with the trigger event? Just the state and options? What about a variables block… do variables get updated and stored so that the updated values are usable in select_option actions?

5

Variables get resolved when a trigger occurs. They are stored every time a trigger occurs and they get passed to the service whenever the service needs to be executed.

It’s a caching system basically

6

I think I understand… maybe. I had assumed that because select_option: is required that it was always used. action: select.select_option does make use of it and the actions within do indeed go off.

Thanks!

7

select option is required because the minimum entry for a select entity is a list of options with an action to change the current selected option.

The state is also required, but that’s an oversite IMO and I will likely correct that in the future. I.e. make it optional, when not provided the entity will be optimistic.

1 Like
8

Yes, I was hoping to keep the functionality in one spot rather than using an input_select and an automation, and it does serve the purpose even if that’s not its purpose.

9

You could trigger off the state of the select itself to get your reset behavior:

  - trigger:
      - trigger: state
        entity_id: select.self_resetting_select
        not_to: 'Default'
        for: '00:01:00'
        id: default
      - trigger: homeassistant
        event: start
        id: default
      - trigger: event
        event_type: custom_select_event
        event_data:
          entity_id: select.self_resetting_select
        id: selection
    select:
      - name: Self-Resetting Select
        optimistic: true
        state: "{{ 'Default' if trigger.id == 'default' else trigger.event.data.option|default('Default',1) }}"
        options: "{{ ['Default','Option_1','Option_2','Option_3']  }}"
        select_option:
          - event: custom_select_event
            event_data:
              entity_id: "{{this.entity_id}}"
              option: "{{option}}"
10

Hadn’t though of that, works a charm. I already had the homeassistant start event in an automation as I also needed to catch event_template_reloaded, which of course can’t work inside a template that’s being reloaded.

Again, thank you :grinning: