Home Assistant Core 0.111 is here!
So, let’s face it: the previous release (0.110) was just jam-packed with new features, tons of upgrades and a lot of stuff changing. It was pretty exciting! It will be hard to top that.
Personally, I’m always looking forward to the new features a new release brings. Time to play! This time, however, not so much to play with. Don’t be fooled, it contains 400+ changes made by a group of 100 contributors! So I’m not sad!
This release is focussed around more stability, fixing, tweaking and tuning. Honestly, I think it is really nice!
Most notably, is the change on how Home Assistant loads up the frontend. It is available really quickly now!
It is definitely worth looking at the “All Changes” section this release, as many many small changes and fixes have been made.
Enjoy the release!
In this version, we start the Home Assistant frontend and API server before all integrations are loaded. This means you can interact with Home Assistant sooner than before.
Instead of waiting a couple of minutes until the Home Assistant frontend becomes responsive, it is available really fast now!
However, with this change, Home Assistant no longer waits for all integrations to be ready. As a result, not all devices and entities are available immediately.
This is actually good! As this means, an integration that got into trouble, can no longer prevent the frontend from becoming available. Also, as soon as it is available, you can change or remove the configuration of a non-working integration. Finally, it easier to check out your logs when something goes wrong.
The base for this change came from @bdraco his creative brains, so thanks for that! @bramkragten did all the frontend work and @pvizeli made sure the Supervisor handles the surprisingly fast available frontend as well.
Great work guys!
One additional note: If you run generated Lovelace, it will still wait for Home Assistant to be completely started. If you created your own dashboard, it will show warnings for entities that are not available yet and will update when they become available.
Another additional note: If you use an automation to set your default frontend theme, it will be applied after Home Assistant has completely started. The default theme is used during the startup phase.
Some more tuning to the startup process can be found in things like the logs. If an integration takes more time to set up, it will be shown in the logs every 60 seconds, indicating that the integration is still being setup.
Another speed improvement is found in the way we load up integrations themselves. Often, an integration has a basic setup and will then load the various platforms (like lights and switches) after that.
As of this release, Home Assistant will set up the integration but will no longer wait for the platforms to finish setting up. The individual platforms will be finished in the background. Allowing the overall startup process to continue, resulting in a faster startup.
- The OpenZwave beta integration is moving forward! Support for climate, fans and locks is added this release! If you are using the OpenZWave add-on with this integration, watch closely for updates, as an major update to that add-on is expected soon.
- @gadgetmobile went all out on the Blebox integration, adding support for a lot of platforms!
- Google Assistant now supports using a select helper (aka
input_select), amazing work @ZephireNZ!
@frenck added two new built-in Home Assistant events, helpful for
scene_reloaded. Using this as a trigger can be used for, e.g., re-applying a scene when it was changed.
- The logger has been fixed by @bdraco. The logger has disobeyed default or user-configured logging levels for a long time. This is now fixed and your Home Assistant logs should be much cleaner now!
- The Plugwise integration has been improved by @bouwew and @CoMPaTech, now supporting not only Anna but also Adam climate environments and adding the P1 DSMR monitor.
- Last triggered timestamp of automations is now set the moment it is triggered (as the name implies). Previously it was set after the action that was part of the trigger was done. We don’t expect many issues for this to rise, however, it might be affecting very specific use cases. If you use this attribute to prevent an automation to run quickly (our double), this will actually improve the situation for you.
The following integrations are now available via the Home Assistant UI:
Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.
The frontend is now available sooner. As a result, not all devices and entities are available immediately.
zigbeeintegration has been renamed to
xbee, as it is an integration for XBee devices. This is done to avoid confusion with ZHA, which is the general integration to go to when having Zigbee needs.
The backend module for the Insteon integration has changed from
pyinsteon, enabling significant improvements which include:
- Consistent state status for changes to state outside of Home Assistant (i.e., three-way switches)
- Improved Insteon scene triggering.
- Full coexistence with the Insteon Hub app
As a result, the entity ID of some entities will be changing. Specifically, the following entity types:
- X10 dimmers, switches, and sensors
- SmokeBridge sensor
Additionally, X10 entities for:
No longer appear as entities as they are not needed.
The radar imagery used is no longer associated with fixed radar stations. As a result:
- The station and location attributes have been removed
- Entity names will change, as they are no longer related to the value of the station attribute
The integration can still be configured using a station identification code, so existing configurations using this method remain valid.
ZHA Roller shades, drapes, and tilt-only blinds are now a proper
coverentity instead of a
Keen vent “dampers” are also now
coverentities instead of
The Blink battery has been moved from the
sensorplatform to the
binary_sensorplatform since it only reports “OK” or “Low” as a status. The
blink.trigger_cameraservice now takes the
entity_nameas the payload instead of the name of the camera itself.
To solve a stability problem, HomeKit now uses the entity unique id to generate accessory ids when available. This change allows HomeKit to retain accessory settings when integrations change naming formats or after renaming entities. As a result, some accessories may need a one time reset by calling the
homekit.reset_accessoryservice for them to function again.
Home Assistant Core 0.109 introduced persistent storage for HomeKit accessory ids. When upgrading from 0.108 or earlier, it is highly is recommended to upgrade to 0.110 first to allow the system to store the accessory ids and avoid the need to call the
If the upgrade path skips both 0.109 and 0.110, it may be necessary to unpair and repair the HomeKit Bridge.
Furthermore, the zeroconf options for HomeKit have been removed. HomeKit now uses a system shared instance for zerconf. If you were previously setting the zeroconf interface choice in HomeKit, you should set the interface choice in the zeroconf integration instead.
The Prometheus exporter will now report 0 (
STATE_OFF) as expected, instead of reporting the brightness level when the light is off. You may need to adapt Prometheus data processing.
The stopname has been removed from attributes since it is the same as the sensor name.
Updated binary sensor and sensor device classes to follow official ones.
Binary sensor device classes:
- Carbon monoxide changed to gas
- Vibration changed to vibration
Sensor device classes:
- Alarm has been removed
- Consumption has been removed
- Daylight has been removed
- Power has been added as power
The following sensors are now binary sensors:
The following sensors have been removed:
- volume type (RAID, SHR …)
- disk name (Drive [X])
- disk device (/dev/sd[Y])
The disk and volume sensors have been replaced:
To improve user friendly configuration and support Adam and P1 devices in addition to Anna’s, starting today Plugwise is configured through Configuration -> Integrations instead of updating the configuration file. Please remove the applicable lines from your YAML configuration file before upgrading. After upgrading add each Smile as an integration as described in the documentation. Note that this update also makes slight changes with regard to entity names to handle more than Anna.
Configuration via YAML for the Daikin integration is deprecated and will become invalid in release 0.113.0. All configuration should be done via the Integrations tab in the GUI. Users should remove the Daikin configuration YAML section before 0.113.0 is released.
The OpenUV integration can now only be configured via the UI. If you already had OpenUV configured, all you need to do is remove the corresponding lines from your YAML configuration.
History / Recorder
The history function
states_to_jsonis now a protected function
_states_to_jsonand is not expected to be called from outside the module. This is included as a breaking change in case there are custom integrations which potentially make use of this.
The Dune HD is integration is now available for configuration via the UI, your current YAML configuration is important into the UI automatically. The
sourcesconfiguration option has been removed.
Support for Plex configuration via YAML configuration was deprecated in 0.109 and has now been removed. Existing Plex configuration entries in YAML can be removed without impact, if upgrading from 0.100 or later.
Last triggered timestamp of automations is now set the moment it is triggered. Previously it was set after the action that was part of the trigger was done.
The integrations below have been removed:
This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2020/06/10/release-111/