Input Select bug? HA mixes up values at startup

Configuration
12

Yeah, sounds like you found a bug. Chuck a bug report on GitHub :+1:

13

Hmm…
It also takes the first option “Av” from the second input_select as an input to you first input_select. Also wrong.
But at least there is some kind of logic in that.

Yeah, probably time for a bug report.

14

Easily resolved however:
1: Temporarily remove your Input_select from configuration.yaml
2. Restart
3: Put the code back
4. Restart.

1 Like
15

I’ve got the same issue and following these steps didn’t resolve it for me. Any pointers?

16

I ended up with a different setup: Restore state and automations only work if I don't restart from Hass.io-menu

The solution may seem a little bit unnecessary complex, but it has worked for a couple of months now, so I’ll stick with it.

I think the main problem was the restore_state that restored an incorrect value, but I haven’t dug any deeper into it since it works now.

17

I’m seeing this error too.

I have two completely unrelated input selects and warnings in the home assistant log that that options for one input select are invalid for the other. I’ve been over all my automations and scripts and I only have valid options for the input select set value service calls.

Was an issue ever created?

WARNING (MainThread) [homeassistant.components.input_select] Invalid option: Bright (possible options: Default, Midnight, Solarized Dark)

Input selects:

select_theme:
  name: Select Theme
  options:
   - Default
   - Midnight
   - Solarized Dark

Automations:

- id: select_theme
  alias: 'Select Theme'
  hide_entity: true
  trigger:
    - platform: state
      entity_id: input_select.select_theme
    - platform: homeassistant
      event: start
  action:
    service: frontend.set_theme
    data_template:
      name: >
        {% if is_state('input_select.select_theme', 'Default') %}
          default
        {% elif is_state('input_select.select_theme', 'Midnight') %}
          midnight
        {% elif is_state('input_select.select_theme', 'Solarized Dark') %}
          solarized_dark
        {% else %}
          default
        {% endif %}

And

- id: set_dark_theme_at_sunset
  alias: 'Set Dark Theme At Sunset'
  trigger:
    platform: sun
    event: sunset
  action:
    service: input_select.select_option
    data:
      entity_id: input_select.select_theme
      option: Midnight

- id: set_light_theme_at_sunrise
  alias: 'Set Light Theme At Sunrise'
  trigger:
    platform: sun
    event: sunrise
  action:
    service: input_select.select_option
    data:
      entity_id: input_select.select_theme
      option: Default
18

No, I never raised an issue. So please do if you can re-create the issue.

19

I’ve performed a couple more restarts today and have not been able to reproduce the issue.

20

Saw this in the log this morning:

Invalid option: Forest (possible options: Off, Powerful Heat, Normal Heat, Silent Heat, Powerful Cool, Normal Cool, Silent Cool)

Again, Forest is an option for a completely unrelated input_select and nowhere in my automations do I try to select it as an option for the air-conditioner input_select.

I have opened an issue for this: https://github.com/home-assistant/home-assistant/issues/19810

21

I had HA in debug logging mode for a few days to try and capture one of these errors but as Murphy would have it nothing happened and debug logging was thrashing my SD card so I had to reduce the logging level.

To work around this problem I am going to add a template condition to all my automations that change input selects to ensure the option is valid.

e.g.

- id: logging_level
  alias: 'Logging Level'
  initial_state: true
  hide_entity: true
  trigger:
    platform: state
    entity_id: input_select.logging_level
  condition:
  - condition: template
    value_template: "{{trigger.to_state.state in ['error', 'warning', 'info', 'debug'] }}"
  action:
    service: logger.set_default_level
    data_template:
      level: "{{ trigger.to_state.state }}"
22

If you want to use this with other input selects, you could modify the condition this way.

  condition:
  - condition: template
    value_template: "{{ trigger.to_state.state in state_attr(trigger.entity_id,'options') }}"

This way, it will always work and you don’t have to hard code the options.

1 Like
23

Ugh. I hard coded them all this afternoon!

Thanks though. I’ll change the conditions to your version at some stage. Makes it easier if I ever update any of the input selects options.

24

yah, i hate hard coding things for that reason alone

25

Done. It wasn’t that hard with find/replace.

Interestingly I just saw this error on start up:

Error during template condition: UndefinedError: 'dict object' has no attribute 'to_state'

My input select automations do seem to be working and are not creating more of these errors.

I wonder if this strange input_select bug is being caused by some input_select not being ready before being called in an automation after a restart?

26

That’s possible. You may need to add another check to verify that the trigger platform is ‘state’. I’m willing to bet that HA does some funky things during startup and maybe some bad triggers get sent.

27

I’m not sure what you mean by this. Do you mean checking the trigger_to_state.state for ‘undefined’?

28

That could also work if the trigger truely isn’t defined.

But what I meant was:

trigger.platfrom == 'state'
29

I have to admit I have no idea what that is actually checking.

30

So, it’s checking the trigger object itself. Triggers are just like the data section, accept they have different data. In fact, pretty much all data passed in home assistant look’s like the data section for actions. Pretty much all state objects have attributes inside attributes etc. You just gotta know what to look for. Luckily alot of this is spelled out in the docs, it’s just burried inside areas that people don’t understand.

this pretty much shows the shape of all trigger objects:

which references state objects alot, so heres that documentation:

So, looking at that documentation, if we have this as our trigger:

trigger:
  - platform: state
    entity_id: switch.something

then our trigger will look like this, and we can access it all:

What the data would look like if it was written as a dictionary

trigger: {
  'platform': 'state',
  'entity_id': 'switch.something',
  'from_state': {'state':'off', 'attributes':{'attr1':'value'}},
  'to_state': {'state':'off', 'attributes':{'attr1':'value'}},
  'for':{'hour':0,'minute':0,'second':0}}

So when the trigger is passed to us we have access to all that. Typically you see people only looking at to_state and from_state. But we can look at everything.

to look at it all, we use dots. so…

trigger.platform #returns 'state'
trigger.entity_id #returns 'switch.something'
trigger.for.hour #returns 0
trigger.to_state.state #returns 'off'

etc

31

Even with that condition in all automations that change input selects I’m still getting the occasional warning in the log and today I saw this when I went to manually change an input select:

rumpus_ac_mode:
  name: Rumpus Room Aircon Control
  options:
   - 'Off'
   - Powerful Heat
   - Normal Heat
   - Silent Heat
   - Powerful Cool
   - Normal Cool
   - Silent Cool
  icon: mdi:format-list-bulleted

Someone needs to have a serious look at the input_select.select_option service.

EDIT:

Or maybe I need to check my code more closely, this is wrong but would it cause the above problem?

  action:
    - service: input_select.select_option
      data_template:   ### <-------------- Lazy copy / paste error
        entity_id: input_select.rumpus_ac_mode
        option: 'Off'

Time will tell. I’ve fixed it and reloaded my automations.

EDIT 2:

Nope. Still happening:

389×600 70.8 KB