0.91: More streaming, better Zigbee, cameras with ESPHome

It’s time for release 0.91 and this release is all about streaming cameras. Home Assistant 0.90 allowed users to stream cameras in the frontend and play camera streams on Chromecasts. This release adds support to:

  • Record camera streams to disk with the new recording service for the camera integration
  • Support to ask Google Assistant to show your camera on its display or on a Chromecast
  • Preload streams so that bringing up a stream on a device is super fast. This can be configured on a per camera basis via the camera more info dialog.

Thanks to @hunterjm for all this work on this! ❤️ Check the latest release of the Home Assistant podcast for an interview with @hunterjm about streams in Home Assistant.

We’re still in the process of updating more cameras to support the stream component. If you want to try it today, the easiest approach is to configure a generic camera with a stream_source or buy a camera that supports the standard ONVIF protocol.

A BIG shout to @awarecan, who has migrated our CI infrastructure to CircleCI and Codecov. CircleCI’s advanced caching and code splitting controls has speed up tests significantly. Codecov tracks our code coverage and generates detailed reports for each contribution to see how well it is tested.

And in case you missed the announcement, we will soon start working on an official Android app. And in case it wasn’t clear, our other announcement, that we would occassionally show ads in the UI, was an April fools joke 😁.

Notable breaking change

We finished the great migration. All built-in platforms are now in their own folder. This means that if you had a custom component or platform that had the same name as a built-in one, you have to rename it. If you still have platforms in your custom_components/ directory in the old file format, sensor/my_platform.py, rename it to my_platform/sensor.py. It still works but it will not be supported in a future release.

Thanks to @Swamp-Ig, @robbiet480 and @cgtobi for their work on this!

Trusted networks now support trusted users

Trusted networks has been updated by @awarecan to allow specifying specific uses that specific IP addresses are allowed to log into. If a user is logging in with trusted networks and there is only a single user, you can now configure it to skip the login form and automatically login. See the documentation for more info.

ESPHome Cameras

This release adds camera support to the ESPHome integration. If you haven’t heard about ESPHome yet, it allows you to create your own sensors and smart devices and configure them using YAML. With Home Assistant 0.91, it is now possible to integrate cameras. This means that you can have a WiFi enabled camera that integrates automatically into Home Assistant for as little as $9 😲.

Zigbee ZHA pairing experience

Every release our Zigbee integration is getting better thanks to the hard work by @dmulcahey, @damarco and @Adminiuga. This release introduces a brand new pairing experience. While pairing mode is enabled, any device that is getting paired will instantly show up, allowing users to configure the name and the area.

VSCode hass.io add-on

If you run hass.io on an Intel NUC and haven’t seen it yet, check out the VS Code add-on by Frenck.

I'm so excited to release this add-on 😃

Today I give you the Visual Studio Code!! add-on for @home_assistant! 🎉

The full VSCode experience in your HA frontend including the HA VSCode extension preconfigured out of the box!https://t.co/7bQ6JIF8yQ#InternetOfThings #hassio pic.twitter.com/8CwTfKVJvV

— Franck Nijhof (@Frenck) March 26, 2019

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

  • Z-Wave - The usb_path in configuration.yaml now overrides config entry usb_path. This is potentially a breaking change if people have a stale usb_path setting in configuration.yaml that’s no longer accurate. This should help reduce the number of people that need to manually edit the storage/core.config_entries file if their usb_path changes. (@cgarwood - #22038) (zwave docs)

  • iOS - Improves the text description of ATTR_BATTERY_STATE_UNPLUGGED from Unplugged to Not Charging as many new iOS devices now use Wireless charging and there is no concept of “Plugging In”. This is potentially a breaking change if you have automations making use of “unplugged”. (@FattusMannus - #22152) (ios docs)
  • Iliad Italy - Removed - This was removed because it uses webscraping. (@eliseomartelli - #22175)
  • Netgear lte - The previous three components (network, notify, and sensor) now fall under one netgear_lte component. Check the updated documentation for more information. (@amelchio - #22105) (netgear_lte docs)
  • API streams sensor - Removed - This sensor component was designed to count connected front-end clients. However, it depended on the implementation details of other components, and has therefore been broken since 0.80, so it has been removed. The replacement sensor is now the websocket_api sensor, which does basically the same thing apart from the rename. (@Swamp-Ig - #22200) (websocket_api docs)
  • Public Transit (GTFS)
    • The state for this sensor component was a countdown in minutes. If the next departure was in a few hours, this number became quite large and a tad harder to rapidly calculate mentally (463 minutes anyone?). The sensor’s state output has been changed from minutes to an ISO 8601 UTC timestamp, which allows the UI to interpret the state as needed. (@renemarc - #21053) (gtfs docs)
    • Sensor updates were running many database queries to populate attributes, on top of the bus schedule queries themselves. This is doubled with two sensors. That led to a lot of slowdowns for everything else when using an SD card! Considering that some data never changes (agency, routes…) and that others like departure times are good until invalidated, now we fetch such metadata at first and then only when relevant changes do occur. GTFS sensor attributes are now named using the standard snake_case format. (@renemarc - #20966) (gtfs docs)
  • Yeelight - This is now its own component and has been broken out from the light platform. More Yeelights are being released with more features and this will make if possible to support them. Examples would be adding sensors for a ceiling light, getting the current power mode (daylight/nightlight), or supporting switches to turn moonlight on or off without having to use a service call. Make sure to visit the updated documentation. (@zewelor - #21593) (yeelight docs)
  • Axis - Events supplied from component might differ. Events will not be configurable in the beginning but will instead provide a subset set of events supported per device. This will be configurable in a later stage when config entry options are available. Configuration.yaml support for Axis component will be removed in the future so make sure to remove references to Axis component after upgrade. (@Kane610 - #18543) (axis docs)
  • HTTP - Lower severity level of log messages from http.view (@thomasloven - #21091) (http docs)
  • Dark Sky - Dark Sky provides hourly forecasts for various monitored conditions. This change creates new sensors for each hourly forecasted condition with suffix _<hour>h while adding the suffix _<day>d to the daily forecasted conditions. For example, now a sensor.dark_sky_summary_<day>d and sensor.dark_sky_summary_<hour>h will be created if the forecast and hourly_forecast parameters are populated. (@rtclauss - #21820) (darksky docs)
  • Konnected - This will change the internal unique_id for Konnected switches (i.e. siren, buzzer, generic switch). Users will need to manually remove the orphaned switch entities from the entity registry after updating and re-configure any changes stored in the entity registry (i.e. name and entity_id), as their unique IDs will change. (@heythisisnate - #22389) (konnected docs)

  • Mopar - The mopar sensor platform has been broken up into a base component with sensor, switch, and lock platforms. The sensor.mopar_remote_command service has been removed since the functionality has been folded into the new platforms and the new mopar.sound_horn service. Please view the documentation to see the new setup instructions. (@rohankapoorcom - #21526) (mopar docs)

Beta Fixes

All changes


This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2019/04/03/release-91/
4 Likes

Don’t know about you all, but I’m pumped!

3 Likes

Unleash big brother, ESPHome camera! :smiley:

There are some really useful breaking changes in this release.

Good Job!

It’s first time I wasn’t waiting so much for release… So much stuff seems to be working already… :wink:
But then I look at my to-do wishlist regarding HA and wait for next oppoturnities.

Keep up good work :slight_smile:

1 Like

Broken on FreeBSD if you use zwave due to a compilation bug in open-zwave :frowning:

Yeelight doc is 404.

2 Likes

Great workshop everybody! Looking forward to use this in my camera’s

Que? What doc? Try posting a link.

He means this one returns 404:

seems ok now

Yep, just after some refreshes it works for me too now. =)

Does anyone know how to deal with this situation in the light of this:

I have a custom component based on rflink, just a few changes.
My HA writes LOADS of errors in log like

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/state.py to state/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/state.py to state/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/time_pattern.py to time_pattern/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/state.py to state/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/event.py to event/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/template.py to template/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/time_pattern.py to time_pattern/automation.py. This will stop working soon.

2019-04-03 13:11:50 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/mqtt.py to mqtt/automation.py. This will stop working soon.

2019-04-03 16:38:26 ERROR (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change automation/state.py to state/automation.py. This will stop working

Apparently all these is because rflink uses mqtt, automation, time etc.
What is the best way to get rid of these errors? It still works, but it’s very annoying and could hide real errors easily…

The only way to remove the error is to fix the problem, suggest you contact the dev of the custom component to resolve

it is standard rflink component. it is working fine when inside HA
but if I copy the whole folder to /custom_component/ and rename, errors appear.
do you understand?

UPDATE: after upgrading to 0.90.0 (as hassio ha update --version help updated itself to the latest beta) I can see no more such errors, possibly was caused by using beta…

however, my monster-card based card no longer works :frowning: and there are no errors in log…
UPDATE2: it actually works, but for some reason all automation that are in that card were off - WEIRD.

maybe this thread will assist

1 Like

Thanks to everyone for this new release!
Special thanks to @awarecan for the Skip Login feature! :smiling_face_with_three_hearts:

Here we go again. After updating I have no mqtt devices connected.

Devices appear to be connecting to the mqtt server ok (though I see that usernames and passwods are being logged in the clear!) e.g.:

1554375055: New client connected from 10.1.1.189 as sonoff_spare_bedroom_heater (c1, k15, u'mqtt_user').
1554375055: |-- mosquitto_auth_unpwd_check(mqtt_user)
1554375055: |-- ** checking backend http
1554375055: |-- url=http://127.0.0.1:8080/login
1554375055: |-- data=username=mqtt_user&password=[redacted]&topic=&acc=-1&clientid=

system log:

19-04-04 10:55:49 INFO (MainThread) [hassio.auth] Auth request from core_mosquitto for mqtt_user
19-04-04 10:55:51 INFO (MainThread) [hassio.auth] Success login from mqtt_user
19-04-04 10:55:52 INFO (MainThread) [hassio.auth] Auth request from core_mosquitto for mqtt_user
19-04-04 10:55:55 INFO (MainThread) [hassio.auth] Success login from mqtt_user
19-04-04 10:55:55 INFO (MainThread) [hassio.auth] Auth request from core_mosquitto for mqtt_user
19-04-04 10:55:57 INFO (MainThread) [hassio.auth] Success login from mqtt_user
19-04-04 10:55:57 INFO (MainThread) [hassio.auth] Auth request from core_mosquitto for mqtt_user

Tried restarting the mqtt server (mosquito addon). No change.

EDIT: restarting HA fixed it. Why? Who knows. Sigh.

Nice work on the camera streams, I’ll have to see if I can get my raspberry pi cam to work with it. :slight_smile:

Anyone using the alexa media player custom component linked here:

I’m getting

WebSocket Error [SSL: BAD_LENGTH] bad length (_ssl.c:2337)

Since going over to 0.91, is it just me or are others getting this?

Hey Tom

i have found sometimes when doing updates, i have also needed to do an extra restart.
Maybe it has to pull down updated libraries?

1 Like