0.94: SmartHab, Watson TTS, Azure Event Hub

![](upload://nsljUqATcL6Y1832Hw4l2JcwiCL.png)

It is time for the 0.94 release and there is some seriously good stuff in this release. We’re working hard on polishing everything and getting ready for the big Home Assistant 1.0 release. And we’re getting closer. So close actually, that this is the first release that can be installed and configured without touching a text editor! Onboard, configure integrations, manage automations and scripts all from the UI.

This milestone has been achieved thanks to the hard work by @emontnemery who contributed the ability to store the core config in storage: name, location, unit system, time zone. We still allow users to store their core configuration in configuration.yaml, which will take precedent when defined. This means that it is a non-breaking change. Core config is now set during onboarding and can be edited in the general page of the config panel.

Another cool new feature is the total revamp of how you manage which entities are exposed to Google Assistant via Home Assistant Cloud. From the cloud UI you can now click “Manage Entities” and you are brought to the Google Assistant entity manager. From here you can enable which entities are exposed and, if you deem appropriate, choose to disable the two factor authentication on your garage door (the asking for a pin).

![](upload://sRQAyrH7YAh5YArR1KoXP0txI0C.png) Screenshot of the new user interface to manage which entities are exposed to Google Assistant.

Discovery

Discovery has been mordernized thanks to @Kane610 and with the input from @Jc2k. Each integration is now able to specify how they can be discovered in their manifest, and the new zeroconf and ssdp integrations will do the rest. The new discovery is non-obtrusive: no devices are set up without approval by the user. Instead, you will need to approve each discovered integration. You can find them in the discovered section of the integrations page in the config. Only a handful of integrations have been migrated to the new approach in this release: Hue, LIFX, Deconz, Trådfri, Axis, ESPHome, HomeKit Controller.

The new discovery is now part of the default config. If you are not using the default config, add ssdp: and zeroconf: to your configuration.yaml.

Deprecating Python 3.5 support

This release has deprecated support for the almost 4 year old version 3.5 of Python. The first Home Assistant release after August 1 will drop support. This is part of our newly adopted Python support approach.

This will only impact you if you are running a custom installation of Home Assistant. This will not impact anyone using Hass.io or Docker. If you are using hassbian, you can upgrade Python by following these instructions.

Modernizing the device tracker

This release also introduces a long overdue overhaul of how the device tracker works. We are introducing this overhaul piece by piece, focusing first on device tracker platforms that push their updates to Home Assistant: mobile app, OwnTracks, GeoFency, GPSLogger and Locative.

These integrations will no longer use known_devices.yaml but instead use entities, like all other integrations in Home Assistant. You can change the name and entity ID via the UI. It is no longer posible to merge the devices with other device tracker entities. This was flaky at best. You should now use the new person integration for this.

Improved hass.io builds

We have been working hard on improving Hass.io builds. It’s our goal to make the update process faster and more predictable. A build can now be online in as little as 30 minutes after a new release has been tagged. This is thanks to a new wheel-based infrastructure build by @pvizeli with input from @frenck. With Python wheels, we will build all the requirements of integrations ahead of time, and so a new version of Home Assistant is now just putting pieces together.

Because of this, we changed how packages are installed when running Home Assistant inside a Docker container. It will now install the packages into the Python environment inside the container, instead of storing them in the config/deps folder, which lived outside the container.

Note: Because of the new way packages are installed, Home Assistant on Hass.io will take longer to start the first time it is launched after an upgrade. Don’t worry and let it finish! We are working on making this process faster in the future.

Note 2: If you are using Hass.io or a dockerized version of Home Assistant, this release will one time clear the deps folder in your config folder.

New Integrations

New Platforms

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.

Reporting Issues

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

  • Sun - Inspired by a reddit report, the sun.sun sensor has been tuned so that it doesn’t update nearly as frequently. Previously the sun.sun sensor was updating every 30 seconds, day and night. Now it updates dependent on the solar elevation. This could possibly be a breaking change for some users as it updates less frequently. (@Swamp-Ig - #23832) (sun docs)
  • Doorbird -_Refactored_- This change cleans up the code for the component quite a bit. Schedule manipulation has been removed and HTTP views have been consolidated. The configuration changes should result in an overall easier experience for setting up a Doorbird in HA and allow for new Doorbird events to be utilized without having to update the component as often. No changes for switches or camera integrations of this component. (@oblogic7 - #23892) (doorbird docs)

    Example configuration:

     doorbird:
       devices:
         - host: 10.10.10.10
           token: 12345678abcd
           name: Side Entry
           username: abcd1234
           password: abcd4321
           events:
             - button_1
             - unit_1_button
             - movement
             - relay_1
             - lock_relay
    
  • Plex
    • Configuration option include_non_clients has been removed. The component was unnecessarily complicated with separate update methods for Plex devices and Plex sessions. This change always updates all known Plex clients regardless of type. The previous design also had issues where the Plex sessions are never polled if there are no Plex clients connected at startup and only ‘session’ client types connect after that point. This leads to a failure to discover new devices. This is a breaking change if the config option include_non_clients is being used since it has been removed. (@jjlawren - #24038) (plex docs)

    • Configuration options use_custom_entity_ids and entity_namespace have been removed. This change will prepend the display name (and therefore the default entity_id) of each newly created entity with ‘Plex’ for easy identification. Users may customize each display name and entity_id as desired via the Entity Registry. Entities created before this PR will not be affected as the unique_id remains the same. (@jjlawren - #24072) (plex docs)

  • Verisure - Base entity_id of alarm_control_panel on alias of installation set by giid rather than first installation. This is a breaking change as it will change entity_id of alarm_control_panel in cases where a user is configuring an installation using giid that is not the first installation. (@tkjacobsen - #23606) (verisure docs)
  • Zestimate - Changed name property to return Zestimate and the property address. This will make it easier to distinguish multiple Zestimate sensor entities in the UI and is a breaking change as it will change entity_id of Zestimate sensors. If you have automations relying on your Zestimate sensor(s) you may need to revisit them to fix the ID’s to the new ones. Also, you may need to update your Zestimate sensor(s) in your Lovelace UI. (@dreed47 - #23770) (zestimate docs)

  • Python - Deprecation - Python 3.5.3 support will be removed in the first release after August 1, 2019. This release will print a warning if a soon to be unsupported Python version is used. A notification will be present if Home Assistant is run under 3.6.0. (@balloob - #24177)
  • Async - Developers only - hass.components.frontend.async_register_built_in_panel is no longer an async function. This allows removing panels form the frontend on the fly, and fires and event when panels are added/removed so the frontend knows when to reload. (@balloob - #24184)
  • TP-Link - Distress Signal - Add a deprecation warning for tplink device_tracker (@rytilahti - #24236) (tplink docs)

Beta Fixes

All changes


This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2019/06/05/release-94/
2 Likes

Just tried updating to 0.94. Running HA in a pyvenv. See the following error message in my log on restart:

019-06-05 13:36:45 ERROR (MainThread) [homeassistant.setup] Error during setup of component zeroconf
Traceback (most recent call last):
  File "/opt/homeassistant/lib/python3.6/site-packages/homeassistant/setup.py", line 156, in _async_setup_component
    component.setup, hass, processed_config)  # type: ignore
  File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/opt/homeassistant/lib/python3.6/site-packages/homeassistant/components/zeroconf/__init__.py", line 56, in setup
    properties=params)
TypeError: __init__() got an unexpected keyword argument 'addresses'
2019-06-05 13:36:45 ERROR (MainThread) [homeassistant.setup] Unable to set up dependencies of ios. Setup failed for dependencies: zeroconf
2019-06-05 13:36:45 ERROR (MainThread) [homeassistant.setup] Setup failed for ios: Could not set up all dependencies.

Please disregard my message. I did not fully read all of the release notes. I added the following 2 lines to configuration.yaml, restarted and all good!

ssdp:
zeroconf:
3 Likes

I have errors with switch/flux component:

2019-06-05 20:33:48 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/flux/switch.py", line 209, in async_flux_update
    if stop_time <= start_time:
TypeError: '<=' not supported between instances of 'NoneType' and 'datetime.datetime'

Thanks for the great work again guys.

1 Like

Perfect upgrade! No issues! Simply amazing as always!

Edit, spoke too soon, all my owntracks users are showing up with _2 appended to them, this alone would not be a problem, but the new entities are not in the all_devices group.

I too saw this on the first start after the upgrade, upon restart of HA, it did not come back. I have restarted 2x just to be sure, and it did not come back.

Looks like fritzconnection==0.6.5 is missing in 0.94.0’s Docker container image. It cannot be installed, if the container is run by a non-root-user:

homeassistant | 2019-06-05 22:22:10 ERROR (SyncWorker_5) [homeassistant.util.package] Unable to install package fritzconnection==0.6.5: ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/usr/local/lib/python3.7/site-packages/fritzconnection-0.6.5.dist-info'
homeassistant | Consider using the `--user` option or check the permissions.
homeassistant | 2019-06-05 22:22:10 ERROR (MainThread) [homeassistant.requirements] Not initializing fritz because could not install requirement fritzconnection==0.6.5
homeassistant | 2019-06-05 22:22:10 ERROR (MainThread) [homeassistant.setup] Unable to prepare setup for platform fritz.device_tracker: Could not install all requirements.

Another great release! Thank you to all the contributors.

Really appreciate the increased attention to UI and user experience lately. I think it’s an area where significant and meaningful improvements can be made. Making it easier to get started and configured will make Home Assistant a more attractive platform to a lot more people.

2 Likes

Has anyone figured out how to use the new device trackers? I am not seeing any docs explaining how to transition from known_devices to the new whatever it is.

The new way is how you manage any other entity in Home Assistant: via the entity registry. Access it either via config panel, customize or the settings icon in the more info dialog.

Ahh, okay I had gpslogger set in my config still and i wasn’t seeing any device_trackers at all. Removed gpslogger and rebooted and they showed up. @balloob thanks for the quick response.

Are there plans to allow managing cloud devices via the UI for Alexa as well?

1 Like

Upon upgrade my owntracks entities were doubled adding a _2 to each owntracks entity, none of them were added to group.all_devices. So I downgraded, setup persons, and then upgraded again.

What I find is that if I remove my known_devices.yaml (with HA stopped), upon startup none of my owntracks entities appear in the group.all_devices. If I restore the old known_devices.yaml then the owntrack entities appear in the group.all_devices. Is there a proper way to remove the known_devices.yaml and still have device tracker entities be part of the all_devices group? Its like the “track: true” is missing.

Hmm I’m having the same problem but added both entries in my configuration.yaml file then rebooted a few times. Still having trouble with ios failing and causing dependency for device_tracker not to load. Any ideas what may be causing this? My device trackers include nmap, unifi, gpslogger, and tile.

EDIT: I think I’m good now. I had the discovery: section disabled. So I enabled it and restarted. No more errors.

This update, unlike most previous ones, actually went rather smooth. The new way to add homekit devices to the homekit controller is much appreciated as they will also show up in the integrations now.
Thanks for the awesome work. I just have one question though. I can’t seem to get my device_tracker working, apparently it is a legacy one:

Error setting up platform legacy
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/device_tracker/setup.py", line 69, in async_setup_legacy
    self.platform.get_scanner, hass, {DOMAIN: self.config})
  File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/tado/device_tracker.py", line 33, in get_scanner
    scanner = TadoDeviceScanner(hass, config[DOMAIN])
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/tado/device_tracker.py", line 64, in __init__
    hass, cookie_jar=aiohttp.CookieJar(unsafe=True))
  File "/srv/homeassistant/lib/python3.6/site-packages/aiohttp/cookiejar.py", line 55, in __init__
    super().__init__(loop=loop)
  File "/srv/homeassistant/lib/python3.6/site-packages/aiohttp/abc.py", line 146, in __init__
    self._loop = get_running_loop(loop)
  File "/srv/homeassistant/lib/python3.6/site-packages/aiohttp/helpers.py", line 267, in get_running_loop
    loop = asyncio.get_event_loop()
  File "/usr/lib/python3.6/asyncio/events.py", line 694, in get_event_loop
    return get_event_loop_policy().get_event_loop()
  File "/usr/lib/python3.6/asyncio/events.py", line 602, in get_event_loop
    % threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'SyncWorker_18'.

All other components (and this still baffles me :stuck_out_tongue:) are working, I only had to remove one line in discovery that’s it. Amazing!

I use Hass.io but no update panel has appeared to allow me to upgrade. Is that just me? I’m currently running 0.93.2

there’s always a delay for HassIO updates. You just need to wait, or manually force the update using the command line:

hassio homeassistant update --version=x.y.z

substituting the x.y.z for 0.94.0 in this case

Hassio versions are now available almost immediately… within 30 mins of being tagged. 0.94.0 is certainly available from the front end right now and has been for a few hours.

If you don’t see it you might need to check/update supervisor and/or reload supervisor.

That’s a nice improvement, I didn’t realise this was the case now. Cheers!

Every single Lifx WiFi (HomeKit) bulb disappeared (is unavailable) post upgrade. I have removed homekit from the discovery config; I also tried the Lifx integration which just said it could find any Lifx bulbs in the network. I am sitting here looking at one on as well as seeing them on my WiFi.