2024.11.2

0.110: Speed! OpenZWave beta, HomeKit Cameras, ONVIF, Calendars

Franck Nijhof Franck Nijhof Comments

Do you know how excited I am for bringing you Home Assistant Core 0.110?

Would you believe me, if I told you I’ve been upgrading my personal Home Assistant production instance to the latest development version almost every day?

Well, better believe it, it is how I started my day for the last 3 weeks. It felt like opening new presents and enjoying amazing improvements every day.

Today, we are shipping it all to you, as one big package. 🎁

This is definitely one of the bigger releases of Home Assistant on all levels. Speed improvements to both the frontend and backend, lots of usability improvements, 12! new awesome integrations and an insane amount of major updates to existing ones.

Enjoy the release!

../Frenck

Icons

In Home Assistant Core 0.109, we made the frontend lighter and faster, this release takes it a step further.

The way icons are loaded is updated. With the ever-growing Material Icons set, it was necessary to update the way we handle icons to make sure our application continues performing.

The Material Icons are now split in chunks, so the frontend does not have to load all the icons if you just need one; besides that, we no longer store the icons in the DOM but in a database.

This saves a lot of memory and thus makes the Home Assistant frontend even more leaner and faster!

Honestly, it is not just icons… A lot is optimized to make the frontend faster this release. It is now snappier than ever!

Integrations grouping, searching & custom logos

@timmo001 added the possibility to search your integrations, so you can find what you are looking for quickly.

We also grouped the entries by integration now, this means we no longer show multiple cards for the same integration, but show a list of the names if there are multiple entries.

If you click the entry, it will show that entry in the card. This makes it easier to keep an overview of all your integrations.

Screenshot of the integrations page Screenshot of the integrations page.

Oh! We’ve also made the icons and logos available for custom integrations!

Screenshot of the HACS integration with its icon shown Screenshot of the HACS integration with its icon shown.

OpenZWave integration now in beta

This release features the new OpenZwave integration. It has been in testing as a custom integration by the community since last December and is now ready for a wider audience.

It is still early days for this integration, though; not all platforms and devices are supported yet and the setup process has prerequisites that raise the accessibility bar. See our documentation for the current requirements and instructions.

If you want to give it a shot, you should be comfortable with setting up custom add-ons and MQTT. There is no migration from the current Z-Wave integration yet, this is still to come.

The plan is to add more platforms in the future, making it super simple to set up the integration. Stay tuned.

There is currently no plan to deprecate the existing Z-Wave integration. But the hope is that the new integration, in the future, will offer a simpler, more stable and more feature-rich experience than the current Z-Wave integration.

Thanks go out to the community that has been testing the custom integration and provided very valuable data to allow us to catch bugs and support more devices. A special thanks to @cgarwood and @marcelveldt who have been pioneering building the integration.

Every discovered integration can be ignored

An often reported issue/request feature is to allow any discovered item to be ignored. Most integrations supported that already, but some didn’t.

As of 0.110, we have a new development rule requiring an integration to support ignoring discovered items; and for 0.110, we have upgraded all integrations that didn’t support it yet!

Result: Any discovered item, can be ignored.

Screenshot of showing ignorable integrations Screenshot of showing ignorable integrations.

Calendar panel

Thanks to @zsarnett we got a beautiful new calendar panel!

It shows you all items of the calendars you select in a month, week or day view. There is also a calendar card for Lovelace in the making.

Screenshot of the Calendar panel Screenshot of the Calendar panel.

Weather card

We got a lot of feedback about the updated weather card of the last release, we listened to feedback and added some features. You can now theme the colors of the new icons, and you can even completely replace them with another image.

You can also set the attribute you want to show as the secondary information.

Screenshot of the updated weather card Screenshot of the updated weather card.

Check the documentation for more information.

Internal & External URLs

There are many cases where an integration needs the URL/link to your Home Assistant instance. For example, to set up a webhook, communicate audio files or camera streams to an Amazon Alexa or Google Assistant device.

We used to have a base_url setting to deal with those cases, but that wasn’t always sufficient. Some integrations require specific requirements for that setting, which could lead to conflicting or impossible settings.

It often resulted in broken TTS, streaming issues for camera’s or issues with casting. This release addresses this issue by introducing two new settings in Configuration -> General.

Screenshot of the URLs configuration Screenshot of the URLs configuration.

If you want to set those via YAML, homeassistant: main configuration has now a external_url and internal_url setting.

These settings allow you to override the URLs Home Assistant uses when communicating on your internal network versus the outside world. Please note, that these are overrides. By default, Home Assistant will try to figure this out on its own.

If you have a Home Assistant Cloud subscription, integrations can now also leverage that. This will reduce the amount of, often complex, configuration needed.

After upgrading to 0.110, you can delete base_url from your configuration as Home Assistant will automatically migrate that setting for you on upgrade.

Support for “not” conditions in automations

When an automation triggers, one can use conditions to check if the set actions of an automation should be run. Conditions, however, always take the positive approach: If “something” equals or is “this”.

As of this release, the conditions now have support for specifying if a condition (or set of conditions) should “not” match. This can be helpful for devices or entities that have multiple states, but you actually only want to ensure it is not just that one state.

Screenshot of the automation editor with a "not" condition Screenshot of the automation editor with a "not" condition.

This feature has been added to the automation editor, but is also available for writing automations in YAML:

# Example automation
alias: "Turn kitchen lights off when alarm is armed."
trigger:
  - platform: state
    entity_id: alarm_control_panel.home_alarm
condition:
  - condition: not
    conditions:
      - condition: state
        entity_id: alarm_control_panel.home_alarm
        state: disarmed
action:
  - service: light.turn_off
    target:
      entity_id: light.kitchen

HomeKit

@bdraco has been busy improving HomeKit support for Home Assistant in 0.109, but it seems like that didn’t stop him even a tiny bit. This release @xdissent and @stickpin jumped on the HomeKit bandwagon as well!

HomeKit can now be configured and set up from the Home Assistant frontend, and even allows you to set up multiple instances! This allows one to bypass the maximum amount of devices a single HomeKit gateway supports by adding multiple. Using multiple, will also allow you to bypass the 1 TV per bridge limit on HomeKit.

Ready for this? Home Assistant Core 0.110 now has camera support for HomeKit!

And if that wasn’t enough already, the HomeKit integration now sends out more information as HomeKit accessory information. So besides the entity id, which was already present, you can also see which integration (and its name) provided the accessory in HomeKit.

Screenshot from HomeKit. Left: accessory information, Right: Camera support. Screenshot from HomeKit. Left: accessory information, Right: Camera support.

ONVIF

The ONVIF integration did get lots of love from @hunterjm! ONVIF Profile S conformant camera’s, can now be set up via the UI!

And that is not all… It now leverages more features of the ONVIF protocol: pull point subscriptions. This means that events from ONVIF will now show up in Home Assistant as well. So, if your ONVIF compatible camera supports things like motion, object or sound detection, those will be available now!

Screenshot of an ONVIF camera in Home Assistant Screenshot of an ONVIF camera in Home Assistant.

Supervisor

Have you seen the new supervisor UI? @ludeeus did a great job redoing its UI! It now uses the same tabs as the configuration panel. The add-on page is split into multiple tabs, the add-on store is cleaned up and you can view all logs in the system tab now (requires advanced mode).

Screenshot of the Supervisor panel Screenshot of the Supervisor panel.

Some add-ons are now also marked “advanced” and are only visible when you’ve enabled advanced mode on your user profile.

Other noteworthy changes

  • It took a while, as many adjustments had to be made. This is the first release supporting Python 3.8 🎉!

  • Quite a few optimizations to make Home Assistant go faster. One of the major changes is that Home Assistant will now set up all configured integration instances in parallel during startup. Some startup speed reported improvements from 82 seconds before this change and 28 seconds after this change. That is a huge improvement!

  • The info page in the development tools now shows more information about your set up. Including the name for your installation method. It will tell you if you run Home Assistant, Home Assistant Supervised or Home Assistant Core.

  • @MartinHjelmare added a new detection method for integrations that potentially harm Home Assistant during runtime. We can now detect if an integration tries to close Home Assistant’s (shared) HTTP client. If this happens, it will be prevented and write an error message to your log, similar to how the I/O detection does it (released in 0.109).

  • The ISY994 got a major upgrade! While it has quite a few backward-incompatible changes, it is now available via the UI and many bug are squashed. Thanks @shbatm!

New Integrations

New Platforms

Integrations now available to set up from the UI

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

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat.

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Backward-incompatible changes

  • Manual Alarm Panel - When going from state disarmed to any other (armed) state such as armed_away, the state will be arming instead of pending during the transition time as set in the configuration. When going from an armed state (such as armed_away) to the triggered state the state will still be pending during the transition time as set in the configuration (as it was before). - (@starkillerOG - #32950) (manual docs)

    • State attribute pre_pending_state changed to previous_state
    • State attribute post_pending_state changed to next_state
    • Configuration option pending_time is renamed to arming_time, functionality is the same.
    • The time the alarm stays at pending when triggered has changed from delay_time of the previous state + arming_time (previously known as pending_time) of the triggered state to only the delay_time of the previous state.

  • Cert Expiry - The “name” configuration option marked as deprecated in 0.107 has been removed and will now cause errors on startup if it remains in the configuration. You should change your configuration accordingly. - (@jjlawren - #34628) (cert_expiry docs)

  • Stream - pyAV >7.0.0 has dropped support for FFmpeg versions <4.0. FFmpeg will need to be updated to at least 4.0 for stream to work. If you run an Home Assistant with the Superviser or Docker, no manual intervention is needed. Alternative installs can check the stream integration documentation for troubleshooting tips. - (@hunterjm - #34648) (stream docs)

  • Nederlandse Spoorwegen - The punctuality attribute has been removed from the integration. Ever since NS updated its API a few months ago, its behavior with regards to the punctuality has been incoherent, sometimes even missing from the API’s response. This has caused numerous Issues to be created in this repo by users getting errors that the punctuality attribute was unlike what the integration was expecting. - (@YarmoM - #34680) (nederlandse_spoorwegen docs)

  • Fortigate (Deprecated) - The Fortigate integration will be removed in 0.112.0 and has a replacement in the FortiOS integration.

    Please refer to the fortios integration on how to configure the new parameters. - (@kifeo - #34854)

  • Raspberry Pi Camera - To align with ADR-0007, configuration has been moved under rpi_camera: as its own platform. - (@alxrdn - #34461) (rpi_camera docs)

    Old YAML configuration example:

    camera:
- platform: rpi_camera
  image_width: 1296
  image_height: 972
  image_quality: 75

    New YAML configuration example:

    rpi_camera:
  image_width: 1296
  image_height: 972
  image_quality: 75

  • ONVIF - ONVIF is now available to be added from the Integrations UI! The extra_arguments and rtsp_transport configuration from YAML is now a part of the Options flow for the integration, and is not automatically imported to the configuration flow with the rest of the defined ONVIF platforms. - (@hunterjm - #34520) (onvif docs)

  • PulseAudio Loopback - Internal library code has been replaced with the pulsectl library. - (@breiti - #34965) (pulseaudio_loopback docs)

    • The default connection honors the configuration in /etc/pulse and no longer defaults to localhost.
    • When a host is configured, the default port has been changed to 4713 to use the native interface of PulseAudio.
    • The configuration parameters buffer_size and tcp_timeout have been removed.

  • UPnP - This integration has been simplified and will always create sensors, so port mapping functionality has been removed. - (@StevenLooman - #35191) (upnp docs)

    Example YAML configuration:

    upnp:

  • ZHA - Configuration options for ZHA integration in YAML is now deprecated and will be removed in 0.112.0. - (@Adminiuga - #35161) (zha docs)

    Starting with the following radio configuration options:

    • usb_path
    • baudrate
    • radio_type

  • IMAP Email Content - The state of the imap_email_content is replaced when there is no email found. With this change, any other thing like an automation can react to the arrival of an email - (@isk0001y - #35123) (imap_email_content docs)

  • Sony Songpal - This is now enabled through the Integrations UI. To call songpal/set_sound_setting on all songpal devices, the entity_id now needs to be set to all instead of left unset. - (@shenxn - #34714, #35318) (songpal docs)

  • HTTP - base_url is deprecated and replaced by an internal_url and external_url core configuration setting. - (@frenck - #35224) (basic config docs) (http docs)

  • Kodi - Kodi previously reported the media content type for all PVR channels as “channel”, no matter if it was a TV or a radio channel. The media content type is now derived from the used player type, i.e., it reports as “music” for radio channels and “video” for TV channels. - (@Tho85 - #35091) (kodi docs)

  • Mill - Mill is now enabled through the integrations UI and no longer available via YAML - (@Danielhiversen - #35136) (mill docs)

  • Homematic - Automations relying on the numeric value for the garage door status might break, since the status will now be reported as human-readable strings. - (@guillempages - #35349) (homematic docs)

  • Tuya - Tuya is now enabled through the Integrations UI. - (@ollo69 - #35422) (tuya docs)

  • LG webOS Smart TV - A new unique_id is used for webostv media players for users running a 0.109.X release. Duplicate entities will be created with new entity IDs and old entities will need to be manually removed. - (@jjlawren - #34979) (webostv docs)

  • Blink As of May 11, 2020 Blink has removed the old username/password authentication method, which means all current Blink integrations prior to this release are broken.

    In order to support this change, a 2FA key must be entered before setup can continue. Some users may not have 2FA enabled on their account yet, but you will still receive an email at login asking you to allow the device to continue setting up.

    Your current YAML configuration will be converted to a UI-based configuration, but the only supported entries are username, password, and scan_interval. All other entries must be removed; otherwise, the integration will not be configured. - (@fronzbot - #35396) (blink docs)

  • Emulated Hue - Emulated Hue was updated for better compatibility with newer systems. Existing users may find that they will need to re-pair their system with emulated hue to reconnect devices. - (@Tho85 - #35148) (emulated_hue docs)

  • Universal Devices ISY994 - This migrates ISY994 to PyISY v2 and is now available to be added from the Integrations UI. PyISY Version 2 is a significant update to the original module used to communicate with the ISY. (@shbatm - #35212, #35338, #35413, #35391 ) (isy994 docs)

    As part of the update and many bug fixes, some backward-incompatible changes were introduced:

    Click see all backward-incompatible changes for ISY994

    • Remove ISY Climate Module support: the ISY Climate Module was retired by UDI on 3/30/2020: UDI Announcement, support has been removed from the module, so any entities based on Climate module nodes will no longer import into Home Assistant. The enable_climate configuration option will need be removed from your YAML configuration file.

    • Device State Attributes have changed: some attributes’ names and types will have changed as part of the changes to PyISY. If a user relied on a device state attribute for a given entity, they should check that it is still there and formatted the same. In general, more state attributes that were previously unavailable, should appear.

    • isy994_control events now return with additional information about the event. If a user relies on the control event property in Automations, these will need to be updated since the format has changed to include the additional detail.

    • Nodes that are “grouped” together in the ISY Admin Console will now be correctly identified and sorted, this will cause additional entities to be added to Home Assistant. If you were using this “group” feature to ignore some sub-devices in Home Assistant, you will now need to use the ignore_string in the name instead.

    • Turning on a light without providing a brightness value will use the ISY Device’s On Level property instead of turning on to full brightness (if Home Assistant doesn’t have a stored value for the last brightness).

    Sorting of certain devices based on the ISY’s Node Def ID and Insteon Type properties have been corrected to match the ISY’s provided device categories, as well as user feedback of incorrect sorting for specific devices. As a result, some entities that were incorrectly categorized will now appear under a different platform (e.g. switch to binary_sensor, light to switch, etc.)

    Both KeypadLinc Secondary Buttons and RemoteLinc2 Buttons have been moved from switch to sensor. This is because these buttons cannot actually be directly controlled via commands sent from the switch platform, doing so results in communication errors from the ISY because the commands are not valid. These devices are being moved to sensor instead of binary_sensor because they report a state in a range from 0 to 255; 0=Off, 255=On according to their last brightness/dimming level sent.

    The ISY994 integration now includes a restore_light_state option. In 0.109.0, a change was made to restore a light’s brightness to the previous state when turned on with no brightness parameter. This was, in part, to fix an issue where the light to turn on to full brightness when no parameters were given, regardless of the physical device’s On Level brightness setting. Using the On Level is now supported and is the default behavior. To keep the current behavior and use Home Assistant’s last brightness, set the restore_light_state to True or enable the option in the new config flow options.

    The following device node types have changed platforms to correct their categorization:

    • “BinaryControl” (SWITCH->BINARY_SENSOR)
    • “BinaryControl_ADV” (SWITCH->BINARY_SENSOR; IOLinc Sensor)
    • “EZIO2x4_Input” (SWITCH->BINARY_SENSOR)
    • “EZRAIN_Input” (SWITCH->BINARY_SENSOR)
    • “OnOffControl” (SWITCH->BINARY_SENSOR)
    • “OnOffControl_ADV” (New; Thermostat Control/Running Sensors)
    • “EZIO2x4_Input_ADV” (SWITCH->SENSOR, Analog input on EZIO).
    • “RemoteLinc2” (LIGHT->SWITCH),
    • “RemoteLinc2_ADV” (LIGHT->SWITCH),
    • RemoteLincs only report button presses as events, are not controllable and do not accurately report dimmable states.
    • New Insteon Types for BINARY_SENSORS: “7.0.”, “7.13.” (IOLinc/EZIO Sensors)
      • IOLinc sensor/control logic will be updated in PR-4 to sort them correctly into two different platforms.
    • New Insteon Type for LOCKS: “4.64.” added.
    • New Insteon Types for SWITCHES: “0.16.”, “7.3.255.”, “9.10.”

Release 0.110.1 - May 21

Release 0.110.2 - May 24

Release 0.110.3 - May 26

Release 0.110.4 - May 28

Release 0.110.5 - June 5

Release 0.110.6 - June 8

  • Fix mobile_app registering/update sensor values with an unknown state. Will unblock iOS app (#36566 - @frenck)

Release 0.110.7 - June 9

  • Fix mobile_app missing state in sensor registration (#36604 - @frenck)

All changes

Click to see all changes!