If you are running HassIO, you can (and should) run the " Check Home Assistant configuration" addon BEFORE upgrading versions.
This addon will check check whether your configuration files are valid against the new version of Home Assistant before you actually update your Home Assistant installation. This add-on will help you avoid errors due to breaking changes, resulting in a smooth update.
It caught a bunch of changes to MQTT switches, sensors, and lights for me in the 0.87 update.
Note, this is not the same as the “Check Config” button. That checks your config against the version you are running. The addon I’m talking about here checks your config against the latest version, before you upgrade to it.
This is one of those situations where ‘read the documentation’ would not be a helpful suggestion! After reading it, the word “opaque” came to mind.
This component is a meta-component and configures a default set of components for Home Assistant to load. The components that will be loaded can be found here.
I sorta get it (a component that manages a default set of other components) but I don’t understand how it automatically keeps that ‘default set’ of components up to date. For example, it’ll automatically update that default set to 0.89 … even if everything else remains at 0.88? That can’t be right.
Don’t worry about the pip version. That’s managed by Home-Assistant and they’ll upgrade it when necessary.
As for the Alexa media player, is that a custom component you installed? I believe it is, and if so, since it’s not official the config checker probably thinks it’s not supported.
It scraps update_interval in favor of the more widely used scan_interval. If you’re using components configured with the option update_interval you’re probably affected by this change.
Basically, it will auto add new core components to your HA install.
For instance, person: is a brand new core component. If you want to start using it after you upgrade, you will have to add it to your config to activate it. To make this easier for future new core components, they have added default_config:. If you add that, then new core components will automatically be added to your install as they become available. Saving you the hassle of tracking the new releases and adding them by hand as they’re released.
If you don’t track the new releases but the component automatically gets added then how will you ever know that the component is available for you to use?
Updates are traumatic enough sometimes without HA adding components without telling you.
What is the deal with the new “person” component?
How is it different than using a group of devicer_trackers?
Right now for everyone in household I have a group composed each of a device_tracker.ping and device_tracker.bt If atleast one is ‘home’ then the group.person_one is ‘home’. It works flawlessly for tracking, sensor, stats, automations, etc.
I’d prefer to keep things simple by just using core-level components, unless this offers some new advantage.
Right now? Probably not much, other than that it can be linked to a user account.
However, in the future, with multiple user accounts with individual permission levels and device trackers tied to them, the new area’s component with the ability to have a “person” in an “area”, etc, there will likely be many differences.
With the initial introduction of this component there is not much difference, but it might make sense to migrate to it where possible so when more advanced features are added the transition is smoother.
Maybe I am off base with this question, but if I want to keep a separate file for persons named (ex.) person.yaml , (splitting my configurations) I would have normally made a reference in my configuration.yaml file like this: “person: !include include/person.yaml”
If I add default_config: instead, will this not cause a conflict by seeing 2 entries named “person:” in my configuration.yaml? One for the default_config: and one that has the include statement.
I would really like to use default_config so that I am always up to date on the new components, but I have to say that I love splitting my configuration to keep it easy to locate.
So I installed this component and it totally hosed the machine. When I started it, about 5 minutes later HA stopped responding. So I SSH into it, and that took like a solid minute just to get in, after that, running hassio help causes an out of memory error. I had to restart the computer. Not sure why that happened.
I’ve seen a couple of other threads in which custom_components are beginning to give warnings that they need the directories to be restructured or they will soon fail.
It’s fairly easy enough to make the switch (unless you have a ton of them, I guess…) but when/where was this change announced?
the good news is you can switch to the new file structure now to beat the rush and your stuff will still work. the bad news is it also breaks the custom resource tracker card once you switch to the new folder structure unless the dev catches that change and updates their code.
EDIT: I just re-read the post and saw this:
That’s a pretty nonchalant statement for something that could end up breaking a significant portion of peoples set ups in the near future.
Hi all,
I’m receiving the following error when updating HASSOS to 0.88.
Any ideas?
19-02-21 00:18:22 INFO (SyncWorker_6) [hassio.docker.interface] Pull image homeassistant/raspberrypi3-64-homeassistant tag 0.88.0. 19-02-21 00:18:25 ERROR (SyncWorker_6) [hassio.docker.interface] Can’t install homeassistant/raspberrypi3-64-homeassistant:0.88.0 -> 500 Server Error: Internal Server Error (“readlink /mnt/data/docker/overlay2/l: invalid argument”). 19-02-21 00:18:25 WARNING (MainThread) [hassio.homeassistant] Home Assistant is already running!
Not normally one to complain but ZHA seems completely broken now with 0.88. I had to revert back to 0.87.1 to have it working again.
Entities in the ZHA dashboard have lost all their names, which makes it darn near impossible to know what device you’re looking at there without guessing and drilling down.#21242
Half of the device stops working but not all of it. I.e. the ZHA and Temp Sensor still works but the Binary Sensor doesn’t? #21243
Parts of the ZHA device that were shown as entities are no longer present. 21245
CoolMasterNet sounds like a very cool component, but it does not look like I can buy one as a home automation enthusiast since I can only get a quote. It’s more for integrators and installers. Oh, well. But hey! It’s nice having Ethernet! No need for Wi-Fi, which is nice!
