Populating input_select at startup unnecessary triggers automation

Configuration
1

I have simple automation that at HA start populates options of input_select with list of available effects from twinkly integration. Unfortunately updating the list with actual values also causes automaatic selection of the first item on the list to be active and thus triggers change of input_select state, (which is unwanted). This in consequence triggers another automation that pushes new selection to twinkly integration and turns the light on and changes prior selection (it is impossible to change selected scene in twinkly without powering light on and is also unwanted).
This can be solved by adding 2 helpers to preserve power status and selected effect prior to updating the list of available effects and reapplying these at the end of automation. But I think it not elegant solution and will cause twikly lights to flash briefly at HA restart.
So is there any other way to resolve this? Ideally input_select should retain previously applied selection if it exists in new set of options, but unfortunatelly input_select from definition in config is static (options are mandatory definition parameter and are unknown as this changes dynamically in twinkly setup).
Any other solutions to avoid such behavior?

2

Have you created the input_select through the UI or in configuration.yaml? If the latter, make sure you do not have the initial key configured. Without the key HASS should restore its last value on reboot, but if the key is set, and its value does not exist as an option, then I guess it would automatically pick the first option.

I have been looking into how context works the last couple of days. You may be able to use it to identify whether it was the automation itself that last changed the state of the input_select, but that depends on how HASS handles that state change when it resets to the first available option.

One of these conditions may be the solution you’re looking for, but you’ll have to try them and/or inspect the different values of context in real time to know for sure:

conditions:
- "{{ states['input_select.my_entity'].context.id != states[this.entity_id].context.id) }}"
- "{{ states['input_select.my_entity'].context.parent_id != states[this.entity_id].context.id) }}"
- "{{ states['input_select.my_entity'].context.parent_id != states[this.entity_id].context.parent_id) }}"
1 Like
3

Magnus, here is m y code:

input_select:
  twinkly_effects:
    name: Twinkly Effects
    options:
      - None
automation:
- id: 'update_twinkly_effects_list'
  alias: Update Twinkly Effects List
  mode: queued
  initial_state: true
  trigger:
    platform: homeassistant
    event: start
  actions:
    - action: input_select.set_options
      target:
        entity_id: input_select.twinkly_effects
      data:
        options: |
          {{ state_attr('light.strings', 'effect_list') | list }}

and actual value of input_select.twinkly_effects:

options:
  - 0 fireplace
  - 1 Sparkles
  - 2 Carnival
  - 3 Wed. Day Blues
  - 4 Rasta
  - 5 My Bright Tribe
  - 6 Flare
  - 7 Night Sky
  - 8 Candy Cane
  - 9 Diagonal
editable: false
friendly_name: Twinkly Effects

So while I do not have initial option set, in definition of helper I can’t provide actual list, but have to provide something, as otherwise setup of helper fails. If I remove suggested options list I get error:

Configuration warnings
Invalid config for 'input_select' at configuration.yaml, line 1246: required key 'options' not provided

So perhaps value of helper is preserved on restart, but only if list is not changing. Which is not my case. So perhaps adding 2 helper is the simplest solution :man_shrugging:
Anyhow I was not aware about context existance, so interesting to dig into this too, perhaps will find some use for it!

4

Add a “do nothing” choice as the first option in the input_select’s list.

For example:

data:
  options: |
    {{ ['None'] + state_attr('light.strings', 'effect_list') | list }}

Modify your automation so that it ignores the input_select’s state-change to "None". If it’s using a State Trigger, you can use the not_to: option. Or you can use a State Condition if you prefer.

If you want to save the previously selected effect then, yes, you’ll need to store it in an Input Text helper (in order to survive a restart). If you wish, you can use one helper to store both the effect’s name and the light’s state (just separate the two with a comma).

5

Well, that would work… but will add unwanted None option to the list of available options, that will be later available in UI, but will be invalid :slight_smile:
I know, I’m whining :wink:

6

It’s a “no effect selected” option.

If you wish, you can even use it as a means of turning off the light (i.e. name it “Off”).

7

Just wanted to comment (almost a year later) that HA does not set the select to the first item when updating the select options. It only does that IF the current state is not one of the possible selects. HA will log this if it happens:

2025-11-02 07:45:54.385 WARNING (MainThread) [homeassistant.components.input_select] Current option: Two no longer valid (possible options: One, Three, Xxx, Five)

HA will also reset the current state on restart (or YAML reload for a yaml helper), if there’s no matching option, but it won’t log that issue and will set the select’s state to “unknown”.

But, I do think there is a real bug, although not sure if there can be a fix:

The “options” are a required configuration AND when HA restart (or reloads the yaml), it resets that option list.

There’s the input_select.set_options action, so we know it’s possible to change the default options. And that updated list is stored in .storage/core.entity_registry.

On restart, HA should restore those options – otherwise the current state cannot be set because it may not match the freshly-loaded default options.

The problem, of course, is you need to define the default options when creating the input_select. I guess HA could look at core.entity_registry when restarting, but explicitly reloading the input_select YAML would seem like you want to refresh the options. :person_shrugging:

Note that even if the option order changes (e.g. from [‘One’, ‘Two’, ‘Three’] to [‘Three’, ‘One’, ‘Two’] and the state is “Two”, on restart/reload the state will be maintained because “Two” is still a valid option.

Anyway, not restoring the last options means you have to do unusual things to bring back the state after a restore.