0.86.1 broke virtually everything

Super thankful for my OCD-level snapshot routine lately.

In reading the release notes, I understood that the upgrade from 0.85.1 to 0.86.1 was expected to be relatively straightforward. Having experimented with Lovelace via the Lovelace Migration Tool add-on, I expected that the upgrade would yield some UI issues but an otherwise overall functioning system. However, when Hass.io reboot, it seemed that much was broken, including some fairly fundamental parts of the system. Here is a list of the components and platforms that could not be setup in the Invalid Config error upon reboot:

  • history
  • group
  • automation
  • switch
  • cover
  • script
  • device-tracker
  • fan
  • lock
  • light
  • remote

The absence of all of these, of course, resulted in a heavily crippled system. I see comments to the 0.86 blog post that mention similar problems, but the correct upgrade process is not clear. Would failure to address config, automation, or customize (or other) yaml files prior to upgrade result in this sort of issue?

2 Likes

check the breaking changes… a ton of my stuff was disabled too when I switched to 0.86.1 from 0.85.1. I corrected a few double _ and some time automations and it is all back up and running now

Thanks for the recommendation, which I have looked into.

The only breaking change that I believe is relevant to me is the change in time triggers but I do not have any that should fall into the time_pattern category. Curiously, I note that some of my time triggers have single quotes (e.g., ‘15:00:00’), whereas some do not. I believe this happened as a result of creating some automations within the Configuration UI and others within the YAML directly and I know it confounded me before. Will need to check if that is relevant to this problem (the automations were all functioning correctly until now).

I see references to invalid slugs in the customize.yaml in the comments in the blog post. I have to admit, I don’t actually know what a slug is in this context and so may start by eliminating this file entirely as a test.

There are other mentions of renaming prior lovelace ui configuration files and the system trying to generate a file from the wrong place (in that case from the groups.yaml file). I think it would be useful to have a guide of best practices for these things that could influence the outcome as significantly as this. I did have a prior lovelace config, but trying to delete this prior to another upgrade attempt did not have any bearing.

Finally, it is important to note that I was not able to revert back to the states UI when this all occurred. I would click the link and it would take me to the corresponding URL, but everything remained exactly the same on screen. Failure of so many components and platforms may be the cause of that however.

EDIT: Finding some double underscores and so will look into that too.

I am having same problem. Everything works in 0.86.0b1 and lower, but not 0.86.1.

EDIT: It was a single device that had a double underscore in the name. Once I fixed the name, the update to 0.86.1 is working.

b2 they did rigid id checking.
Check automations, groups and customize for rogue id’s with 2 underscores.

1 Like

Same boat.
Didn’t create a snapshot and now I have a house that does not run.
This is the kind of thing to drive someone away from this silly UI not embrace it.

1 Like

don’t be dramatic about it… just fix the errors and it will all work again!

5 Likes

Why didn’t I think of that? Why wasn’t I also thinking of the lack of time I have to devote to fixing the errors for the next 10 days?

1 Like

I had a little of both in mine. I think 2 or 3 of each, and it totally knocked out everything. It apparently doesn’t take much.

1 Like

Why would you update if you didn’t have time to dedicate to fix the breaking changes that will apply to your system?

9 Likes

Ok, progress. Verified no time_pattern triggers and removed all double underscore entities then upgraded to 0.86.2. Exact same thing happened.

Eliminated all Customize entries, reboot, same thing.

Eliminated all Group entries, reboot, and I now have a reasonably operational system. The only thing that is failing to start is History. So, I may leave it like this for now to see if automations run correctly, etc. If yes, I will work on fixing History, which remains a mystery.

Again, having learned the hard way, I am super glad that I maintain a rigorous snapshot routine (and that that method of backup is so robust), with offsite backups (because problems will traditionally only arise when you are out of town). Updates have historically been very straightforward and the announcement of this one predicted the same. That has clearly not been the case and, most likely, the more complex the setup, the more probable a problem. For those raging or being critical, there’s little point getting into flame wars about an open source community driven system that is - frankly - so much better than most of the commercial options.

2 Likes

Good news! Just check the groups.yaml file for invalid entities… use the entity tool in dev-tools… you will eventually locate the culprit…

3 Likes

Same for me. Scary at first, but I fixed it by getting rid of all references to entities with double underscores in sensors, automations etc, now everything works again :slight_smile:

2 Likes

Problem with my configuration was references to group objects in groups.yaml. I used this with the old GUI and did not clean this up when I migrated to Lovelace.

Removing the group.* entrys from groups.yaml cleared all errors. The groups component seems to be a dependency for almost everything.

Removal of one trailing underscore fixed problem with Groups causing majority of failure. Removing double underscore from History exclusions fixed last problem.

The responses of various people in various threads identifying their issues has helped tremendously.

Although I was able to fix my issues this time, for future reference when problems with new versions occur:
Even without a snapshot you can install the previous version of homeassistant. There are several ways to do this.
Here is how I do it:
Open homeassistant in google chrome (may work with other browsers?).
Right click on the web-page.
Choose “Inspect” from the menu
Select the “Console” tab in the window.
Paste the following in the console window:
javascript:document.querySelector('home-assistant').hass.callApi('post', 'hassio/homeassistant/update', {version: '0.85.2'})
You can change the version to whichever you need.
This will roll back or update homeassistant to whichever version you specify.

1 Like

By the way, the breaking change that was causing this issue has been addressed in the latest update: https://github.com/home-assistant/home-assistant/pull/20478. Going forward it should produce a warning instead of breaking everything.

Yeah I was caught out too. Config was OK but my custom Samsung TV media player no longer worked. Can’t see how given it completely self contained. I’m going to wait until the new samsungctl is incorporated and then make the jump.

I was relatively lucky in that most of my config was fine.

However I definitely had the broken history problem too. This was solved by deleting home-assistant_v2.db. Yes, you lose some history, but HA recreates the DB and then History and the Recorder should work fine again.

This is the first upgrade ever since I started using HA that I have had a really bad experience.
I am pretty meticulous with my naming and never had (and still do not have) double underscores, rogue underscores at start and end and definitely no capitals in entity names.
Unfortunately my instance was still broken, so I downgraded back to 85.1 until I get time to have a proper play with 86 again.
My main issue is with input_select options, which 0.86.x does not want to honour in my install.
I wont give up, but for now had to drop back to 85.1. The downgrade process was totally painless though. I use hassio and just ran hassio ha update --version=0.85.1 at the cli via ssh.

Hoping I will find something stupid that I have missed to fix 0.86.x