Input Select bug? HA mixes up values at startup

Configuration
9

Yes and no. I’m more of a Windows kind of guy so i use Samba ang Notepad++.
But I searched for all occurrences of “Morgonbelysning PÅ” (from the log) and changed the spelling in the automation files to all lowercase just to see from where it originated.

I have spent most of the afternoon on this, but I still can’t explain how it occurred.

What I know is this:
I moved all my automation files to another drive.Then I restarted hass.io (several times just in case), checking the log after each restart. No errors. Then I took my automation files and searched and replaced the old name “heater_entryfloor” with “heater01”. Moved all files back. Restarted. And BAM. No error in the log, Everything works as expected.

I can’t explain why it works now. Best guesses:
Something about underscore in the name? Any relation to swedish letter “ä” in en friendly name? Some mix-up in the resume state-function?

I have the old files in a backup if you want them for deeper analysis, but I’m fine now and my log is clean and good looking again :slight_smile:

1 Like
10

Ha, I’ll pass on going through your old config :stuck_out_tongue_winking_eye:

Glad you got sorted :+1:

11

Just because I’m curious I just had to keep trying.
And yes, I managed to re-create the error.

I added a new option “Alla lampor av” to the input_select.lights01 and reloaded Scripts and Automations. I had no automation calling this new option, but still I got an error in the log. And after restart - it’s back.

Once again with reference to wrong input_select (which is what is really strange):

2018-01-23 21:14:21 WARNING (MainThread) [homeassistant.components.input_select] Invalid option: Morgonbelysning av (possible options: Av, 22 grader auto, 24 grader auto, 24 grader max, 24 grader tyst)

The “Morgonbelysning av” is a reference to was previously was the first option in the input_select.
After my addition, “Alla lampor av” is the first option.

So if I try to create an explanation:
If you add a new option to an input_select and then reload scripts and/or automation, hass.io suddenly think that the previously first option in your first input_select belong to your other input_select. Which it doesn’t, and therefore it produces an error.

Phew. It doesn’t seem very likely, but now it has happened twice.

Now I know how to get rid of it, but it still seems like it would be worth investigating.

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'