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?
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) }}"
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
Anyhow I was not aware about context
existance, so interesting to dig into this too, perhaps will find some use for it!
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).
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
I know, I’m whining
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”).