Update to 0.117 just bricked my system

Installation
21

It’s got to be something like this…, but this is the only think I can think of that is ‘unusual’ in my configuration.yaml…, everything else is stock…, or it could be something to do with the ordering…, race condition perhaps ?

This is my component ordering:

homeassistant:
config:
counter:
image:
input_datetime:
input_number:
input_select:
input_text:
logbook:
media_source:
mobile_app:
person:
ssdp:
sun:
system_health:
updater:
zeroconf:
zone:
discovery:
frontend:
recorder:
history:
stream:
http:
tts:
sonoff:
wake_on_lan: 
webostv:
weather:
device_tracker:
camera:
light:
input_boolean:
binary_sensor: 
sensor: 
timer: 
group: 
automation:
script:
logger:
22

There is some sort of configuration.yaml issue. I tried the trick to delete it (which also deletes the secrets.yaml) and put my original entries back one-by-one. The one that seems to lock-up the system is my “sensor:” entry so I am back to functional with the exception of my rest sensor that I had in my configuration.yaml.

1 Like
23

any change to rest in 0.117? I don’t see any and I have rest sensors in my config as well as in some packages. Can you show your config? I had no issues I wasn’t expecting in 0.117.0

24

I updated to 117.0 and it broke my ozw, mqtt, and all sensors. I had just “config:” in my configuration.yaml so I downgraded to 116.4 then replaced it with “default_config:” then updated to 117.0 and now everything is working.

25

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
https://community.home-assistant.io/t/ability-to-ignore-components-in-default-config/194144/37?u=davidfw1960
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.

26

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.

27

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

28

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

sensor:
- platform: rest
  resource_template: >
    https://tidesandcurrents.noaa.gov/api/datagetter?product=predictions&application=VCM.Riverdale&datum=MLLW&station=8720625&time_zone=lst_ldt&units=english&interval=hilo&format=json
    &begin_date={{now().strftime('%Y%m%d')}}&range=48
  name: Racy Point Tides
  value_template:  >
    {{now()}}
  json_attributes:
    - predictions  
  headers:
    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.
29

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

30

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

2 Likes
31

Nice find !

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

Strange that it fails with no errors though

32

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.

33

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

34

@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.

35

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

1 Like
36

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

37

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
38

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

If your interested:

- platform: rest
  name: Octopus
  resource_template: >-
    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') }}"
  json_attributes:
    - "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') }}"
  json_attributes:
    - "results"
39

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.

40

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.