Can't restart due to Invalid Configuration

pcal · January 22, 2022, 7:07am

Hi guys,

I’m running 2021.12.7 in a Docker image on a Qnap. It has only been up for a little over a week, and I’m still climbing a steep learning curve.

I’ll offer a little more background than I usually would for this error, because I’m not sure which bit of it may be relevant…

I’ve added a new Shelly Uni to my Garage door control unit to read the state of a spare button on the existing RF door remote, and give me a HA means of triggering the door. (I’ll probably use the other Uni output to drive a piezzo for audio feedback in the garage - but that is for a later project.) The hardware install is all ok and seems to be working. I’ve been playing with an automation to use data from the spare door remote signal, to switch on the flood lights that illuminate the drive way up to the garage. It all seemed to be going well, with everything doing as I expected it should after a couple of tweaks.

Then I noticed that TTS announcements were not happening. I use a helper variable to track the state of TTS outputs, so one does not get triggered until the previous one has completed and cleared. Sometimes, something goes wrong and the variable doesn’t get reset when a TTS announcement is finished, at which point no other announcement will start.

So I built a simple little automation to trigger if the helper boolean stayed in the “on” state for more that 5 minutes, and if so to run a script that would reset the helper variable, and stop the script that manages TTS message output.

alias: tts watchdog
description: ''
mode: single
trigger:
  - platform: state
    entity_id: input_boolean.speaking
    to: 'on'
    for:
      hours: 0
      minutes: 5
      seconds: 0
condition: []
action:
  - service: script.reset_announcements

alias: reset announcements
sequence:
  - service: input_boolean.turn_off
    target:
      entity_id: input_boolean.speaking
  - service: script.turn_off
    target:
      entity_id: script.speak
mode: single
icon: mdi:alarm-light

I saved this automation, but it did not appear in the list. So I created it again. Again it did not appear in the list. Both times I had called it “tts watchdog” - and wondered if I may have stumbled upon a reserved name or some such thing. So I created it a third time under a completely different name, and again it did not appear in the list of Automations.

Thinking there was “something weird” going on, I attempted a restart - and got an error indicating an invalid configuration. So I fired up the Text Editor in the Qnap and opened the automations.yaml at which point I found all three of the attempts at the automation above were saved in the file under different ID numbers. So I manually deleted all three from the yaml and saved it thinking I had solved the problem.

Alas, I am still getting an error when attempting to restart, and the log file is pointing to a whole lot of python that is beyond my current skill set…

Logger: homeassistant.helpers.check_config
Source: components/shelly/utils.py:174
First occurred: 4:15:17 PM (8 occurrences)
Last logged: 5:34:52 PM
Unexpected error validating config

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/check_config.py", line 161, in async_check_ha_config_file
    await config_validator.async_validate_config(  # type: ignore
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 129, in async_validate_config
    await asyncio.gather(
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 106, in _try_async_validate_config_item
    config = await async_validate_config_item(hass, config, full_config)
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 74, in async_validate_config_item
    config[CONF_TRIGGER] = await async_validate_trigger_config(
  File "/usr/src/homeassistant/homeassistant/helpers/trigger.py", line 50, in async_validate_trigger_config
    conf = await platform.async_validate_trigger_config(hass, conf)
  File "/usr/src/homeassistant/homeassistant/components/device_automation/trigger.py", line 26, in async_validate_trigger_config
    return await getattr(platform, "async_validate_trigger_config")(hass, config)
  File "/usr/src/homeassistant/homeassistant/components/shelly/device_trigger.py", line 100, in async_validate_trigger_config
    input_triggers = get_block_input_triggers(block_wrapper.device, block)
  File "/usr/src/homeassistant/homeassistant/components/shelly/utils.py", line 174, in get_block_input_triggers
    if not is_block_momentary_input(device.settings, block):
  File "/usr/local/lib/python3.9/site-packages/aioshelly/block_device.py", line 272, in settings
    raise AuthRequired
aioshelly.exceptions.AuthRequired

 Logger: homeassistant.components.homeassistant
Source: components/homeassistant/__init__.py:160
Integration: Home Assistant Core Integration (documentation, issues)
First occurred: 4:15:17 PM (4 occurrences)
Last logged: 5:34:52 PM
The system cannot restart because the configuration is not valid: Unexpected error calling config validator:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/homeassistant/__init__.py:170
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 4:15:17 PM (4 occurrences)
Last logged: 5:34:52 PM

    [140050818282544] The system cannot restart because the configuration is not valid: Unexpected error calling config validator:
    [140050812944736] The system cannot restart because the configuration is not valid: Unexpected error calling config validator:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 185, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1495, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1530, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 733, in admin_handler
    await result
  File "/usr/src/homeassistant/homeassistant/components/homeassistant/__init__.py", line 170, in async_handle_core_service
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: The system cannot restart because the configuration is not valid: Unexpected error calling config validator:

Please, can someone tell me what is going on, and more importantly, how to fix it?

pcal · January 23, 2022, 3:58am

I’ve tried swapping out each of the .yaml files in /config with their pair from by backup folder, but none of them made any difference to the issue.

I can only assume something happened inside the container - and I’m not aware of even having access to that, let alone any understanding of it.

I’m tempted to shut down the container and reboot it, or alternatively to delete it altogether and reinstall a new copy (keeping /config intact), but if I have invalid config somewhere, could this result in a down system that never comes up again?

I even tried running a whole new installation in a VM (again on the qnap) at a different IP address. Never got to the point of registering the device integrations on the new install, as I could not find the location to copy the /config files to.

In a bit if a bind here. Next step if I can’t get the configuration right is I may have to start taking hardware out to reinstate the old fashioned way thing used to work…

pcal · January 23, 2022, 5:06am

OK. I still have no idea what happened or why, but deleting the docker container and building a new one did fix the issue and restore normal operation.

pcal · May 9, 2022, 11:09am

This worked for a while, but no longer…

The Docker image seems to have been running ok (at least the automations run like they should most of the time), but almost always when I want to make any adjustments saving is not possible because of the “unexpected error”, so I have been loading the Container Station in the Qnap - stopping and restarting the container whereupon the Configuration check as valid again and everything works.

This evening I had gone through this now routine procedure, and the configuration had tested as valid, when she that must be obeyed called that dinner was ready. One meal break later while the system had not been touched, and to the best of my knowledge no automation had been triggered it was again invalid with the unexpected error. However this time, restarting the container has not restored its validity so I am unable to save any changes in the configuration as the “pre-save validation check” always fails.

The error log is now showing…



Logger: homeassistant.helpers.check_config
Source: components/shelly/utils.py:174
First occurred: 8:21:39 PM (1 occurrences)
Last logged: 8:21:39 PM
Unexpected error validating config

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/check_config.py", line 161, in async_check_ha_config_file
    await config_validator.async_validate_config(  # type: ignore
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 129, in async_validate_config
    await asyncio.gather(
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 106, in _try_async_validate_config_item
    config = await async_validate_config_item(hass, config, full_config)
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 74, in async_validate_config_item
    config[CONF_TRIGGER] = await async_validate_trigger_config(
  File "/usr/src/homeassistant/homeassistant/helpers/trigger.py", line 50, in async_validate_trigger_config
    conf = await platform.async_validate_trigger_config(hass, conf)
  File "/usr/src/homeassistant/homeassistant/components/device_automation/trigger.py", line 26, in async_validate_trigger_config
    return await getattr(platform, "async_validate_trigger_config")(hass, config)
  File "/usr/src/homeassistant/homeassistant/components/shelly/device_trigger.py", line 100, in async_validate_trigger_config
    input_triggers = get_block_input_triggers(block_wrapper.device, block)
  File "/usr/src/homeassistant/homeassistant/components/shelly/utils.py", line 174, in get_block_input_triggers
    if not is_block_momentary_input(device.settings, block):
  File "/usr/local/lib/python3.9/site-packages/aioshelly/block_device.py", line 272, in settings
    raise AuthRequired
aioshelly.exceptions.AuthRequired

Painful has become debilitating. I don’t even know where to find this Shelly utils.py file, much less what to do with it once I have.

Please, can anyone point to a solution?

petro · May 9, 2022, 11:27am

restart via SSH. If you changed the authorization for a shelly device after you configured it without auth in home assistant, you’ll get this error. The solution is to restart.

pcal · May 9, 2022, 11:37am

Thanks @petro

I have not changed any authorizations. All my Shelly devices have the same login credentials, and have had since day one.
I have completely shut down the entire container and restarted from scratch several times with no effect.
I have no idea how to SSH into the container while it is running anyway. I though the point of a container is that the system remained contained / isolated from outside interference with its only adjustable settings in the linked config folder.

petro · May 9, 2022, 11:41am

It is, but one of your shelly devices didn’t use credentials and now it wants to. The container has no control over a device it just talks to.

pcal · May 9, 2022, 11:44am

OK… Trying to wrap my head around it…

Should I shut down the Container, then reboot each of the Shelly devices, and then restart the container?

petro · May 9, 2022, 11:49am

Sure, either way, restarting should work unless home assistant is not providing credientials that shelly wants. That depends on how you set up the shelly devices in HA.

Long story short is:

If you configured home assistant & shelly without login credentials, HA will try to connect to the device without login credentials. And vice versa.

You’d need to figure out which device is causing the problem and fix it. Based on this thread, it seemed like you had many miss-steps. So it’s hard to say what you did, but you need to figure that out and correct it.

pcal · May 9, 2022, 11:59am

Thanks @petro,

I was certainly wandering in the dark initially with a lot of “educated guesswork”, but once I found a methodology that worked, I nuked everything and restarted from scratch so I’m reasonably confident that things are at least consistent, if not best practice…

If I were to delete all the Shelly devices and reinstall them all from scratch, I’m assuming they would randomly select new device ID’s so I’d then have to go back and adjust all the existing automatons to make them work again - is that correct?

petro · May 9, 2022, 12:00pm

If you used device triggers, yes. If you used state triggers, then you’d just have to update the entity_id’s

pcal · May 9, 2022, 12:03pm

I have a range of different devices, some use device triggers and others use state triggers. Perhaps I’ll try to be more surgical in examining each device first and only fall back onto the wider wipe and reset if the first approach doesn’t get me anywhere.

Thanks again - I have some work to try now…

pcal · May 9, 2022, 1:50pm

I have deleted and reconnected two of my Shelly devices -co-incidentally both battery operated devices (button, and temp sensor) - and it does seem that the unexpected error has not come back for a longer while than usual. Hopefully it will stay away a lot longer this time. So far so good.

Thanks @petro

petro · May 9, 2022, 1:54pm

No problem. So, what changed in those devices? i’d try to update the firmware if you can. Lastly, if they always do this, you can move them to MQTT instead of shelly to avoid this auth stuff.