Template select with state as selected option

[gabrielmazor]

I have an input_select helper for each room and one for the home, that are used as scene / mode selectors for each area, and I want to have a different icon for each selected option.

Currently, this is done by templating the icon in each card in the dashboard, but this is painful to keep it organized.

I created a template select, with all the options, and I want the state to be the last selected option. Can this be done without creating another helper for each template to keep the state?

Thanks!

[Edwin_D]

I’m not sure if this survives a restart (edit: it does not). Trigger based template sensors are supposed to remember state, but the more complicated sensor I took this from had trouble remembering. After testing this had the same problem.

- trigger:
    - trigger: event
      id: pick
      event_type: picked_something
    - trigger: event
      event_type: event_template_reloaded
    - trigger: homeassistant
      event: start
  select:
    - name: "My select"
      options: "{{['one','two']}}"
      state: |
        {%- if trigger is defined and trigger and trigger.id == 'pick' -%}
          {{ trigger.event.data.option }}
        {%- else -%}
          {{ 'one' if this.state in ['unknown', 'unavailable'] else this.state }}
        {%- endif -%}
      select_option: 
        - event: picked_something
          event_data: 
            option: "{{ option }}"
      optimistic: true

Edit: this is edited to include the restart trigger. Without it, it remains uninitialized.

[petro]

@gabrielmazor

and I want the state to be the last selected option.

post your template select code

[123 (Taras)]

@gabrielmazor

Can this be done without creating another helper for each template to keep the state?

If you want the selected value to survive a restart/reload, you need to store it in a helper.

Here’s how to configure it without a helper but the selected value will be lost after a restart/reload.

Select template

You can set it up to self reference for the state which will basically just give it an initial value…but for it to actually function, you also need to enable optimistic mode so that the state is updated by any selection events. As far as I know, the variable option is undefined outside of select_option, so there’s no point in using it in the state template: - name: "Porch Camera Day-Night Mode" unique_id: ma_lis options: "{{state_attr('select.mon_domicile', 'options') }}" state: | {{ …

[petro]

Trigger based template entities restore state as well.

[123 (Taras)]

True, instead of using one helper per Template Select, they can use one of these for all of their Template Selects.

Trigger based template sensor to store global variables

This was posted earlier here. I’ve added some improvements, mostly to avoid errors, and also added some additional stuff suggested by @erkr in this post It can happen you want to store some data to use it in another automation, or make sure it’s still available after a restart of HA. You can use helpers for that (eg and input_text entity) but these are limited in which types you can store, and they can be easily edited in the GUI. The configuration below creates a trigger based templates senso…

I have never tried it. It remains to be seen how it behaves on startup/reload when the Template integration is loaded (the Trigger-based Template Sensor would need to be restored before the Template Select is processed).

[gabrielmazor]

Awesome, this is working, thanks!
It doesn’t survive restart, but that’s alright because it is managed with an automation, that also triggers on startup.

Below is the code of my template.
But there is an new issue now. The icon is changed only for the first two selects, and getting stuck afterwards until restart. Anyone got an idea why?

template:
  - trigger:
    - trigger: event
      id: select_home_mode
      event_type: selected_home_mode
  - select:
    - name: "Home Mode"
      unique_id: "home_mode"
      icon: |
        {%- if this.state ==  'Daytime' -%}
          mdi:weather-sunny
        {%- elif this.state ==  'Evening' -%}
          mdi:weather-sunset
        {%- elif this.state ==  'Night' -%}
          mdi:weather-night
        {%- elif this.state ==  'Sleep' -%}
          mdi:sleep
        {%- elif this.state ==  'Away' -%}
          mdi:shield-home
        {%- elif this.state ==  'Guest' -%}
          mdi:kabaddi
        {%- elif this.state ==  'Basic' -%}
          mdi:auto-mode
        {%- else -%}
          mdi:auto-mode
        {%- endif -%}
      options: |
        {{ ['Daytime', 'Evening', 'Night', 'Sleep', 'Basic', 'Manual', 'Guest', 'Away'] }}
      state: |
        {%- if trigger is defined and trigger and trigger.id == 'select_home_mode' -%}
          {{ trigger.event.data.option }}
        {%- else -%}
          Daytime 
        {%- endif -%}
      select_option: 
        - event: selected_home_mode
          event_data: 
            option: "{{ option }}"
      optimistic: true

[123 (Taras)]

@gabrielmazor

It doesn’t survive restart, but that’s alright because it is managed with an automation, that also triggers on startup.

How does the automation restore the Template Select’s previous value (the value it had prior to the restart).

Or does it simply set the Template Select to a default value thereby losing its previous value?

[Didgeridrew]

When I was putting together the cookbook article mentioned in the post Taras linked above, I tried all kinds of different permutations and could never get all the features of a state-based Template Select to work reliably with a trigger. For anything but the most basic entity, the configuration became so convoluted that it just made no sense to continue trying to avoid using a helper for storage. There have been a few functional features added to template entities since my experiments, but, as far as I can tell, they would not increase the viability of trigger-based template selects.

[gabrielmazor]

@123

How does the automation restore the Template Select’s previous value (the value it had prior to the restart).

Or does it simply set the Template Select to a default value thereby losing its previous value?

It doesn’t restore it. It is just sets it based on the time of the day and whether someone is home or not.

[123 (Taras)]

@gabrielmazor

just sets it based on the time of the day and whether someone is home or not.

Is the Template Select’s value exclusively set by the automation? Or does someone (you) manually set its value on occasion?

[TheFes]

You put a dash before select:, so in your code the select isn’t connected to the trigger. You have created a trigger without any entity connected to it, and a state based select.

[123 (Taras)]

I’m using version 2025.2.1 and this is reported as an error during configuration check:

      options: 
        - one
        - two

I changed it to this:

        options: "{{ ['one', 'two'] }}"

All else remains the same as in your example.

Full code

  - trigger:
      - trigger: event
        id: pick
        event_type: picked_something
    select:
      - name: "My select"
        options: "{{ ['one', 'two'] }}"
        state: |
          {%- if trigger is defined and trigger and trigger.id == 'pick' -%}
            {{ trigger.event.data.option }}
          {%- else -%}
            {{ this.state }}
          {%- endif -%}
        select_option: 
          - event: picked_something
            event_data: 
              option: "{{ option }}"
        optimistic: true

The modification eliminated the error but the resulting options list is empty.

Just for fun, I added unique_id but it didn’t make a difference. Instead of reloading I restarted but that didn’t help either.

I’ve never used a Trigger-based Template Select before but it seems quirkier than the many Trigger-based Template Sensors I’ve created. I feel certain that I have supplied options with a correct value. Anyone know why it’s empty? Maybe I made a silly mistake but simply can’t see it.

tl;dr
The posted Solution example doesn’t pass config check. Fixing the source of the error doesn’t produce a viable Template Select.

[Edwin_D]

I modified an existing trigger based template select that uses a template to return the options and that works for me, but my edits may have introduced errors.

I did remove a trigger for home assistant restart, maybe that is needed to initialize the options?

[123 (Taras)]

I’m not sure what’s needed to make it work but, in its current form, it produces a non-viable Select entity (because no options).

[Edwin_D]

This one I tested and works. I first loaded it by reloading themplates. It’s state got reset on a restart of HA

- trigger:
    - trigger: event
      id: pick
      event_type: picked_something
    - trigger: event
      event_type: event_template_reloaded
    - trigger: homeassistant
      event: start
  select:
    - name: "My better select"
      options: "{{['one','two']}}"
      state: |
        {%- if trigger is defined and trigger and trigger.id == 'pick' -%}
          {{ trigger.event.data.option }}
        {%- else -%}
          {{ 'one' if this.state in ['unknown', 'unavailable'] else this.state }}
        {%- endif -%}
      select_option: 
        - event: picked_something
          event_data: 
            option: "{{ option }}"
      optimistic: true

Edit: if I remove the startup trigger, there are no options and the state is unknown after a reboot. So it needs the startup trigger to initialize.

[123 (Taras)]

I tested it and can confirm that version populates options.

Ideally it would not lose its state after a restart/reload but storing/restoring the state is limited to Trigger-based Template Sensor/Binary_Sensor.

From the docs:

The state, including attributes, of trigger-based sensors and binary sensors is restored when Home Assistant is restarted. The state of other trigger-based template entities is not restored.

Given that a Trigger-based Template Select currently offers no additional functionality compared to its simpler cousin, the Template Select, my preference would be to use a Template Select. Plus it’s easy to set a default option value.

The following example is based on Didgeridrew’s example (link posted above).

select:
  - name: "My Select X"
    options: "{{ ['one', 'two', 'three', 'four'] }}"
    state: "{{ this.attributes.options[0] | default('None', true) }}"
    optimistic: true
    select_option:
      - service: select.select_option
        target:
          entity_id: select.my_select_x
        data: 
          option : "{{ option }}"

---

The OP’s Template Select would look like this:

- select:
    - name: Home Mode
      unique_id: home_mode
      icon: |
        mdi:{{ {
          'Daytime': 'weather-sunny',
          'Evening': 'weather-sunset',
          'Night': 'weather-night',
          'Sleep': 'sleep',
          'Away': 'shield-home',
          'Guest': 'kabaddi',
          'Basic': 'weather-night',
          'Sleep': 'auto-mode'}.get(this.state, 'auto-mode') }}
      options: |
        {{ ['Daytime', 'Evening', 'Night', 'Sleep', 'Basic', 'Manual', 'Guest', 'Away'] }}
      state: "{{ this.attributes.options[0] | default('None', true) }}"
      select_option:
        - service: select.select_option
          target:
            entity_id: select.home_mode
          data: 
            option : "{{ option }}"
      optimistic: true

NOTE

This Template Select exhibits the same problem mentioned by gabrielmazor. After you make two selections, the icon stops changing.

[Edwin_D]

I think I tried something like this first, but I could not get it to accept a new value. The developer tools kept showing the old state. I figured that was because the state template always returns the first option. That is why I changed it to a trigger based one to allow the state template to return the option that was chosen in the UI. I did not think I could use the select_option service, because I thought that would equate to an endless loop. Might that be why a second change no longer works?

[Edwin_D]

LOL, I tried my sample with an icon template. It works all the time,… kind of. It is always one state behind if I use this.state. That is rather useless… One might consider it a bug. How would you ever have the right icon then?

EDIT: I can ‘fix’ it by also listening to state changes. But it isn’t a pretty sensor anymore that way. The fixed sensor below, remove the state trigger and watch the icon running behind.

- trigger:
    - trigger: event
      id: pick
      event_type: picked_something
    - trigger: event
      event_type: event_template_reloaded
    - trigger: homeassistant
      event: start
    - trigger: state
      entity_id: select.my_select
      to: null
  select:
    - name: "My select"
      options: "{{['one','two', 'three']}}"
      state: |
        {%- if trigger is defined and trigger and trigger.id == 'pick' -%}
          {{ trigger.event.data.option }}
        {%- else -%}
          {{ 'one' if this.state in ['unknown', 'unavailable'] else this.state }}
        {%- endif -%}
      icon: "{{ 'mdi:clock-time-' + this.state | string }}"
      select_option: 
        - event: picked_something
          event_data: 
            option: "{{ option }}"
      optimistic: true  

[123 (Taras)]

@Edwin_D

Might that be why a second change no longer works?

I doubt it. The select.select_option action successfully sets the Template Select’s state each time.

@Edwin_D

It is always one state behind if I use this.state.

this.state is the entity’s existing state value (i.e. before the entity’s state template is processed).

From the docs:

Note

Self-referencing using this provides the state and attributes for the entity before rendering the templates to calculate a new state. To access the new state, use the value or value_json variable.

You can try this (untested):

icon: "mdi:clock-time-{{ trigger.event.data.option }}"