Release 0.88 has landed. It’s been a busy two weeks with a ton of cool stuff and improvements.
This release introduces a new person component thanks to @MartinHjelmare. With this component, Home Assistant can be set up to track the people in your home. Each person can be linked to a user and multiple device tracker entities. This release does basic device tracker state merging, which will be evolved in the future. Device trackers merging their own states will be phased out in favor of persons. You can configure persons via the config panel. To get started, add the person component to your configuration.yaml file: person:. If you want to automatically stay up to date with the latest default Home Assistant components, you can now also add default_config: to your config.
This release also extends the event dev tool to include an event debugger. It allows you to listen to core events and get them printend to the screen. This makes it easy to find the event data that your remote is sending out.
We also have a new command line auth provider. This will allow you to use a shell script to validate users logging in to the system. This gives a lot of flexibility. For example, you can now authenticate against LDAP. More info in the documentation.
@andrewsayre has been working hard on extending the SmartThings support. This release brings sensors and climate devices into the mix. Awesome!
Noteworthy breaking changes
We have tightened config validation, so expect a couple of new warnings. Platform configuration will no longer allow to contain keys that are not supported. This should help with finding typos in your current and future YAML configs. This will currently fallback to a warning and will become a full error in the future.
Note for Lovelace custom card developers: if you relied on the availability of <paper-button> in your code, you will have to update it to <mwc-button> to get a similar component.
Note for custom component developers: We are moving to a new file structure. More information on our dev blog.
New Platforms
New Features
If you need help…
…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.
Reporting Issues
Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.
When you say that we will get warnings on Platform configuration that contains keys that are not supported, you mean in the Check Configuration (or hassio ha check)?
Is there any custom component or anything that will take a list of all the components that I’m running, and compare it to the changelog, and then only show me the parts of the changelog that matter to my installation? These changelogs just seem to get longer and longer, and I would like to be able to see which changes matter to me.
All of these link to same page and also page is only about the speedtestdonet as platform, no ‘sensor’ info. I don’t know how to fix what I’m running currently as I want it to be as usual sensor.
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.
as I want it to be as usual sensor.
