2024.11.2

2021.4: For our advanced users ❤️

Franck Nijhof Franck Nijhof Comments

Survived April fools day? I assure you, this April release is no joke!

This release is dedicated to our more advanced user base, as it is packed with some really advanced features and enhancements our more experienced users will love. Ready to debug your automations? Yeah…

Not that advanced of a user? I’m sure there is something in here for you to look forward to as well.

Oh, by the way, have you heard the news of ESPHome joining the Home Assistant family? If not, you should definitely read the blog post announcing it!

Enjoy the release!

../Frenck

Database upgrades, please be patient

This release contains database migrations, meaning that the format of how your history is stored is changing. This migration is automatically performed after upgrading and takes a bit of time. The time it takes depends on how much history you have stored and how fast your system is.

Please be patient when upgrading to this release.

Automation debugging

Wait, why didn’t that light turn on? Why isn’t the thermostat adjusted? Why is this automation not working? What is going on here?! This is a haunted house!?!

Sounds familiar? I’m sure we all had these moments, but are you ready for this? We can now debug automations!

Screenshot showing the automation trace of a previously ran automation Screenshot showing the automation trace of a previously ran automation.

The above screenshot shows a previous run of an automation. The automation is displayed using an interactive graph, which highlights which path the automation took. Each node in the graph can be clicked to view the details on what happened with the automation during that specific step. It traces the complete run of an automation run.

If an automation didn’t run as it should, this will allow you to debug and understand why it ran the way it did.

This extremely advanced and super useful feature is thanks to the hard work of @emontnemery who build the backend for this. The beautiful graphing was made by @thomasloven, and all the frontend work by @balloob & @bramkragten. Marvelous job guys! Thanks!

Additionally, a special thanks to all the (beta) testers that helped testing this feature and those who provided trace samples that helped to squash bugs!

Got questions about this feature? Want to see it in action? Be sure to tune in to the 2021.4 release party stream later today!

Home Assistant Analytics

Now don’t be scared by the title!

Today we introduce: Home Assistant Analytics. Opt-in, privacy-aware, public and open source. Just as it all should be for our project.

@ludeeus did a fantastic job writing this new integration. You decide if you turn it on or not; however, we guarantee it’s privacy-aware. Doubt it? Review it! Everything is open source!

Not open enough for you? We are publishing the result for everybody to see:

Screenshot of the Home Assistant Analytics website Screenshot of the Home Assistant Analytics website.

Well, maybe you want to view the public result yourself:

https://analytics.home-assistant.io

So why do we do this? Well, it helps the project and all contributors to see things like: Most used integrations. This can significantly help with improving project priorities. It also helps to convince manufacturers to work with Home Assistant, add local control and privacy-focused features.

“But the updater did this already, right?” Yes, well, the updater has actually been broken. So while we had some data, it was barely usable (actually not useable at all). Instead of fixing the updater, we now have a better solution that better matches our project goals. The updater still exists; it now just does one single thing: showing if an update is available.

Want to help the project out? Please enable Home Assistant Analytics. We would be very grateful!

You can find the settings in the general configuration options, or click the My Home Assistant button below to go directly to it. (Only visible to owner users)

Screenshot of the Home Assistant Analytics options Screenshot of the Home Assistant Analytics options, you control the amount of data you share.

For more information on how this all works and what data is shared, check out our documentation.

Thanks for sharing already! ❤️

Warnings for undefined variables in Templates

This feature is really cool. While technically a small improvement, it is a change that can impact you (as in “breaking”), but also, will greatly help you!

So imaging this little template: {{ my_variable }}

Previously, if my_variable would not exist in the template or system as a variable, Home Assistant would just ignore it and skip over it.

While this can be convenient, it can become problematic when it was misspelled or referring to a variable that doesn’t exist at all. For example, if you would have mistyped it: {{ my_varaible }}, you would never know something is wrong, unless you spotted it.

As of today, Home Assistant will tell you this, using a warning in the logs!

Screenshot of undefined variable warning log Screenshot of undefined variable warning log.

This helps to find templates that behave unexpectedly because the variable you thought was there, isn’t. It is quite possible you get a bunch of warnings after upgrading to this release. Fixing those warnings, really helps to improve your setup.

So, what if a variable isn’t always there, but I still want to use it? Well, you can give it a default, for example: {{ my_variable | default }}. Or even a default value (10 in this example): {{ my_variable | default(10) }}.

Please note that these are just warnings for now. We plan to replace the warning with an error as of Home Assistant 2021.10 (in October).

Filtering automations, scripts and scenes

Categorizing automations, is definitely one of the most requested things in our history. This became clear again during last year’s month of what the heck and various issues/discussions/feature requests.

Suggestions for labels, folders, and many more have been created. However, we already have some great categorizing features in Home Assistant itself:

Devices, Areas & Entities.

Screenshot of filtering automations by the living room area Screenshot of filtering automations by living room area.

As of today, you can filter your automations, scripts and scenes by area, device or entity. For automations and scripts, it goes one step further; it magically finds those that affect the area, device or entity being filtered.

So, you can now look at the automations affecting your living room area (even if those automations itself are not in the living room area) and also filter the automation list with just the ones that touch your thermostat.

Z-Wave JS update

So before we talk about The nice new things in Z-Wave JS, there are breaking changes in this release for the Z-Wave JS integration that could affect your existing automations. Be sure to read the backward-incompatible changes section for more info.

Alright, now the fun stuff! You can now configure each Z-Wave device straight from within Home Assistant. When you view a device in the Home Assistant frontend, you can click on “CONFIGURE DEVICE” button that is shown on each device page. This allows you to manage and adjust device (node) specific configuration parameters for the selected device.

Screenshot of configuring a Z-Wave device from within Home Assistant Screenshot of configuring a Z-Wave device from within Home Assistant.

Furthermore two new, advanced, services are introduced:

Trigger-based template sensors

This release adds initial support for a pretty advanced new, helpful feature. Template sensors, that are updated based on triggers and the data that comes with it.

Whenever the trigger fires, the template sensor will re-render and it will have access to the trigger data in the templates. This feature is a great way to create data based on webhook data, or have sensors be updated based on a time schedule.

See, for example, these two template sensors that update based on a single webhook trigger using data pushed into the webhook:

# Example configuration entry
template:
  - trigger:
      - platform: webhook
        webhook_id: my-super-secret-webhook-id
    sensor:
      - name: "Webhook Temperature"
        state: "{{ trigger.json.temperature }}"
      - name: "Webhook Humidity"
        state: "{{ trigger.json.humidity }}"

You can test this trigger entity with the following CURL command:

curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"temperature": 5, "humidity": 34}' \
  http://homeassistant.local:8123/api/webhook/my-super-secret-webhook-id

It is not just webhooks! Any trigger that you can use in automations, can be used to update these types of template sensors.

For this release, it only works for sensors; other platforms are not supported yet.

Please note: that these new template sensors are configured under the template: key in the configuration and is using a new configuration format and keys. For more information, see the documentation.

UI selectors for script fields

You can now use UI Selectors for you scripts field parameters. This brings the same UI capabilities that Blueprint have to scripts. This allow for creating advanced scripts that you can later easily reuse in your UI (even in UI automation).

Screenshot of scripts using selects in its fields Screenshot of scripts using selects in its fields.

For more details on these new field configuration options, see the scripts documentation

Other noteworthy changes

There is much more juice in this release; here are some of the other noteworthy changes this release:

  • The Supervisor is now also in the integrations dashboard, and provides entities for all kinds of things! These entities are disabled by default, so head over to the integration and see if there anything in there you could use. Thanks @raman325!
  • The develo Home Control (@Shutgun), Apple TV (@bdraco), August (@bdraco) and MQTT (@RadekHvizdos) integrations can now suggest areas.
  • You can now configure additional Google Cast devices by IP address via the integrations options. This is helpful in case of mDNS issues. Thanks @emontnemery!
  • @joshmcrty added support for selecting the number formatting you like on your profile! Awesome work!

Screenshot of selecting the number format you prefer in your profile Screenshot of selecting the number format you prefer.

  • @marvin-w added support for unique IDs to KNX entities. So, as a KNX user you can now tweak your entities in the frontend and group them into areas!
  • HomeKit now supports CO/CO2 device classes, thanks to @iMicknl!
  • @robertdelpeut added monthly and yearly totals to the DSMR sensor, thanks!
  • Hyperion users can now hide certain effects from the UI using integration options. Thanks, @dermotduffy!
  • Got that one message in your logs that you don’t care about? @jshufro added support for filtering log messages using regular expression!
  • The Plex integration now provides library count sensors! These are disabled by default by can be enabled if you like that. Thanks, @jjlawren.
  • The Quickbar had an update from @donkawechico! So press those C & E keys on you keyboard to see those beautiful new labels.

New Integrations

We welcome the following new integrations this release:

New Platforms

The following integration got support for a new platform:

Integrations now available to set up from the UI

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

Release 2021.4.1 - April 8

Release 2021.4.2 - April 9

Release 2021.4.3 - April 10

Release 2021.4.4 - April 13

Release 2021.4.5 - April 16

Release 2021.4.6 - April 19

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.

Backward-incompatible changes

Below is a listing of the breaking change for this release, per subject or integration. Click on one of those to read more about the breaking change for that specific item.

Custom integrations: Version warning

Custom integrations now require a version key in their manifest file, this also means that all custom integrations now require a manifest file.

If you are using a legacy custom integration like custom_components/awesome.py this now needs to move to custom_components/awesome/__init__.py so you can add custom_components/awesome/manifest.json to it.

For more information about integration, manifests have a look here: https://developers.home-assistant.io/docs/creating_integration_manifest

For now, this will create a warning on startup. But this will be blocked from loading if it’s missing a version in the manifest starting with Home Assistant 2021.6.

If you see these warnings, please report the issue with the author of that custom integration.

(@ludeeus - [#45919])

Xiaomi Miio

The Xiaomi Miio Fan, Sensor & Light platforms can now be configured via the UI.

If you currently have them configured using YAML configuration, they will be automatically imported into the UI on upgrade. After upgrading, you can safely remove the YAML configuration for these devices.

(@starkillerOG - #46866 #46964 #47161) (xiaomi_miio docs)

KNX

The config_file YAML option for KNX is deprecated, please remove it from your YAML configuration if you have it configured.

Float types are no longer valid for sensor / expose sensor type because the trailing zeros caused troubles when splitting to two integers.

(@farmio - #46874 #48005) (knx docs)

LIFX Legacy

The LIFX Legacy platform is deprecated and will be removed in Home Assistant Core 2021.6.0. Use the LIFX integration instead.

(@frenck - #47235) (lifx_legacy docs)

Secrets

At this moment, we are unsure if this is a breaking change or not, so we list it, just to be sure.

We are now explicitly only supporting secrets inside your Home Assistant Core and Lovelace configuration files (and anything included from there). Secrets are no longer supported in other loaded YAML files.

This change should not affect regular users of Home Assistant, however, we have been made aware that some custom integrations may cause problems. If you are a user of Dwains theme, the HomeKit Infused theme or lovelace_gen, please make sure to update those or check with the upstream project.

(@balloob - #47034)

HomeKit

The HomeKit auto_start configuration option has been deprecated. It dates from the “old”-days to prevent entities not being available yet when HomeKit started. However, nowadays, Home Assistant ensures all entities are available on startup instantly.

Therefore, this option is no longer needed. If you still have it in your configuration (and have automations for it to start HomeKit); those can be safely removed as well.

(@frenck - #47470) (homekit docs)

Hive

The Hive integration can now be configured via the UI and configuring it via YAML is now deprecated. If you have an existing YAML configuration, it will be automatically imported on upgrade. After the upgrade, the YAML configuration can be safely removed.

(@KJonline - #47300) (hive docs)

Wake On LAN

Wake on LAN component now assumes a dummy state if a host is not provided. Before, the state was only based on the host config parameter, which is listed as optional.

With this change the host config is still optional, but if it is not defined, the state of the switch is simply the last action that was taken. If you’re relying on a Wake on LAN entity in an automation or script, please make sure that your assumptions about state still hold.

(@ntilley905 - #47719) (wake_on_lan docs)

Verisure

The Verisure integration largely rewritten and is now configured via the Home Assistant user interface.

Your existing YAML configuration will be automatically imported when upgrading Home Assistant Core. After the upgrade completes, you can safely remove the existing Verisure YAML configuration.

If after upgrade your Verisure alarm system doesn’t appear, please check your integrations dashboard. In rare cases (with accounts that have access to multiple Verisure alarm systems), it might be needed to select the specific Verisure alarm system to migrate.

This also means the YAML configuration for the Verisure integration is now deprecated and will be removed in Home Assistant Core 2021.6.0.

The services provided by the Verisure integration have changed to match the standard way of how Home Assistant handles services. The following services are affected by this change:

Previously these services required a device_serial parameter, they have now changed to accept a regular Home Assistant entity, device or area as a target. For example:

- service: verisure.enable_autolock
  target:
     entity_id: lock.my_verisure_lock

If you used any of these services in your automations or scripts, please make sure you update them after updating to Home Assistant Core 2021.4.0.

(@frenck - #47880 #47905) (verisure docs)

Prometheus

Before this change, all sensors in an unknown state when the Prometheus exporter starts (i.e.: when Home Assistant starts) were being setup and metrics were exported with a default value of 0. Now, they will not be exported anymore (unless they become available again) - they can be found by searching for metrics where entity_available is 0 (will reveal both entities that are in unknown or unavailable state).

You should update any automations, scripts or 3rd party data consumers that depend on the old prometheus export with default value 0.

(@inetAnt - #47840) (prometheus docs)

August

August has fully transitioned to configuration via UI. YAML configuration is no longer supported. Existing YAML configuration has already been imported automatically in the previous releases and can now safely be removed from your configuration files.

(@bdraco - #47615) (august docs)

Workday

The Workday integration used to operate on the timezone configured on the system, instead of the timezone configured in Home Assistant. This can become problematic, for example, if your system runs on UTC, but you are 11 hours ahead of that.

This behavior has been correct and the workday sensors now rely on the timezone configured in Home Assistant. You might need to adjust to this, if you have automations, scripts or templates that previously manually corrected this.

(@schiermi - #47927) (workday docs)

Ubiquiti UniFi Video

The datetime returned in the last_recording_start_time state attribute of the uvc camera entity was changed from local time to be UTC time. All times in state attributes must be UTC time. You should update any automations or scripts that depends on this state attribute.

(@sycx2 - #41438) (uvc docs)

Z-Wave JS

Zwave JS climate devices that report their temperature in Fahrenheit will now report in tenth precision instead of whole precision, when the device supports it.

Previously, when those devices reported a temperature of, for example, 67.6F it would be rounded and reported in whole precision as 68F. Those devices will now report the temperature with tenth precision, thus 67.6F.

This means that if you currently have automation that depends on the temperature reported by these devices you may have to adjust their functionality to work properly with how the temperature is now being reported.

(@chilicheech - #48133) (zwave_js docs)

The event names for Z-Wave JS value notification (central scene) events will now be called zwave_js_value_notification and notification (e.g., locking or unlocking a lock) events will now be called zwave_js_notification.

For notification events, the properties that Z-Wave JS provides have changed, and we have changed the HA event property names to reflect that. The parameter that used to be called label (The human-readable label for the notification event) is now called event_label as there is now a new label property which is the human-readable label for the notification type.

In addition, we now support notification events for two command classes, Entry Control and Notification, so the command class is reflected in the event data. You can learn more about the different command class notifications and what each parameter means for the different notifications here:

https://zwave-js.github.io/node-zwave-js/#/api/node?id=quotnotificationquot

(@raman325 - #48094) (zwave_js docs)

Templates

Previously, during template rendering, undefined variables are replaced with an empty string. As an example the template `` will render as the empty string. This is error prone as it means misspelled or non existent variables are silently accepted by the template engine.

Starting this release, there will be a warning message in the log when a variable is undefined, but it is still rendered as the empty string. So, besides the warning, right now, nothing changes.

Starting with Home Assistant 2021.10, undefined variables will be treated as an error and template rendering will fail.

To allow rendering of templates where it is expected that a variably may not be defined without logging a warning or failing to render, use the default filter: ``.

(@emontnemery - #48140)

ZeroConf

Zeroconf will now only listen on the default interface by default.

If you need to broadcast mDNS responses to all interfaces or retain the previous behavior, set default_interface to false.

With multiple interfaces, mDNS traffic processing happened numerous times since the duplicate packets appeared on each interface. This behavior was not desirable for most cases which necessitated a change in the default.

The Home Assistant Operating System has multiple interfaces and was affected.

(@bdraco - #48302) (zeroconf docs)

Google Cast

The YAML configuration for the Google Cast integration has been deprecated and will be fully removed in Home Assistant Core 2021.6.0.

If you have existing YAML configuration for the Google Cast integration, please remove it from your configuration.

(@emontnemery - #47269) (cast docs)

Neato

Vacuum attributes clean start, clean stop and camera attribute generated_at are now in a timestamp format.

New format is “2021-03-20T10:35:47Z”. This allow automation to use their value based on as_timestamp().

If you relies on these attributes in your automation or script, you might need to adjust them to match this change.

(@chemelli74 - #48150) (neato docs)

MQTT Fan

The fan entity model has been changed. This impacts the way the MQTT Fan supports speeds and the following configuration options are deprecated and will be removed in Home Assistant Core 2021.7.0:

  • speed_command_topic
  • speed_state_topic
  • speed_value_template
  • speeds
  • payload_off_speed
  • payload_low_speed
  • payload_medium_speed
  • payload_high_speed

Additionally,preset_modes and percentage are added to replace the legacy model supporting only three speeds low, medium and high. Therefore, command templates for state, oscillation, preset_mode and percentage are introduced.

(@jbouwh - #47944 #48413) (mqtt docs)

Core / Custom integrations

Block detectable I/O in the event loop

We added a warning when this happens last April and gave developers a year to fix the instability. We now prevent the instability by raising RuntimeError when code attempts to do known I/O in the event loop instead of the executor.

We now provide a suggestion on how to fix the code that is causing the issue.

(@bdraco - #48387)

ModBus

You can now use the new style configuration when configuring the modbus integration. The existing configuration style is kept, allowing you to change gradually.

Remark the existing configuration style will be removed in a couple of releases.

Example of an existing configuration:

modbus:
  - name: "hub1"
    type: tcp
    host: IP_ADDRESS
    port: 502

sensor:
  platform: modbus
  registers:
    - name: "Sensor1"
      hub: "hub1"
      unit_of_measurement: "°C"
      slave: 1
      register: 100

Same configuration in new style:

modbus:
  - name: "hub1"
    type: tcp
    host: IP_ADDRESS
    port: 502
    sensors:
      - name: "Sensor1"
        slave: 1
        address: 100

(@janiversen - #46591) (modbus docs)

Updater

The reporting and include_used_components configuration options have now been deprecated, the updater integration will no longer report any analytics.

The analytics has moved to its own integration. See the analytics integration for more details on how to configure it.

(@ludeeus - #48518) (updater docs)

SolarEdge

The SolarEdge configuration via YAML has been deprecated and will be removed in a future release of Home Assistant. The integration is using a configuration via the UI for two years now.

Existing YAML configurations are automatically imported into the UI, and can be safely removed from your YAML configuration.

(@frenck - #48533) (solaredge docs)

MQTT Light

MQTT JSON light now supports color_mode which should be used together with supported_color_modes to signal the light’s features.

Feature flags color_temp, hs, rgb, white_value, xy are all deprecated and support will be removed in 2021.10.

(@emontnemery - #47993) (mqtt docs)

Ping

When restarting Home Assistant, the previous ping sensor state is now restored and then updated in the background to allow startup to proceed without the risk of timing out.

When the user has many ping sensors, the ping integration could timeout starting up because each ping has to happen in the executor.

(@bdraco - #43869) (ping docs)

Plex Media Server

Devices representing Plex Web media_player devices are now removed. Any automations, scenes, or scripts based on the device will need to be changed to use the media_player entity.

(@jjlawren - #48369) (plex docs)

Farewell to the following

The following integrations are no longer available as of this release:

  • Griddy has been removed, Ercot shut down Griddy after the massive power mess in Texas in mid February. (@bdraco - #47218)

All changes

Click to see all changes!