2021.7: A new entity, trigger IDs and script debugging

Happy July, which means Home Assistant Core 2021.7!

An interesting release, with a bunch of little goodies to make things easier in creating automations, scripts and doing templating. Those are things that in general, make me very happy. Mainly because, well, I use Home Assistant to automate 😁

Also, we are saying “hi!” 👋 to a new type of entity, which is really exciting and I can’t wait to see how that is being put the use in the future.

Lastly, I want to give a shout-out to @klaasnicolaas! He has been an intern with Nabu Casa for the last months. Besides doing the community highlights, he has been working on some awesome stuff that will land in upcoming Home Assistant releases.

His internship is now over, and he passed with a nice grade. Yet, he could not leave without a little present as it seems. He contributed the Forecast.Solar integration, bringing in energy production forecasting for your solar panels. Really cool!

Alright, that’s it! Enjoy the release!

../Frenck

New entity: Select

In this release we welcome the select entity to the Home Assistant family. The select entity is family of the dropdown helper (also known as input_select).

The difference is that while the input select is configured and managed by you, the select entities are provided by integrations.

This means integrations can now provide entities that give a choice. Either in the Lovelace UI, but also via automations using services, and via the Google Assistant.

Screenshot of a select entity, providing a choice from a list of options.

Some integrations started implementing the first select entities as of this release. MQTT & KNX made it available for use, WLED uses it to provide controls on selecting and activating a user preset, and with Rituals Perfume Genie you can now change the room size for your diffuser.

Trigger conditions and trigger IDs

If you are creating some complex automations in YAML, you might be familiar with this. Consider an big automation, with a whole bunch of triggers. But how would you know which of those triggers actually triggered the automation?

You can now assign an id to your triggers that is passed into automation when triggered, allowing you to make decisions on it.

automation:
  - alias: "Trigger IDs!"
    trigger:
      - platform: state
        id: "normal"
        entity_id: binary_sensor.gate
        state: "on"
      - platform: state
        id: "forgotten"
        entity_id: binary_sensor.gate
        state: "on"
        for:
          minutes: 10
    ...

The above example triggers the same automation twice, when the gate opens and when the gate is left open for 10 minutes (probably forgotten). Each trigger has its own ID.

Now introducing the new trigger condition! So you can add a condition on which trigger fired the automation.

automation:
  - alias: "Trigger IDs!"
    ...
    action:
      ...
      - condition: trigger
        id: "forgotten"
      - service: notify.frenck_iphone
        data:
          message: "Someone left the gate open..."

You can use the trigger condition in all places where all the other conditions work as well, including things like choose from a group of actions.

Rather use the UI to create and manage your automations? No problem! These new features have been added to the automation editor as well!

Screenshot of using a trigger condition in the automation editor.

Script debugging

In Home Assistant Core 2021.4, we added the ability to debug automations. This release, we’ve made these same powerful tools available for scripts!

So, this helps for the next time you are wondering: Why didn’t that script work? Or why did it behave as it did? What the script is going on here?

Screenshot of using the new script debugger on my office announce script.

The above screenshot shows a previous run of a script, using an interactive graph for each step in this script; with the path it took highlighted. Each node in the graph can be clicked to view the details of what happened on each step in the script sequence.

Referencing other entities in triggers and conditions

A small, but possibly helpful, change to our script and automations. You can now reference other entities for the above/below values of numeric state triggers and conditions. Both sensors and number entities can be used.

For example, you can now trigger an automation if the outside temperature is higher than the temperature inside.

automation:
  - alias: "Notify to close the window"
    trigger:
      - platform: numeric_state
        entity_id: sensor.outside_temperature
        above: sensor.inside_temperature
    action:
      - service: notify.frenck_iphone
        data:
          message: "Close all windows, it is warm outside!"

The numeric state conditions supports the same.

Additionally, the time conditions now support a similar thing using other sensors that provide a time in the before and after options. Time triggers added support for that already in a previous release.

Working with dates in templates

If you ever tried to work with dates in templates, you probably know that that is hard. And honestly, that will never go away, times, dates and timezones are complex little beasts.

However, we realized that the hardest part of using date & times with templates is converting the state of a sensor or text to a datetime. This release we added a small template method to help with that: as_datetime.

It can be used as a filter or as a method. Here is an example of calculating the number of days until my drivers’ license expires:

{{ (states('sensor.drivers_license') | as_datetime - now()).days }} days

Series version tags for Docker containers

If you are using the Home Assistant Container installation method, we recommend using a specific version tag; however, that means you need to update the version tag each time we release a new patch version of Home Assistant.

Thanks to @kmdm, as of this release, we also provide a series version tag that always points to the latest patch version of that release, in addition to all existing tags we already provide.

docker pull ghcr.io/home-assistant/home-assistant:2021.7

The 2021.7, will contain the latest July release, even if that is actually version 2021.7.2.

Other noteworthy changes

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

  • Z-Wave JS got quite a few updates this release:
    • A new zwave_js.multicast_set_value is available, allowing to issue a set value command via multicast. Thanks, @raman325!
    • Each node now has a status sensor available and can be pinged using the new zwave_js.ping service. Added by @raman325.
    • The Z-Wave JS configuration panel now has a “Heal Network” button, thanks @cgarwood!
    • Z-Wave JS Server connection can now be re-configured from the Z-Wave JS configuration panel, added by @MartinHjelmare.
    • Z-Wave JS logs can now be downloaded, thanks @raman325!
  • The Google Assistant integration now has support for fan speed percentages and preset modes. Thanks, @jbouwh!
  • @jbouwh didn’t stop there and added fan preset mode support to Alexa too!
  • The Philips TV integration now supports Ambilights, added by @elupus.
  • Yamaha MusicCast integration now supports grouping services, thanks @micha91!
  • @raman325 added a whole bunch of sensors to the ClimaCell integration!
  • WLED now supports local push. Updates are now instantly both ways. Also, the master light can be kept and added support for controlling user presets.
  • Setting up Xiaomi devices has gotten way easier! There is no need to do difficult things to get the tokens. Instead, Home Assistant can now extract the tokens from a Xiaomi Cloud account. Thanks, @starkillerOG!
  • More Xiaomi updates, @jbouwh added support for fan percentage-based speeds and preset modes.
  • @RenierM26 added a lot of new services to the Ezviz integration, thanks!
  • Tibber had quite a few improvements and now provides a power factor sensor, added by @Danielhiversen!
  • Google Translate TTS now supports the Bulgarian language, thanks @hristo-atanasov!
  • If you have a SmartTube, you can now reset your reminders, thanks @mdz!
  • KNX had quite a lot of updates and added support for XY-color lights, thanks @farmio.
  • @OttoWinter added support for presets, custom presets and custom fan modes for climate controls in ESPHome. Awesome!
  • Nuki now has a service to enable/disable continuous mode, thanks @anaisbetts!
  • @cgomesu added quantiles to Statistics integration, thanks!
  • The Home Assistant login page now better support password manager, thanks, @rianadon!

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2021/07/07/release-20217/
8 Likes

update went super smooth again! thanks team, beta was quite exciting, can’t wait to use release now.

Having said that, the first Python 3.9 warning has landed, (just before closure of the beta… :slight_smile:

not sure if this wasn’t mentioned using 3.8 before, but just in case…

That is not a python 3.9 warning, that is your integrations taking over 10s to setup warning

1 Like

Lots of amazing stuff here but for me the big lifesaver is the Docker series version tags! :heart_eyes:

EDIT: Looks like it may not work at the moment? Have tried 2021.7 & 6 with no luck :confounded:

ERROR: for homeassistant  manifest for homeassistant/home-assistant:2021.6 not found: manifest unknown: manifest unknown
ERROR: manifest for homeassistant/home-assistant:2021.6 not found: manifest unknown: manifest unknown

yeah, I figured. first proof of python 3.9 though. and as said running smoothly as ever.
was just setting up the new Forecast.solar integration, prepping for what’s to come. So looking out for next month…

Thanks for the trigger ID’s and the referencing of other entities. This will clean up my automations so much!

1 Like

2021.7 just landed in the last 2 minutes so thats probably why it didnt work for that one and it will be only available from this release, so 2021.6 wont be there

1 Like

Trigger ID is going to be VERY welcome, now I will finally be able to use a timer finishing as a trigger and be able to react to it in a choice. Blueprints are going to be able to become much more complete too! This is going to be very exciting.

1 Like

Nice, looks like a lot of good quality of life improvements for automations, happy about this release.

You were too fast!

The release build just finished, so they are now available (only for 2021.7 and up)

image

2 Likes

Ah, that’d be why - Makes complete sense! Thanks for the help :smiley:

Haha! Always too keen :wink: Will give it a go now!

I recently discovered that it has been available since version 2021.4 except it was not highlighted in the release notes and simply listed as one of the many changes (it appeared near the end of a list of about 700 changes). However, id was limited to being an automatically generated index value where '0' represents the first trigger.

You can test for which trigger occurred like this (shorthand notation for Template Condition):

  - choose:
    - conditions: "{{ trigger.id == '0' }}"
      sequence:
        ... etc ...
    - conditions: "{{ trigger.id == '1' }}"
      sequence:
        ... etc ...

The advantage in 2021.7 is that you can now assign a custom string value to an id and, for those who are uncomfortable with a Template Condition, there’s now a Trigger Condition. Lastly, it is now incorporated into the Automation Editor.

This is a very useful feature and, now that it has been enhanced and formally announced, is likely to help users create neater, yet more sophisticated, automations. I have already employed the 2021.4 version of id in my automations and it allowed me to consolidate several into one and/or streamline their logic.

FWIW, the advantage of using a custom string value vs auto-generated index value:

  • Improves code legibility.
  • Permits re-ordering multiple triggers without concern for altering their auto-generated index values.
5 Likes

So far so good! Great additions to this release :slight_smile:

Only minor new issue in my log is about wemo long press support (which I don’t use, so not chasing it down)

Logger: homeassistant.components.wemo.wemo_device
Source: components/wemo/wemo_device.py:85
Integration: Belkin WeMo (documentation, issues)
First occurred: 9:52:04 AM (1 occurrences)
Last logged: 9:52:04 AM

Failed to enable long press support for device: Kitchen Nook

Actually, id was previously used for the automation debugger, this variable has been renamed to idx, id has been newly added for consumption :slight_smile:

id will have the value of idx, when no id is set though (backward compatible).

3 Likes

Nice update ! I see a secondary use for solar forecast for climate control !
Substitute solar panels by glass surface of your house/appartment and you could get a prediction of how much energy flows into your house that way and use that to tweek your thermostat in winter and your blinds in summer : if the predictions are high in summer close the blinds, or in winter delay the heating to save energy.

It would probably be a relative value only, but I’ll have a look at it once i update at home !

1 Like

Whew! Thanks! :+1:

I was just about to ask that question because my automations already use id without assigning it a custom value.

2 Likes

I get this after update :

Setup failed for google_assistant: Unable to import component: No module named 'av'
Setup failed for camera: Unable to import component: No module named 'av'
Setup failed for mobile_app: Unable to import component: No module named 'av'
6 Likes

@chemelli

Setup failed for fritz: Unable to import component: cannot import name 'get_all_profiles' from 'fritzprofiles' (/usr/local/lib/python3.9/site-packages/fritzprofiles/__init__.py)
...
Error occurred loading configuration flow for integration fritz: cannot import name 'get_all_profiles' from 'fritzprofiles' (/usr/local/lib/python3.9/site-packages/fritzprofiles/__init__.py)
...

Known issue?

The result is, that the whole integration is not loaded and the trackers, etc. are not working anymore.

1 Like