Another special, themed, release inbound!

It seems like @bdraco is unstoppable; he just keeps going on improving
the performance of the Core. I truly admire him for the work he has been
delivering the past months, however, that is not the point of this release.
Sorry, @bdraco!

This release is about: Automations & Scripts! Yes!!!

A long, long time bug with automation triggering has been resolved, but not
only that, @pnbruckner went all-in by extending the automation/script engine
even more.

Adding repeat, a chooser and running modes (with cool down possibilities as a side-effect).

I’ve been playing with these features on my home already and I’ve
changed/improved quite a few things. For real, @pnbruckner, thank you!

Enjoy the release!


Ludeeus joins Nabu Casa

Today we’re happy to announce that @ludeeus is joining Nabu Casa to work
full-time on Home Assistant!

Ludeeus has been a core contributor for a long time working on the Supervisor
panel and different bits of the frontend. He is, however, mainly known as the
creator of the Home Assistant Community Store (HACS).

We’re looking forward to seeing what he can do now that he is able to focus
full-time on Home Assistant.

Welcome @ludeeus!

Automations & Scripts

This release brings changes to our automations and scripts. Before we start with
this all, please note, that the action part of an automation is a script

So, all discussed below, apply to both scripts and automations.

Before diving in: All automation and script changes, have been driven by
@pnbruckner! It is awesome! Thanks!

Automations & Scripts: Bug fix

There has been an issue with our automations for a long time already, which
you actually might have never noticed. It is kinda hard to explain, so this
needs an example.

Consider the following automation:

  - alias: "Example"
    description: "On button press, turn on the light bulb for 10 seconds."
      - platform: state
        entity_id: binary_sensor.button
        to: "on"
      - service: light.turn_on
        entity_id: light.bulb
      - delay:
          seconds: 10
      - service: light.turn_off
        entity_id: light.bulb

This automation turns on a light bulb when the button is pressed, and after
10 seconds, it turns off the light bulb again. A fairly basic automation, which
does exactly what one would expect, except when a button is pressed twice.

So it takes 10 seconds for the bulb to turn off, what if you press the button
again after 5 seconds?

Please, think about this for a moment…

What actually happened before 0.113, is that the light bulb would turn off
immediately! Chances are, you didn’t expect that.

Let’s explain this: So the first button push, turns on the light, and the delay
is active for 10 seconds. The second button push, done after 5 seconds, is
actually not handled, however, it does cause the delay of the first run to
cancel itself and continues to run the rest of the actions/sequence,
causing the light to turn off immediately!

That bug, has been fixed. As of this release, the second button press wouldn’t
do anything and the light will now turn off after 10 seconds, which the first
button push has triggered.

Automations & Scripts: Running modes

With the above-mentioned bug fix, it now becomes possible to introduce new
running modes for both scripts and automations. It allows you to control
what happens if actions of a previous trigger are still running.

Considering the light bulb example in the bug fix paraph above, it shows
the default mode: single, which means: Do not run and ignore the trigger
if a previous action of the same automation is still running.

Besides the default single mode, the following modes are now available:

Mode Description
single Do not start a new run, if running already.
restart Start a new run, after stopping the previous run.
queued Start a new run after all previous runs complete.
parallel Start a new, independent, run in parallel with previous runs.

Automation/script running modes visual explained.
Automation/script running modes visual explained.

For the queued and parallel modes, an additional parameter max is available
to control the maximum number of runs that are awaiting each other. When
omitting this setting, it would default to 10.

To clarify a little more, remember the first example in the bug fix paragraph
where the light bulb would turn on for 10 seconds after a button press?

This would make every button press within the 10 seconds, restart the countdown

  - trigger:
      - ...
    mode: restart
      - ...

And this example, would turn on/off the light, for 10 seconds twice, if the
button was pressed after 5 seconds.

  - trigger:
      - ...
    mode: queued
      - ...

The modes are also available for automations and scripts in the frontend UI:

Screenshot of running modes in the frontend
Screenshot of running modes in the frontend.

This is a powerful feature, which allows you to control how automations
and scripts are run in ways you could not do before.

More information about the running mode can be found in the automations
and scripts documentation.

Automations & Scripts: Repeats

A brand new action is made to allow for repeating (also called loops)
part of your automations or scripts.

The new repeat feature can be used in three different ways:

  • Counted repeat: Control how many times to repeat a sequence.
  • While loop: Keep repeating as long the condition(s) is/are met.
  • Repeat until: Runs at least once, and decides after that to repeat until the condition(s) is/are met.

For example, this would spam your phone with the same message 10 times:

# Send notification spam to phone
        count: 10
          - service: notify.frenck
              message: Ding dong! Someone is at the door!

More information about repeats can be found in the documentation.

Automations & Scripts: Chooser

Got multiple automations for that single light to turn it on/off? Or multiple
automations/scripts to handle the different buttons on some remote?

You can now combine them using a chooser. The chooser is able to pick the
first sequence that matches a condition, or if none match, run a default

This means each individual sequence in the chooser is paired with its own set
of conditions.

  - alias: "Example"
    description: "On button press, choose the right thing to run."
      - platform: state
          - binary_sensor.button1
          - binary_sensor.button2
          - binary_sensor.button3
      - choose:
        - conditions:
            - condition: state
              entity_id: binary_sensor.button1
              state: "on"
            - service: light.turn_on
              entity_id: light.bulb
        - conditions:
            - condition: state
              entity_id: binary_sensor.button2
              state: "on"
            - service: light.turn_off
              entity_id: light.bulb
          - service: notify.frenck
              message: Some other unknown button was pressed!

In the above example, pushing button1, turns on the bulb; while button2 turns
it off again. The third button isn’t handled by any of the conditions in
the chooser and the (optional) default is run instead.

The chooser can be used as an if/else statement, where the default acts as
the else. Or even as if/else if/else statement as shown in the YAML
example above.

More information about the chooser can be found in the documentation.

Automations & Scripts: Sub-second precision

Thanks to a bunch of optimizations done this release, which is discussed later
in this blog post, we now have sub-second precision available to our delays.

This precision is helpful in case you want a delay that is less than a second,
for example, 500 milliseconds.

An example script that toggles the light every 500 milliseconds 10 times.

        count: 10
        - service: light.toggle
          entity_id: light.bulb
        - delay:
            milliseconds: 500

Automations & Scripts: Bonus! Cool down

An often requested feature is to allow for a cool down time on an automation.
What that entails is setting a limit on the run of an automation or script
to a certain time frame.

While this is not a feature specifically added or build, it can be achieved
now using the new run modes.

  - alias: "Doorbell cool down"
    description: "Prevent multiple message being send when spamming the doorbell."
    mode: single # Which is the default
      - platform: state
        state: binary_sensor.doorbell
        to: "on"
      - service: notify.frenck
          message: Ding dong! Someone is at the door!
      - delay:
          seconds: 10

The single run mode of this automation, combined with the last delay of 10
seconds, prevents this automation from being ran more often than only once
every 10 seconds. This is ideal for things like a doorbell.

MDI icons updated

It has taken some time for us to upgrade to the newest version of
Material Design Icons, 5.3.45, there was a reason for that,
version 5.0.45 contains a lot of breaking changes.

We wanted to handle these well, so it took some time.

A lot of icons are renamed, and some are removed. In this release, we included
all new, and all removed icons and we made sure the new and the old name work.

If you use an icon that is renamed or removed we will show a warning in the log,
in version 0.115, this conversion path will be removed and removed icons and
old names will no longer work.

So make sure to check your logs if you need to adjust any of your used MDI

Most of the removed MDI icons can be found in Simple icons,
which is available as a custom integration.

Please note: It is possible that custom integrations (also known as
custom components) use deprecated icons. These can throw warnings that need
to be addressed in the custom integration.

Script and Scene editor updates

The UI to edit or create a script has been updated, besides support for the
new running mode, you can now give your scripts a custom icon and ID from the UI.

Especially the ID is helpful, you no longer have to search your states for
a long numeric entity id that matches your script.

Screenshot of a script name, icon and run mode.
Screenshot of a script ID, icon and run mode.

The support for setting a custom icon, is also added to the scenes editor.

More speed optimizations

After, the well-received, speed optimization done in the 0.111 & 0.112 releases,
the saga towards improving resource usage and responsiveness of the platform

This time we have both @bdraco and @pvizeli to thank for some great
optimizations that will reduce the CPU usage of Home Assistant.

First of all, if you are running a Home Assistant OS, Container or
Supervised installation, then your Home Assistant instance will run on
Python 3.8. No action from your end is needed for this.

It is not just a normal Python version, but @pvizeli has worked on a highly
optimized Python version for Home Assistant, hitting performance improvements
that can reach up to 40%! He wrote a more technical article about this on
our developers blog

Then @bdraco did his part on adding some improvements to the Core. He
changed a lot of handling around event & state listeners, in such a way
less things trigger unneeded, which reduces processing when states change.

This lowers CPU usage and improves response speed when you have many state
changes happening in a short time span, or when having a lot of automations.

Also, all time listeners now have microsecond precision as they are scheduled
on the internal event loop, instead of the previous situation when it relied on
the internal clock that triggered every second.

This release should drastically lower the CPU usage of Home Assistant for
most installations.

Other noteworthy changes

New Integrations

Three new integration added 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:

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

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.

Minimum Python version 3.7.1

The minimum required Python version has been bumped from Python 3.7.0 to 3.7.1.



The TensorFlow integration will fail to upgrade due to missing wheels for Python 3.8.
This affects all installations that rely on our default docker images running Python 3.8.

To work around this, remove the tensorflow platform under the image_processing domain from your
configuration.yaml, before upgrading to 0.113.

Work is under way to resolve the problem. For more information follow this issue: #38073


The way automations behaved when they were triggered while “suspended” in a
delay or wait_template step from a previous trigger event was unexpected. If
this happened the suspended step would be aborted and the automation would
continue the action sequence with the following step.

This change removes support for that “legacy” behavior, in both automations
and scripts (although scripts were less affected by this.)

It also provides new “modes” of operation for these action sequences, namely
single, restart, queued & parallel. To minimize the impact on existing
automations and scripts, the default mode is single.

In addition, for queued & parallel modes there is now a new configuration
option – max – that controls the maximum number of “runs” that can be
running and/or queued up at a time.

And lastly, the delay step is now much more precise, and supports delays of
less than one second.

(@pnbruckner#37729) (automation docs) (script docs)


Most of the template platforms would check for extract_entities failing to
extract entities and avoid setting up a state change listener for “all” after
extract_entities had warned that it could not extract the entities and updates
would need to be done manually.

This protection has been extended to all template platforms.

Alter the behavior of extract_entities to return the successfully extracted
entities if one or more templates fail extraction instead of returning “all”
and getting rejected by the platform itself.

(@bdraco#37831) (template docs)

Relative time

Previously, the value used for displaying a relative time was floored before
being interpolated into the localized string, leading to situations like these:

  • 47 hours ago is displayed as “1 day ago” instead of “2 days ago”
  • 13 days in the future is displayed as “in 1 week”

This change modifies the relativeTime function to use Math.round instead of
Math.floor so the output more closely matches the actual relative time of the



Birth and will messages are now published by default.

MQTT birth message defaults to:{"topic": "homeassistant/status", "payload": "online"}
MQTT will message defaults to: {"topic": "homeassistant/status", "payload": "offline"}

MQTT will published also on clean connect from broker.

(@emontnemery#37371) (mqtt docs)

ZHA with Hue remotes

This update does contains a breaking change if you are using Device Triggers
for the Hue Dimmer models RWL020 and RWL021.

We decided to configure these to use the extended manufacturer support so that
we can support 4 triggers per button.

If you were previously using Device Triggers in automations for these devices
you will have reconfigure the device leveraging the button on the device page
or remove and re-pair the device after updating Home Assistant.

Then you will have to update the automations to use the new triggers.

Sorry for the inconvenience.

(@dmulcahey#37859) (zha docs)

ZHA power unit of measurement

Previously ZHA was displaying power as kilowatt (kW) for some devices
(the ones with the SmartEnergy cluster), but since watts are more common as
household power unit, ZHA will start using W for those instead.

If you have any calculations or accumulation based on power sensors,
they may need to be updated.

(@abmantis#37896) (zha docs)

Philips Hue

Configuring a Hue bridge via YAML configuration is now deprecated. Your current
YAML configuration is imported and can be safely removed after upgrading.

Adding Hue bridges manually by IP can now be done via the UI. Changing allowing
Hue groups or unreachable Hue bulb is now managed by clicking the options button
on the Hue integration in the UI.

(@frenck#37268) (hue docs)


Support for glob matching is added with InfluxDB filters.

InfluxDB was not using the common filtering logic shared by recorder,
logbook, homekit, etc. and as a result had filtering logic that is
inconsistent with the filtering logic of every other recorder-like component.
This has been corrected causing the following changes in filtering logic.

Same domain specified in both include and exclude:

  • Previous behavior: All entities in that domain excluded
  • New behavior: All entities of that domain included unless entity is excluded
    by ID or by glob

Same entity ID specified in both include and exclude:

  • Previous behavior: Entity excluded
  • New behavior: Entity included

Filtering has 1+ exclude domains, 0 include domains, and 1+ include entity ID’s specified:

  • Previous behavior: All entities not specifically listed by ID were excluded
  • New behavior: All entities not specifically excluded by either domain or ID
    are included.

(@mdegat01#37069) (influxdb docs)


For all torrents sensors (e.g., active_torrents or started_torrents) order
of the content of the torrent_info attribute has changed to oldest first
which means older torrents will appear first in the list.

Also a default limit of 10 items is also applied to the list to avoid very long
strings stored in the recorder database. Both configuration options, order and
limit, can be adjusted in the integrations UI.

(@zhulik#35411) (transmission docs)

Logitech Harmony Hub

New devices and activities are visible as harmony attributes. The current
activity is now updated as soon as the remote starts the activity change
instead of being delayed until the activity is finished setting up.

(@bdraco#37559) (harmony docs)

Xiaomi Miio

Fan and remote components now have unique LED strings.
If you had previously set your automation calls from
fan_set_led_on/off” to “remote_set_led_on/off”,
you will now need to set those back to “fan”.

(@alexhardwicke#37605) (xiaomi_miio docs)

Samsung SyncThru Printer

Syncthru configuration is now done through the integrations UI page.

(@scop#36690) (discovery docs) (syncthru docs)


Re-added the ability to use remote files (by URL) in Slack messages.

The data schema for sending files in Slack messages has changed, so be sure to
update any Slack-related service calls with the new schema as listed in
the Slack integration documentation.

(@bachya#37161) (slack docs)

  • Configuration of entity name must now be done inside home assistant
  • Multiple entities may be generated for a single device
  • The events signalled from entity id’s are removed in favor of events from an integration level.
  • The events format has changed.

(@elupus#37742 #37565) (rfxtrx docs)


Fibaro Home Center switches that control light sources will now correctly be configured as Light entities (instead of Switch entities). This causes those entities IDs to change from switch. to light. If this is not desirable, change the device role in Home Center to something that isn’t a light source (e.g., Other device).

(@danielpervan#37690) (fibaro docs)

Frontend: Deprecated HTML imports

extra_html_url is now deprecated and support will be removed in 0.115.
You can switch to the new extra_module_url or extra_js_url_es5 by changing
your imported file to JavaScript.

With the start of custom components, you would import a HTML file for your
component instead of JavaScript. That’s why we have always supported importing
extra HTML in the frontend and custom panels.

This has been deprecated and superseded by ES modules since some time and has
no support anymore in browsers. We have a polyfill in place to still support
this, but we are going to remove this.

In version 0.115 we will remove the ability to import HTML, you can use ES
modules as a replacement.

(@bramkragten#37843) (frontend docs)

Frontend: Themes

The theme variable paper-card-background-color is removed. You can use ha-card-background or card-background-color as a replacement.

In general, all variables that start with paper will be removed at some point.

(@bramkragtenfrontend#6377) (frontend docs)

Release 0.113.1 – July 24

All changes

Click to see all changes!