edcyang

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.

New Platforms

Release 0.91.1 – April 4

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

本站文章如需转载,请注明文章出处:https://www.hachina.io/16504.html
本站保留文章版权以及相关权益。