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

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

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.

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

Screenshot of the HACS integration with its icon shown.

OpenZWave integration now in beta

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

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.

Weather card

Internal & External URLs

Support for “not” conditions in automations

# 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
    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.

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.

Supervisor

Have you seen the new supervisor UI? @ludeeus did a great job redoing it’s 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.

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 breaking 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

• Blink, done by @fronzbot
• HomeKit, done by @bdraco
• Hunter Douglas PowerView, done by @bdraco
• Lutron Caséta, done by @chrisaljoudi
• Mill, done by @Danielhiversen
• ONVIF, done by @hunterjm
• Pi-hole, done by @shenxn
• Tibber, done by @Danielhiversen
• Tuya, done by @ollo69
• Universal Devices ISY994, done by @shbatm

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

• 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: https://www.home-assistant.io/integrations/fortios/ –
  (@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 breaking changes were introduced:

  Click see all breaking 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