It’s time for the 0.98 release. As Home Assistant grows, some features will sometimes be left partially implemented, leaving things to be desired. In this release we’ve been focusing on tieing up these loose ends, sometimes with new features. Getting better all the time!
One of the things that we’ve been improving in this release is entity management. Historically we’ve let this up to integrations, but that caused users to learn multiple ways and more work for integration developers.
Generally entity management is not that important, you want all the entities created by your integrations! However this was less the case when we started migrating over device trackers. This became clear when we migrated over Unifi.
So in this release we’re introducing a couple of new features that are available for all entities in the entity registry and integrations that are set up via config entries.
The first feature is that it’s now possible to disable entities. If an entity is disabled, it will not be added to Home Assistant when an integration adds it. So now it will be easy to manage which entities will show up. This option is accessible from the entity registry
The second feature is a new option to automatically disable any new entities that an integration discovers. In the case of a device tracker, newly connected devices to the network won’t be added anymore. This option is accessible from the integration details page via a button on the toolbar at the top.
With these two features we are now at feature parity with the filtering features that are available in the device tracker integration. Next step will be polishing of the person integration to get all those shiny new device tracker entities under one roof.
Screenshot of integration system options
We introduced config entries last year as our way as a generic way for integrations to store authentication and configuration. By allowing integrations to define the storage format, there are no more breaking changes for anything stored inside config entries!
Config entries also work great with people who prefer configuration.yaml. At startup a config entry is created/updated with the configuration.
With this release @kane610 added a new possibility for integrations to offer options in the UI. Options that previously required you to edit configuration.yaml can now be offered via the interface.
Screenshot of Unifi config options
Devices and services can receive updates that can cause integrations to break. This is frustrating and sometimes the cause can be hard to track down. Usually the users on forums/chat are aware and can help redirect people in the right direction, but that’s not a scalable solution!
So to combat this, we’re launching Home Assistant Alerts. Home Assistant Alerts is a website that will track known issues and explains in user friendly language what is going on. Alerts can be tagged with applicable Home Assistant versions, integrations and Python packages.
In the future we’re planning on integrating this directly in Home Assistant, so that users can be pro-actively notified of issue related to their configuration.
If you run Home Assistant via Docker (not Hass.io) and are using the
homeassistant/home-assistant container, the images are now using the same images as hass.io, which are using Alpine Linux instead of Debian.
The hass.io images are a third of the size of the old images and are heavily optimized thanks to the hard work by @pvizeli.
This change will only impact you if you were extending or customizing the image with Debian packages. If you want to continue to use the Debian based images, you can find the Dockerfile for the old images here.
For more background on this decision, see ADR-006.
With this release we have deprecated integrations that rely on webscraping. These will be removed from Home Assistant in a future release. Our scrape integration will remain part of Home Assistant.
Webscraping is fragile, breaks often requires frequent updates and there have been occassions where websites have banned our users.
Users that rely on these integrations can continue using them as custom components.
For more background on this decision, see ADR-004.
Mason Made created a great video walking through her Lovelace UI with a fancy custom sidebar. Check it out:
Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.
Integrations which make use of web scraping and are pending for removal in Home Assistant 0.100.0 ADR-004:
Googlehome - Removed - In recent months this integration was broken when Google changed the port they serve this information on, in addition to requiring a token header in the request. That method requires the user to have a rooted android device, and even then then the “result” was not the best, since you often need to get that token. As an alternative to the device tracker, users can look into https://community.home-assistant.io/t/monitor-reliable-multi-user-distributed-bluetooth-occupancy-presence-detection/68505 - (@ludeeus - #26035)
Nissanleaf - Nissan leaf European API no longer supports location control. The
nissan_connect:element from the homeassistant
nissan_leaf:configuration must be removed. - (@filcole - #26139) (nissan_leaf docs)
Updater - The updater component is now a binary sensor that is always available. The entity ID is
binary_sensor.updater. The state is on/off depending on whether an update is available or not. The latest version as well as the release notes are attributes of this binary sensor. Automations that are listening for the existence of
updater.updatershould now trigger when
binary_sensor.updaterchanges to on. This makes the component more transparent and understandable for the user. Additionally, it is visible if there is an error or the source (https://updater.home-assistant.io/) is outdated. - (@Santobert - #25418) (updater docs)
Mikrotik - The Mikrotik device tracker integration is now a component (hub) with a device tracker platform. If you have a device_tracker section where
mikrotikis a platform in your configuration.yaml you will need to move it to the hub config section for
mikrotikand make sure you follow the new config format. - (@slackr31337 - #25664) (mikrotik docs)
Example configuration entry:
mikrotik: - host: 192.168.88.1 username: !secret router_user password: !secret router_pass ssl: true - host: 192.168.88.2 username: !secret capsman_user password: !secret capsman_pass ssl: true
Prometheus - Previously, the integration would create too many metrics based on
entity_idname which would pollute and fill the database. The naming of metrics has been changed and doesn’t use the
entity_idanymore. Any consumers of the prometheus data will need to be changed to use the new names. The user can now also use the new
component_config_globto remap the metrics any way the user sees fit. - (@perosb - #24103) (prometheus docs)
Example configuration entry:
prometheus: namespace: hass component_config_glob: # override metric for RFLink devices sensor.*_hum: override_metric: humidity_percent sensor.*_temp: override_metric: temperature_c sensor.*_bat: override_metric: battery_percent filter: include_domains: - sensor - lock
Sonos - This change rejects previously accepted calls using content_types (image, tvshow, video, episode or channel) when using
media_player.play_media, and changes the behavior of a content_type of “playlist” to play a Sonos playlist, rather than a URL. - (@ahertz - #26054) (sonos docs)
Statistics - The names of statistics sensor no longer get
countappended automatically, respecting the name configured by the user. If you use this integration, this name change will affect the name of the entity. - (@frenck - #26119) (statistics docs)
Example configuration entry:
- platform: statistics name: 'MiAP2 PSI Stat' entity_id: sensor.mi_ap2_aqi
This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2019/08/28/release-98/