Update to 0.117 just bricked my system

One other thought. I think its a mistake to not use default_config because they do seem to add stuff to it and you can break stuff by not using it (unexpectedly without warning). There are open WTH and feature requests to be able to exclude components from default_config.

There is a post here
showing how to ignore cloud and updater but I think it would be pretty simple to do this for map as well if you want that… It doesn’t seem to require too many skills to write one.

Honestly I forgot I changed it a long time ago to exclude the map as it was giving me problems on a old android tablet I used as a wall controller that I don’t use anymore anyway. I think you are right and most users if not all should keep the default_config.

Same issue
Upgrade from 0.116.4 to 0.117.0 on Rpi3 and HA boot seems to hang with no errors
Unable to roll back from SSH

Reingstalling now will then downgrade with snapshot and investigate over the weekend
Will try renaming configuration.yaml as mentioned above, although I already have the default_config: entry

I created a thread yesterday but I probably should have put it in Installation rather than HA OS

I do use default_config and here is the config for my sensor:

- platform: rest
  resource_template: >
  name: Racy Point Tides
  value_template:  >
    - predictions  
    User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
    Content-Type: application/json
  scan_interval: 21600 # every six hours should be plenty fast enough.

I think I read something about issues with the resource template in 0.117.0 Maybe do a forum search for that.

Looks like rest sensors that use resource templates are the issue https://github.com/home-assistant/core/issues/42574


Nice find !

At least we know which fix to look out for before trying another upgrade.

Strange that it fails with no errors though

Adding default_config and removing certain REST sensors has allowed me to upgrade to 0.117.0 successfully today, however I’m fairly certain it was the REST sensors that were causing the issues.

default_config has added a lot that I didn’t want, so I may go back to cherry-picking configuration again.

I dont use default_config and have things i need listed and have always had the config item.

Also config is not part of default_config and is a seperate item, always has been before they introduced defaul_config

and the hostory

@tescophil has the answer (for me, at least). I’m running HA in a Docker container on a Synology NAS, and the upgrade to 0.117 failed to start, with the logs stopping halfway through setup.

I have a couple of REST sensors with resource_template in — I commented those out and it starts up just fine. Will have to work out how to re-do those sensors in a way that doesn’t crash.

Or just wait a bit. A fix is in progress.

1 Like

if you have an older installation that you built before default_config was introduced then there is a good chance you wont have it

Waiting is boring…, converting my REST sensors to command_line CURL sensors (back to 90’s technology, we still use it because it works…)

1 Like

Rest sensor rewritten, upgrade to 0.117 sucessfull (interesting, but painful experience)

If your interested:

- platform: rest
  name: Octopus
  resource_template: >-
    {% if now().timetuple().tm_isdst > 0 %}
        {% set ts_now = (((as_timestamp(now())/1800))|round(0,'floor')|int * 1800)-3600 %}
    {% else %}
        {% set ts_now = (((as_timestamp(now())/1800))|round(0,'floor')|int * 1800) %}
    {% endif %}
    {{ (ts_now) | timestamp_custom ('%Y-%m-%dT%H:%M:%SZ') }}&period_to=
    {{ (ts_now + 24*60*60) | timestamp_custom ('%Y-%m-%dT%H:%M:%SZ') }}
  value_template: "{{ as_timestamp(now()) | timestamp_custom('%Y-%m-%d %H:%M') }}"
    - "results"

converts into

- platform: command_line
  name: Octopus
  command: "curl 'https://api.octopus.energy/v1/products/AGILE-18-02-21/electricity-tariffs/E-1R-AGILE-18-02-21-E/standard-unit-rates/?period_from={% if now().timetuple().tm_isdst > 0 %}{% set ts_now = (((as_timestamp(now())/1800))|round(0,'floor')|int * 1800)-3600 %}{% else %}{% set ts_now = (((as_timestamp(now())/1800))|round(0,'floor')|int * 1800) %}{% endif %}{{ (ts_now) | timestamp_custom ('%Y-%m-%dT%H:%M:%SZ') }}&period_to={{ (ts_now + 24*60*60) | timestamp_custom ('%Y-%m-%dT%H:%M:%SZ') }}'"
  value_template: "{{ as_timestamp(now()) | timestamp_custom('%Y-%m-%d %H:%M') }}"
    - "results"

In my experience if HA failed to started there are some problem with writing the recorder or something in that area. The best way to solve it to remove/delete everything with home-assistant some times it can have 4 files. home-assistant_v2.db, home-assistant.log etc. BTW make sure your HA is stop when you delete the files… and start… HA should working again.

Well that’s why I run daily full backups I can restore from.
And why I don’t use HA for anything critical/WAF relevant.

I’ve removed default_config and added the individual components back in and it still starts up OK.

Interestingly I had a REST sensor for Octopus Energy too that I had to disable.

Its doesnt matter if you backup… but when the upgrade version is up there are tend to be a breaking changes anyway and you just need to fixed your setup.

Can’t the check configuration addon (here) detect the default config and REST changes against the 0.117?

How can I access the config files locally? Logged in via login. Just don’t know where to look now.