0.111: Frontend loaded sooner, Elexa Guardian, Unify Circuit, Acmeda

[system]


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

• 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 automations: automation_reloaded and 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.

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)

• 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) ([zigbee 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:

All changes

Click to see all changes!

---

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2020/06/10/release-111/

[balloob (Paulus Schoutsen)]

Amazing how fast it loads!

[Mariusthvdb (Marius)]

cool, and amazing work by all! thanks been running the beta for some time, and it promises to be good in production.

Frenck, please let me continue what I wrote 0.110: Speed! OpenZWave beta, HomeKit Cameras, ONVIF, Calendars

Is last_triggered set when the automation is triggered (triggers matching kicking the automation), or is last_triggered set, when triggers match, And the conditions evaluate to true and pass.

The change is only mentioning the finishing of the action block, I would be interested in the start: because if the condition block wouldn’t pass, it would be of no interest to set the last_triggered…

Again,
Thanks!

[balloob (Paulus Schoutsen)]

It’s when we start executing the action. If you want to keep track when something is finished, store that in an input datetime

[tom_l]

Stability, fixing and tweaking are the best kind of updates.

The last triggered automation change is going to simplify a few of my automations. Thanks.

[Mariusthvdb (Marius)]

@balloob

It’s when we start executing the action

that would indeed be perfect! thanks for confirming Paulus. Good to know conditions ‘not met’ can stop the last_triggered from being set.

[carlos.vroque]

Thanks for another update. Two months ago I started a VM to see what HA was capable of and now my home lives through it.
It’s great to see all the changes, the work and the discussions involved in this project, so congratulations to everyone involved.

[firstof9]

I do like how the frontend fires up while deps are still getting loaded from pip in the background. Good stuff.

[dedi]

“If you run generated Lovelace”

This is a little unclear to me. Does that mean if you use a third party tool to generate the lovelace config? First I thought it means when you use the UI to “generate” your instead of yaml, but after a quick serach I don’t thats the case, but I am still unsure.

[123 (Taras)]

What is the typical delay between a new release becoming available and the following URL being updated?
https://version.home-assistant.io/stable.json

Currently, it reports that 0.110.7 is the latest stable release:

Whereas the GitHub repo indicates 0.111.0 is the latest release:

Is it updated when the Docker containers also become available?

[SeanM]

It’s referring to the default auto-generated Lovelace (what you get before you take control of your UI). Those users will see a progress spinner like this:

For everyone else who has customized their dashboards, it will look like this while it’s still loading. Entities that haven’t loaded yet will be shown as placeholders, this yellow box would go away as soon as the entity finished loading:

There’s also a message at the bottom of the screen which goes away when Home Assistant is fully started. It’s really nice, especially on slower systems like a Raspberry Pi that take longer to start up. Now you can use HA while it’s still loading everything.

[123 (Taras)]

Not sure why you replied to me; I didn’t discuss the Google Assistant.

[frenck (Franck Nijhof)]

@123

What is the typical delay between a new release becoming available and the following URL being updated?

In general max 2 hours for all platforms to be built and available after creating the release.

[balloob (Paulus Schoutsen)]

Follow it here https://dev.azure.com/home-assistant/Core/_build?definitionId=76

[RetroTim (Tim)]

Sorry, my bad.

[frenck (Franck Nijhof)]

The release is now available for all platforms and systems!

Happy upgrading

[RetroTim (Tim)]

Can someone explain the Google Assistant change to me please? Does this mean we can expose input_select to GA? And how do we use this?

[123 (Taras)]

Maybe I’m misreading it but that tells me 0.111.0 was built ~2 hours ago but at that time it still wasn’t available as an upgrade for Home Assistant, Home Assistant Supervised, nor Home Assistant Container.

I see you just posted the docker container about ~15 minutes ago.

Now the URL has been updated and shows 0.111.0 to be latest stable release:

As per Frenck’s post, there’s about a 2 hour interval between availability of the Core version and availability of container-based versions. During that interval, the URL continues to report that the latest release is the previous one. That’s fair; no point in updating it until all flavors become available. All I wanted to know is the duration of the delay (~2 hours).

[balloob (Paulus Schoutsen)]

No… it started 2 hours ago and lasted for 2 hours. Only when all builds are finished is the JSON file updated. You can actually click on that line you screenshotted and see all the details

[balloob (Paulus Schoutsen)]

Yes, just expose it and ask Google!