0.115: B-Day release! Media browser, tags, automations & WTH

Happy Birthday Home Assistant!

There's a party goin' on right here 🕺
A dedication to last throughout the years 🥳
So bring your good times, and your laughter too 😂
We gonna celebrate our party with you 🎁

It's a celebration! 🎉

~ Kool & The Gang - Celebration

7! Siete! Soch! Syv! Sieben! Seitsemän! Cедем! Sept! Sju! επτά! Zeven! Sette! Seven! Years old today! And ooooh, are we going to party and celebrate with you!

You might have noticed, this release is a bit late, two weeks late. Our regular release cycle is 3 weeks, this time however, we took 5 weeks. Sure, the reason was, of course, related to our birthday today, but what is a better gift than a jam-packed release that has something for everybody?

Thankfully, a lot of you have been sharing their gift wishlist items during the month of “What the heck?!” (WTH). I love you all! What a good and amazing set of great ideas, annoyances and other suggestions have been made in that forum this month!

And it is not just that, a lot of people jumped in fixing these things as well! What a community! The month of WTH is almost over now, after that we will close the category on the forum, until the next WTH month.

Besides that, two totally new and big features are added this release, which we really wanted to polish before releasing it.

I usually write some things about the release in my personal introduction note right here, but honestly, I have no idea where to start… it is just too darn much! I love the new automation features, but there are so many of those in this release as well. 😅 I’m not going to try writing this. 😂

So, let me close with a thank you to our founding father:

Paulus, thank you so much for what you have imagined, started and created 7 years ago. Your idea has changed the lives of many, including my own. Thank you.

Of course, it is not just Paulus, but everybody else who contributes to the project in any way. Code, text, support, chat, YouTube video, live streams, blogs, articles, community guides, documentation, tweets, issues, bug reports, feature requests, ideas, questions or even if you just use it. Thank you for contributing! ❤️

Happy birthday and enjoy the release!

../Frenck

Table of contents

Alright, this release is massive, so here is a table of contents for helping navigating you around this release.

Media Browser

This release includes an exciting set of features around media. If the media player supports it, you can now browse the player’s media library and quickly change what you’re listening to. No need for two apps anymore if you want to change the lights and pick some music.

Any media player can enable this new feature. This release adds media browser support to Arcam FMJ, Kodi, Philips JS, Plex, Roku, Sonos and Spotify!

Thanks to @jjlawren for the initial implementation and to @cgtobi, @ctalkington, @martinhjelmare, @elupus for the work on the various integrations and backend refining.

But a media browser isn’t just backend, it also needs to look good. Thankfully, we had @zsarnett on the case, with the help of @bramkragten. They came up with a beautiful design so you can browse your media in style.

When @hunterjm saw the new media browser, he got an idea. What if the user can use the media browser to browse media offered by any integration and play it on any of their media players? And so the media source integration was born.

The first media source that has been added is to allow users to play local media. Local media can be motion detection events from your IP camera or a bunch of music files to be used with Home Assistant Tags.

Home Assistant, by default, will look at the /media path. If you’re using Home Assistant OS (the default install), you can use the Samba add-on to upload media. If you use Docker, you need to mount a volume at /media and if you use a Python virtual environment, the default is <config>/media.

You can also specify your own media paths with a new configuration option in configuration.yaml:

homeassistant:
  media_dirs:
    motion: /media/motion_events
    music: /media/music

Media Source is not limited to local media. Any integration can offer its media. @cgtobi has upgraded the Netatmo integration, which will now offer its recorded motion events to play.

Media player integrations that want to play media sources will need to be updated. In this release, we’ve updated the Chromecast integration. If you click its media browser button, you will be presented with the available local sources.

Sometimes you just want to play your media without having to turn on the TV. To cover that case, @zsarnett added a new media browser to the Home Assistant interface, which can be used to play your media. That way, you can quickly see what that motion event that you just received was about.

Home Assistant Tags

Photo of the Home Assistant tag reader made by Adonno The Home Assistant tag reader, made by Adonno with the help of MagnusO.

Home Assistant now has native support for tags! With Home Assistant Tags, we’re making scannable tags (NFC/RFID) a first-class citizen in Home Assistant. Easy to read, write and automate!

We have a beautiful UI for it in the frontend, our mobile companion apps have been updated to work seamlessly with tags and there is now even an open-source scanner available, as shown in the image above.

For all details, read the dedicated blog post about Home Assistant tags!

Customize the sidebar

One of the most requested functions of What the heck was customizing the sidebar: You do want history for your entities in the more info dialog, but you don’t use that history panel. Or you do want calendars for automating, or in the new Lovelace cards, but don’t want a calendar panel with all your calendars.

Now you can hide panels from the sidebar and rearrange them, by just drag and drop them.

Screen recording of customizing the sidebar Screen recording of customizing the sidebar.

You can enter edit mode by pressing and holding the sidebar’s header or from your profile page. You can then drag the items in the order you want them or remove them by clicking the x next to it.

The removed items will be visible at the bottom of the list, by clicking the + button, you can add them back to the sidebar.

These settings are stored on your device in the local storage of your browser, this means that this setting is device-based and will be cleared when you logout.

Person image upload

You can now upload images for a person in the frontend!

Select or drop an image in the input field and then crop it to a square. The image is stored on your Home Assistant instance.

We will use the image in the frontend for your persons and the sidebar for the user linked to this person.

This feature is powered by the new image integration and opens up for future possibilities. For example, uploading images, for use in your Lovelace picture cards, would be nice!

Updated more info dialog

The more info dialog is updated. In case an entity has controls, for example a light, the more info dialog will now have 2 tabs. One for controls and one for history.

On the history tab, you can find the history graph you are used to and now also a list of logbook entries of the specific entity.

Screenshot of the update more info dialogs The updated more info dialogs, showing the two tabs: details & history.

For entities without controls (like a sensor), no tabs will be shown like before.

More information in the logbook panel

The logbook will now show what automation or script caused the change and what action was used to make the change happen.

This solves yet another WTH request. It will be really helpful to find those cases that are: WTH turned on this light?

Screenshot of the logbook showing the sources of the events. The logbook shows which automation changed the state of my stream light.

Automation & Scripts updates

The month of “What the heck?!” brought in a lot of topics that evolve around automations and scripts, of which quite a few have been addressed this release. Furthermore, we already had quite a bunch of improvements pending. If you like doing automation in YAML, you’ll probably just love this release.

Before starting on the list of newly added features, let’s talk about the Home Assistant frontend. You can now duplicate an automation and, the long present but always disabled, duplicate condition, trigger, and action function are now also finally working!

New action: Wait for trigger

This is a special new action than can be used in an automation action or script sequence that allows you to pause the execution until a certain trigger is been fired. It can be helpful for automations or scripts that consist of multiple stages.

In this example, a notification is sent when one passes through two gates to enter the garden, but only when both gates are passed within 10 seconds.

automation:
  - trigger:
      - platform: state
        entity_id: binary_sensor.gate1
        to: "on"
    action:
      - wait_for_trigger:
          - platform: state
            entity_id: binary_sensor.gate2
            to: "on"
        timeout: 10
        continue_on_timeout: false
      - service: notify.notify
        data:
          message: Someone just entered the yard!

This example is simple and probably fairly useless for most of us. However, let’s say you left your garage door open and you leave the “Home” zone. Home Assistant could send you an actionable notification, saying: “Hey, you left the garage door open, shall I close if for you?” with 2 choices: Yes/No.

Where you previously would have needed 3 automations for this. The first for sending a notification and two others for handling the “Yes” or “No” answer. Using the wait_for_trigger this could be done in a single automation.

Right after sending the notification, the wait_for_trigger could halt the script from continuing, until it receives the “Yes” or “No” answer and continue after that and run the actions you’d like based on the answer received.

This new feature is not just for our YAML uses; it also is added to our automation editor in the UI.

Screenshot of the new wait_for_trigger in the automation editor The automation editor can also use the new Wait for trigger action.

Triggers & Conditions on entity attributes

Ever tried to create an automation trigger or condition on an entity attribute, like the temperature of a climate or weather entity?

You used to need to use a template for that. Either by extracting the attribute from an entity using a template sensor or by writing a template condition. A reason for a lot of you to put it up as a “What the heck?!” entry. And you know what? You guys are right, this was difficult.

Screenshot of using attributes in the automation editor The automation editor now supports attributes on triggers and conditions.

So, Home Assistant now supports the use of attributes in triggers & conditions. Both the state and numeric state, triggers & conditions now have an attribute option that can be set with the attribute to use. The UI got a nice field for it, as shown in the above screenshots, but of course, it is also available when you are using YAML for your automations.

Some example triggers and conditions using attributes in YAML:

trigger:
  - platform: state
    entity_id: climate.living_room
    attribute: hvac_action
    to: "heating"
  - platform: numeric_state
    entity_id: weather.outside
    attribute: temperature
    above: 20.5
condition:
  - condition: state
    entity_id: climate.living_room
    attribute: havc_mode
    state: "heat"
  - condition: numeric_state
    entity_id: weather.outside
    attribute: humidity
    below: 80

Use input_datetime helpers in automation triggers

Using dates and times in your automation can be hard. If often needs quite a bit of Jinja templating and is actually really hard to do. @pnbruckner noticed, and he added the possibility to use your input_datetime helper entities directly in time trigger!

Assume you have an input_datetime.bedroom_alarm_clock_time helper entity, that is in your Lovelace UI, which you can set a time in. Great! You can now just use it in your automations to trigger on:

trigger:
  - platform: time
    at: input_datetime.bedroom_alarm_clock_time

Yes, he made it that elegant. It also works for multiple, or mixed variable and statically set times.

trigger:
  - platform: time
    at:
      - "10:00"
      - input_datetime.bedroom_alarm_clock_time
      - input_datetime.some_other_time_entity

More about the time trigger, can be found in our documentation.

Use input_* helpers in conditions

@pnbruckner set a standard in the above, and we used that to start working on making this something that would work on more places. As of this release, all input_* entities can be used in conditions.

The time condition can accept input_datetime helper entities, similar to the trigger shown above.

conditions:
  - condition: time
    after: input_datetime.house_silent_hours_start
    before: input_datetime.house_silent_hours_end

The numeric_state condition now accepts input_number helper entities for the above and below options.

conditions:
  - condition: numeric_state
    entity_id: climate.living_room_thermostat
    attribute: temperature
    above: input_number.temperature_threshold_low
    below: input_number.temperature_threshold_high

And finally, the state condition accepts any input_* helper entity in its state option.

conditions:
  - condition: state
    entity_id: sensor.happy_birthday
    state: input_text.too_you
  - condition: state
    entity_id: sensor.happy_birtday_song
    state: input_select.notify_on_song
  - condition: state
    entity_id: light.living_room
    state: input_boolean.expected_state

We are confident this will greatly improve the power and ease of the helper entities. The conditions documentation has been updated with more examples.

Here is an idea: You can now easily create a set of helper entities representing your automation settings and adding those to a separate Lovelace dashboard. You now have your own automation configuration panel, helpful for tweaking things like times or adjust temperature thresholds, without touching your automations.

Shorthand notation for template conditions

A neat little trick added this release: Allow for shorter, cleaner YAML code, if you use templates quite a bit: A shorthand notation for condition templates have been added.

All places that accept conditions, now accept templates directly. Some examples:

automations:
  - alias: "My automation"
    ...
    condition: "{{ (state_attr('device_tracker.iphone', 'battery_level') | int) > 50 }}"
    ...
- choose:
    - conditions: "{{ is_state('sensor.mode', 'on') and (state_attr('climate.room', 'temperature') | int) < 10 }}"
      sequence:
        - ...

Or in a list of conditions:

condition:
  condition: or
  conditions:
    - "{{ is_state('device_tracker.iphone', 'away') }}"
    - condition: numeric_state
      entity_id: "sensor.temperature"
      below: 20

More examples can be found in the conditions documentation.

Use templates directly in data and service fields

More WTH input! Those data_template, and service_template fields in service calls are so annoying! Why not accept templates in the normal data and service field?

Good question! And even better suggestion. As of now, you can!

action:
  - service: "notify.{{ state('input_select.active_notify_platform)' }}"
    data:
      title: This is notification!
      message: "The time is {{ now() }}"

Don’t worry, the old format still works as before, so this is not a breaking change. However, you can start removing those data_template’s by renaming to (or merging them with) data.

The keys inside a data block, can be templates now too!

service: kef_custom.set_mode
  data:
    "{{ attribute }}": "{{ now() }}"

Variables

Another WTH item, “Why can’t we have variables?!”. This WTH is not fully solved, but a good start is made this release by adding support for variables to automation and scripts.

Here is an example automation:

automation:
  trigger:
    platform: sun
    event: sunset
    offset: -00:30
  variables:
    notification_service: notify.paulus_iphone
  action:
    - service: "{{ notification_service }}"
      data:
        message: Beautiful sunset!

While the above example, it doesn’t add that much value, it does shows how it works. Variables can be templates too! For example:

variables:
  person: frenck
  notification_service: "notify.{{ person }}_iphone"

Both scripts and automation actions support this syntax now. Additionally, we added a new action! The variables action. This unlocks the potential to change variables during the runtime of a script.

variables:
  notification_service: notify.paulus_iphone
action:
  - variables:
      notification_service: notify.frenck_iphone
  - service: "{{ notification_service }}"
    data:
      message: This message actually went to Frenck, not Paulus.

For a more extensive example, check out the example written in the blog article about Home Assistant Tags.

Other scripts and automation changes

But wait! There is more! 😂

There was no way of knowing if a wait template was timed out or if it continued normally. Now, we do know this. After each wait template, a new variable is available: wait. It provides wait.completed (indicates if the template evaluated to true before the timeout expired) and wait.remaning (remaining time out).

sequence:
  - wait_template: "{{ is_state('binary_sensor.abc', 'on') }}"
    timeout: 10
    continue_on_timeout: true
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ not wait.completed }}"
        sequence:
          # Handle timeout case

The new script and automation run modes are amazing! But in some cases, they might be polluting your logs. For example, you have a automation in single mode, but it does get triggered multiples times sometimes and you are not interested in the log. You can now control that with the max_exceeded option.

The example below silences the automation and it will not log when it gets triggered while it was already running:

automation:
  - trigger: ...
    max_exceeded: silent
    action: ...

Calendar card

Like promised, when we introduced the calendar panel, we now also added a Lovelace calendar card!

This allows you to create as many calendars as you want with the entities you want.

If you want multiple calendar panels, create a Lovelace dashboard with a panelmode view with a calendar card!

Screenshot of the new calendar card Screenshot of the new calendar card.

Template developer tools

The template developer tools are very useful for checking if the template you made works and does what you want it to do. But people had some annoyances with the tool; the editor is always filled with sample data, that can give a lot of response. It would be more useful to have your previously used template there. Yes, you guessed it, another WTH!

The template would also not automatically re-render after the state of an entity is changed, causing you needing to change the template in order to re-render it.

We addressed both these issues. We save your last-used template and will show that instead of the example when you visit the template developer tools.

Screenrecording the live state changes in the template development tools. Templates you write in the developer tools, are now updating live!

We will also listen for changes of the entities you used in your template and automatically re-render your template. As a bonus, we will show which entities Home Assistant detected you are using in your template.

Reload everything YAML

WTH, do we still need to restart Home Assistant for applying YAML configuration? That was one of the WTH raised. It is being worked on!

This release, @bdraco found a way to reload some of the internal integrations and boosted this capability to a lot of integrations. For those, you can just reload the YAML in the configuration server control page (you will need advanced mode).

As of this release, besides the integrations that already could be reloaded, the following integration can now reload their YAML configuration without a restart of Home Assistant:

You can also reload an integration that is setup with the UI! This can be useful when it lost its connection or is in an otherwise failed state. You can find the reload button in the overflow menu on the integration card.

Screenshot of reloading an UI configured integration. UI configured integration can now be reloaded as well!

User password change

Another What the heck, that sounded so obvious: Being able to change a user’s password as the owner of the system. Right?!

You can now change every user’s password from the UI when you are the owner of the system!

Screenshot of change a password of a user account. As a owner, you can now change a password of a user.

Improved ways of exposing entities via Home Assistant Cloud

This release brings an update to the way you can expose entities to Google Assistant and Amazon Alexa via Home Assistant Cloud.

With the new panel, you can now set on a domain level if entities should be exposed/not exposed by default. You can still override this on a per-entity level for fine-grained control.

The default expose rules have also been updated to expose entities that work best with voice assistants.

Screenshot of expose options on an entity.

Add card by entities

Are you a bit overwhelmed by all the different types of cards Lovelace has? You can now just select the entities you want to use for a card, and have Lovelace suggest a card for you.

Screenshot of add card by entity selection view in Lovelace UI. Select one or more entities to populate the card.

Screenshot of add card by entity confirmation view in Lovelace UI. A confirmation dialog is shown before adding the suggested card.

In the add card dialog, we added a second tab with a list of all your entities. Select the entities you want to use and click continue. We will suggest a card for you and you can then fine-tune the configuration.

Order entities in Lovelace UI editor

You can now sort the entities in Lovelace UI editors by just dragging them. No more clicking the up and down buttons over and over again, simply drag the item up or down.

Screenrecording of dragging and dropping entities to re-order Drag and and drop the entities in the order you want.

Other noteworthy changes

  • The OpenZWave beta integration is coming along nicely. First signs of some control panels in the UI are visible this release. You can see the status and information of your network and nodes. There are also buttons to put your Z-Wave network in inclusion and exclusion mode and to refresh a node. Thanks @cgarwood!

  • The code editor in the UI is now theme-able, so make them look nice!

  • The stream component now supports audio! Amazing job @uvjustin!

  • Slack notification now supports change username/icon on the fly, which was a great WTH suggestion! Thanks for adding that @bachya.

  • The Met.no now supports hourly forecasts, very nice @bruxy70!

  • The MDI icons are updated to version 5.5.55, this adds another 100 icons you can use!

  • The Google Assistant integration got some updates:

    • @elupus added support for asking for the previous or next input source.
    • Basic support for controlling light effect has been added by @mjg59.
    • @blueshiftlabs added capabilities to control media player muting and relative-volume controls.
  • The Netatmo integration was re-engineered, which reduced the number of API calls and added webhook events to improve overall responsiveness. It now supports controlling the outdoor camera floodlight and got services to set the occupants’ home/away status and the outdoor camera mode.

  • We no longer automatically alphabetically sort the keys in YAML files written by the UI, as a result from a WTH request. Much better!

New Integrations

A lot new integrations 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.

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.

Automations

Previously an automation’s last_triggered attribute was updated, and an automation_triggered event was fired, whenever a trigger fired and the conditions (if any) were true, regardless if the actions actually ran.

For example, in single mode, the actions won’t run if they are still running from a previous trigger event.

Now the attribute will be updated, and the event fired, only if the actions actually run.

(@pnbruckner - #39323) (automation docs)

Axis

Initial naming of events from VMD4 and Fence guard are now based on their configured name on the device; binary_sensor.m1065-lw_0_vmd4_camera1profile1 is now binary_sensor.m1065-lw_0_vmd4_profile_1 or profile_1 can be whatever the user chose to name the profile.

(@Kane610 - #39699) (axis docs)

Broadlink

1. Devices are now configured via configuration flow

To set up a Broadlink device, click Configuration in the sidebar and click Integrations.

The devices will be imported from your configuration files to that page. If you see your device there, click Configure. If not, click the + icon in the lower right, click Broadlink, enter the host and follow the instructions to complete the setup.

The name you choose will serve as a template for the entities. You can change the entity name and id in the entity settings on the frontend. You may need to change some names or ids to make everything look the same as it was before this update.

2. Discontinue broadlink.learn and broadlink.send services

remote.learn_command and remote.send_command are now registered automatically. Now you can use remote.send_command to send base64 codes.

Instead of broadlink.learn:

script:
  learn_tv_power:
    sequence:
      - service: broadlink.learn
        data:
          host: 192.168.0.107

Use the remote.learn_command:

script:
  learn_tv_power:
    sequence:
      - service: remote.learn_command
        target:
          entity_id: remote.bedroom
        data:
          device: tv
          command: power

Instead of broadlink.send:

script:
  send_tv_power:
    sequence:
      - service: broadlink.send
        data:
          host: 192.168.0.107
          packet: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=

Use the remote.send_command by replacing host by entity_id of the remote entity, replace packet by command with data prefixed with b64::

script:
  send_tv_power:
    sequence:
      - service: remote.send_command
        target:
          entity_id: remote.bedroom
        data:
          command: b64:JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=

If you have learned the commands, you can refer to them by name instead of the raw codes.:

script:
  send_tv_power:
    sequence:
      - service: remote.send_command
        target:
          entity_id: remote.bedroom
        data:
          device: tv
          command: power

3. Discontinue all platforms, except switch

Entities are now registered automatically. The only exception is the switch platform, which continues to exist for RM switches. The config schema haschanged . The host and type are no longer required and the name serves as a template for the entity ID.

Instead of:

switch:
  - platform: broadlink
    host: 192.168.0.107
    mac: 34:ea:34:b4:5d:2c
    type: rm_mini3_redbean
    switches:
      sony_tv:
        friendly_name: Sony TV
        command_on: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
        command_off: JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=
      lg_tv:
        friendly_name: LG TV
        command_on: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
        command_off: JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=

Use this:

switch:
  - platform: broadlink
    mac: 34:ea:34:b4:5d:2c
    switches:
      - name: Sony TV
        command_on: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
        command_off: JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=
      - name: LG TV
        command_on: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
        command_off: JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=

The above example creates switch.sony_tv and switch.lg_tv to be controlled using the device with the MAC address 34:ea:34:b4:5d:2c. This device needs to be configured first via configuration flow.

When you finish configuring the devices you can delete all your Broadlink configuration files except the RM switches. These switches are the only platform that still exists in YAML. They won’t be imported. If you delete the file, they are gone.

(@felipediel - #36914) (broadlink docs)

Brother Printer

The uptime sensor state format and unit have been changed. If you rely on those you might need to adjust your configuration.

(@bieniu - #39226) (brother docs)

CPU Speed

The naming of the attributes was updated to be aligned with the current used standards.

  • Brand -> brand
  • GHz Advertised -> ghz_advertised

(@fabaff - #39155) (cpuspeed docs)

Deutsche Wetter Dienst (DWD) Weather Warnings

If you use entity state attributes of this integration in automations or scripts need to adjust these to handle the changes.

  • The region_state attribute has been removed, cause it is no longer available on the new API.
  • All timestamps in the state attributes are now UTC and not local time anymore.

(@stephan192 - #34820) (dwd_weather_warnings docs)

Emulated Hue

By default, all lights and devices that do not support brightness adjustment are exported as On/Off lights without a brightness property. When upgrading from earlier versions of Home Assistant (0.112 and earlier), some devices may now be reported by Alexa as non-responsive.

Alternatively, you can set the lights_all_dimmable configuration option to continue reporting these devices as if they have a brightness setting.

How to fix it once and for all:

You need to have Alexa rediscover all devices and then remove the now non-responding duplicates using the Alexa phone App. This can take quite a while if you have lots of devices.

An alternative would be to log in to the Alexa web site and remove all the lights instead and then re-discover them all.

To do so go to https://alexa.amazon.com/spa/index.html#appliances, or if not logged in: https://alexa.amazon.com then select “Smart Home” -> “Devices” and select “Remove All”.

If you have multiple Echo devices on your network, it is possible that the entries would continue to show as duplicates. This is due to an individual Echo device caching the old list and re-using it.

The only known solution for this is to remove your echo devices from your Amazon account, delete all the lights previously discovered by Alexa and then re-run discovery.

This is a one-off requirement, unfortunately there’s no other way to easily transition from the previously incorrect values reported by the Emulated Hue.

(@jyavenard - #39539) (emulated_hue docs)

Ezviz

The Ezviz integration has been temporarily disabled, as it has a dependency that contains code that breaks Home Assistant.

(@balloob - #38444) (ezviz docs)

Frontend

The previous deprecated frontend configuration options frontend_extra_html_url and frontend_extra_html_url are now removed.

(@balloob - #39799) (frontend docs)

HDMI-CEC

The HDMI-CEC integration has been temporarily disabled, as it has a dependency that contains code that breaks Home Assistant.

(@balloob - #37707)

Home Assistant Cloud for older Android devices

Home Assistant Cloud uses Let’s Encrypt to provide SSL certificates for your instance. Let’s Encrypt is changing the way they sign their certificates at the end of the month which breaks support for older Android devices (older than Android 7.1).

This release includes an update to make the certificates used by Home Assistant Cloud backward compatible. This relies on a feature that Let’s Encrypt provides, which will expire in September 2021.

If you use an older Android device and cannot upgrade to Home Assistant 0.115 or want to use it past September 2021, install the Firefox browser. It includes modern certificates and is able to support the new Let’s Encrypt certificates.

HTTP: Using reverse proxies

The processing of data received from reverse proxies is now more strictly handled. Invalid or malformed X-Forwarded-For headers will now result in an HTTP 400 error (Bad Request).

Support for X-Forwarded-Proto and X-Forwarded-Host has been added.

Additionally, Home Assistant will now log cases of a reverse proxy being used, but not configured with Home Assistant. Make sure, you set the use_x_forwarded_for and trusted_proxies in your Home Assistant HTTP configuration correctly to avoid warnings.

(@frenck - #38696) (http docs)

Instituto Português do Mar e Atmosfera (IPMA)

The precipitation attribute has been renamed to precipitation_probability.

(@dgomes - #38697) (ipma docs)

KNX

The KNX integration has been completely refactored to no longer rely on dedicated platform configuration but instead use the integration domain key as the base configuration.

Let’s say you’ve previously used the following configuration:

knx:
  tunneling:
    host: "192.168.0.1"
switch:
  - platform: knx
    name: Switch
    address: "2/0/1"
    state_address: "2/0/2"

You’ll need to migrate it as follows:

knx:
  tunneling:
    host: "192.168.0.1"
  switch:
    - name: Switch
      address: "2/0/1"
      state_address: "2/0/2"

(@marvin-w - #39219) (knx docs)

Kodi

Kodi Media Player configuration is now available through the UI, including discovery. If you have Kodi configured in YAML, it is advised to remove that and use discovery or a manual configuration through the UI.

Existing YAML entries will be imported, but:

  1. Your turn on/off actions will not be ported. This functionality is now available through device triggers.
  2. You may have duplicate entities.
  3. Kodi must be on when Home Assistant is loading for the first time in order for the configuration to be imported.

(@OnFreund - #38551) (kodi docs)

Lovelace for generated (auto) mode

Entities that are generated from mobile apps with the mobile_app integration is now hidden in the generated Lovelace view. If you want to continue to display those you need to take control over your view with the 3 dots in the top right corner of the Lovelace screen.

(@ludeeus - #6873) (lovelace docs)

MDI Icons

The MDI icons are updated to version 5.5.55, this adds another 100 icons you can use!

In 5.5.55 there was 1 breaking change, if you used the icon mdi:scooter this has been renamed to mdi:human-scooter and you need to adjust your configuration.

All icons that were deprecated in 0.113.0 have now been removed. Icons that were renamed or deleted in version 5.0.45 will no longer work.

Météo-France

The attributes of next_rain has been reworked. In the previous version it was a list of objects with changing keys (every 5 minutes) corresponding to a UTC timestamp. This design was difficult to use in templates and automation.

The new design will add a dedicated string attribute to have the reference timestamp of the forecast (forecast_time_ref) and a dict attribute with fixed keys to access the rain forecast within the hour (1_hour_forecast).

Example of the new attributes:

forecast_time_ref: "2020-08-20T19:25:00+00:00"
1_hour_forecast:
  0 min: Temps sec
  5 min: Temps sec
  10 min: Temps sec
  15 min: Temps sec
  20 min: Temps sec
  25 min: Pluie faible
  35 min: Pluie faible
  45 min: Pluie modérée
  55 min: Pluie modérée

(@oncleben31 - #39092) (meteo_france docs)

Meteorologisk institutt (Met.no)

While updating the integration, and its underlying libraries, to use the newer API endpoint, some of the calculations and forecast aggregations were tweaked a bit:

  • Use hourly forecast for current weather, not daily.
  • Ensure compared datetime objects are compared in the same time zone.
  • Use highest resolution data from full 24 hours to calculate daily forecast min/max/sum values.

None of these changes are expected to break your setup, though the data presented might look a little different due to the above.

In addition, all time stamps are now given in UTC. Automations that depend on the datetime key under the state attribute forecast needs to be checked and updated accordingly.

(@thimic - #39493) (met docs)

Netatmo

The sensor for wind and gust angle is split up into two entities so that it now returns the direction (e.g., NE) and the actual value (e.g., 178°) rather than a string containing both (e.g., NE (123°)).

(@cgtobi - #38627) (netatmo docs)

NZBGet

NZBGet is now available via the Integrations UI. This also means it’s no longer configured in YAML. Existing configurations are automatically transitioned to configuration via UI, so after upgrade your existing YAML entry can be safely removed.

YAML support will be fully removed in Home Assistant 0.117.0.

The NZGGet uptime sensor is now a timestamp sensor so its state value has changed from number of minutes since startup to a timestamp indicating the start time of the application.

(@ctalkington - #38938 #39425) (nzbget docs)

OAuth2 authentication and redirects

Integrations using OAuth2 authentication now use the current request URL from the browser as the redirect target, instead of the internal URL setting.

This matches the experience one would expect to happen and removes the need to fiddle around with the internal URL setting.

However, this might require you to update application settings when re-authenticating with existing services.

(@frenck - #38692)

Open Hardware Monitor

In some locales numbers with decimals uses “,” instead of “.” and this causes an issue when trying to use InfluxDB for example. This has been adjusted.

(@fillefilip8 - #39030) (openhardwaremonitor docs)

OpenUV

Support for configuring this integration has been fully removed. If you have existing OpenUV configuration in your YAML configuration files, you can safely remove that configuration.

(@bachya - #38857) (openuv docs)

OpenWeatherMap

The OpenWeatherMap integration can now be configured via the UI. After upgrading, your existing configuration will be imported automatically and you can safely remove existing YAML configuration for this integration.

(@freekode - #34659) (openweathermap docs)

RFLink

The integration has been adjusted and modified the entity_id generation for Rflink toggle type lights. There is a small possibility an entity ID has changed because of this.

(@javicalle - #37992) (rflink docs)

Roku

The Roku state now better aligns with media playback.

Previously, if an app was open, the state would be “playing” even if you were just browsing the app interface. This has been adjusted to be represented as “on”. When Roku reports media playback in progress, the state “playing” will be used.

This improves compatibility with exposing entities to Alexa, Google Assistant, and HomeKit.

(@ctalkington - #39540) (roku docs)

Sentry

The YAML configuration for Sentry is now deprecated and no longer works. If you had Sentry configured via YAML previously, you can safely remove the YAML configuration (without the need to reconfigure) as it has been imported into the UI before.

The release is now formatted with only the version number of Home Assistant Core, for example, 0.115.0. Previously, this was prefixed with homeassistant-, for example, homeassistant-0.115.0. This prefix is now removed.

(@frenck - #38833) (sentry docs)

Squeezebox

The Squeezebox integration previously always gave only the current track as the media_content_id and gave the media_content_type as music.

This leads to unexpected behavior when saving and loading scenes, because only the current track is saved and loaded.

The media_content_id for the squeezebox integration may be either a single URL or a list of them. If a single URL, media_content_type is music. If a playlist, media_content_type is a playlist. If you are using automations that use media_content_id, you should check if the media_content_type is music or playlist.

(@rajlaud - #38214) (squeezebox docs)

Templates

It is no longer necessary to provide a list of entities to monitor for each template platform as automatic analysis can now find all entities that affect the state in the template without manual setup.

This means you can now remove the entity_id option from your templates, as it is now deprecated.

The template is now re-evaluated whenever an entity that can affect the template state changes. New entities that can affect the template state are automatically discovered each time the template is rendered. This change solves a performance issue where the template would be re-rendered unnecessarily.

Please review the Working without entities section on the Binary Sensor Template documentation for alternative ways to force template entities to re-evaluate. This includes templates that rely on the use of now().

If this change means you need to make adjustments, we have made it easier by making template entities reloadable in the YAML configuration reloading section under Configure Home Assistant -> Server Controls.

(@bdraco - #39382) (template docs)

Themes

The code editor is now themeable, you can set the background color and the color for the different code blocks. The default background color now is card-background-color. For some themes this may conflict with the default code colors. To get the old behavior back add code-editor-background-color: white to your theme.

Time Pattern Trigger

The time_pattern trigger will now reject invalid expressions that were previously accepted (but did not work as expected).

For example the minutes: /60 would have been accepted previously, but could never trigger.

(@amelchio - #38982) (automation docs)

Timer

This will remove the remaining attribute from the timer unless the timer is paused. Any workarounds that do exist to use the remaining attribute to determine when the timer finishes have to switch to use the finishes_at attribute.

(@IcyPalm - #37519) (timer docs)

Timers with a duration longer than a day would format as “1 day, 1:00:00” and that is difficult to use in templates or for the frontend to render. Now it will render as “25:00:00”.

(@bramkragten - #38292) (timer docs)

Yandex Transport

The integration now accepts a full stop ID in text notation: 'stop__1234' or 'group_345' or '6789'

You’ll have to update stop_id: 1234567 in your existing configuration to stop_id: stop__1234567 as it is used in Yandex maps API.

(@devbis - #39021) (yandex_transport docs)

Yeelight

The Yeelight integration now uses custom SSDP-like discovery instead of the mDNS discovery, since mDNS discovery is removed in new firmwares.

After this change, there will be no longer automatic configuration based on discovery. Users currently using that should set up all devices through UI.

(@shenxn - #37191) (yeelight docs)

Farewell to the following

  • The Prezzi Benzina integration has been removed. It was using webscraping to gather its data, which is no longer allowed. (@eliseomartelli - #38736)
  • The yr integration has been removed after a request from yr.no. Use the Met.no integration instead (@Danielhiversen - #39247)

Release 0.115.1 - September 18

Release 0.115.2 - September 19

Release 0.115.3 - September 25

Release 0.115.4 - September 28

Release 0.115.5 - September 29

Release 0.115.6 - September 30

All changes

Click to see all changes!