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!

../Frenck

Starting the frontend sooner

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.

Other startup improvements

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.

Other noteworthy changes

New Integrations

New Platforms

Integrations now available to set up from the UI

The following integrations are now available via the Home Assistant UI:

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat.

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Breaking Changes

  • Frontend

    The frontend is now available sooner. As a result, not all devices and entities are available immediately.

    (@bdraco#36093, #36264) (http docs)

    Lovelace cards getCardSize can now be async, custom cards might need to adapt to this. Check the dev blog for more info.

  • Zigbee

    The zigbee integration 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.

    (@frenck#35613) (xbee docs)

  • Insteon

    The backend module for the Insteon integration has changed from insteonplm to 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:

    • x10_all_units_off
    • x10_all_lights_on
    • x10_all_lights_off

    No longer appear as entities as they are not needed.

    (@teharris1#35198) (insteon docs)

  • Environment Canada

    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.

    (@michaeldavie#36010) (environment_canada docs)

  • ZHA

    ZHA Roller shades, drapes, and tilt-only blinds are now a proper cover entity instead of a switch.

    Keen vent “dampers” are also now cover entities instead of light.

    (@Adminiuga#36059, #36080) (zha docs)

  • Blink

    The Blink battery has been moved from the sensor platform to the binary_sensor platform since it only reports “OK” or “Low” as a status.
    The blink.trigger_camera service now takes the entity_name as the payload instead of the name of the camera itself.

    (@fronzbot#35620, #35635) (blink docs)

  • HomeKit

    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_accessory service 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 homekit.reset_accessory service.

    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.

    (@bdraco#35691, #35687) (homekit docs)

  • Prometheus

    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.

    (@nbarrientos#36134) (prometheus docs)

  • De Lijn

    The stopname has been removed from attributes since it is the same as the sensor name.

    (@Emilv2#36276) (delijn docs)

  • deCONZ

    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

    (@Kane610#36352) (deconz docs)

  • Synology DSM

    The following sensors are now binary sensors:

    • disk_exceed_bad_sector_thr
    • disk_below_remain_life_thr

    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: sensor.synology_status_sda to sensor.synology_drive_1_status, sensor.synology_average_disk_temp_volume_1 to sensor.synology_volume_1_average_disk_temp, etc.

    (@Quentame#35565) (synology_dsm docs)

  • Plugwise

    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.

    (@CoMPaTech, @bouwew#33691, #36219, #36378, #36383) (plugwise docs)

  • Daikin AC

    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.

    (@fredrike#35768) (daikin docs)

  • OpenUV

    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.

    (@bachya#36148) (openuv docs)

  • History / Recorder

    The history function states_to_json is now a protected function _states_to_json and 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.

    (@bdraco#35721) (history docs) (recorder docs)

  • Dune HD

    The Dune HD is integration is now available for configuration via the UI, your current YAML configuration is important into the UI automatically.
    The sources configuration option has been removed.

    (@bieniu#36345) (dunehd docs)

  • Plex

    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.

    (@jjlawren#36388) (plex docs)

  • Automations

    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.

    (@basnijholt#35671) (automation docs)

Farewell to the following

The integrations below have been removed:

Release 0.111.1 – June 11

Release 0.111.2 – June 13

Release 0.111.3 – June 16

Release 0.111.4 – June 17

All changes

Click to see all changes!