0.89: Nissan Leaf, PlayStation 4, Point alarm control, Owlet baby monitor

Blog
1

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

It’s time for release 0.89. It’s another great new release with some cool new features, bug fixes and improvements. The first cool new feature is that yet another car is integrated into Home Assistant: the Nissan Leaf. Both deConz and SmartThings integrations keep expanding to cover more devices.

This release introduces a new mobile app component. @robbiet480, who also works on the iOS app, has taken the best parts of the Home Assistant iOS app component and turned it into a standardized API that any mobile app can build upon. This will allow any mobile apps to integrate with Home Assistant with a great user experience. If you are a mobile app developer, please check the updated app integration docs. We will be fine tuning the API in upcoming releases. Feedback is welcome.

Noteworthy Breaking Changes

Custom Components file structure change: A significant change in how the “under the hood” of Home Assistant works has led to forcing platforms to be resolved based off the component path, if it exists.

Today, if you want, you can override the Hue light platform, but not the other parts of the Hue integration. If a future update evolves the Hue component, removing or changing internal methods that the custom platform relied upon, the custom platform will start failing (like this report).

To avoid this, we’re going to no longer allow custom components to be partial overlays (just a platform). Instead, if you want to override a built-in platform, you will need to override the whole component.

This is enforced by first resolving the platform as a component, and if it exists, limiting the lookup path to the component path.

Example: if I look up the hue component, and it is provided by a custom component, then all platform lookups will also be looked up in the custom component dir. The same works the other way around, if a user would only try to override hue/light.py but not hue/__init__.py, the custom platform will be ignored.

Paulus has written some detailed information about this change on the developers’ blog, if you’d like more information. The Great Migration by Paulus

Existing SmartThings configuration entries will be removed, including the SmartApp/Automation from the SmartThings app. Home Assistant will prompt you to configure the integration again or it can be invoked from the integrations page. The configuration process is the same as before. To prepare, have your personal access token and a mobile device with the SmartThings Classic App handy. This will not affect the naming of devices or entities and is a one-time inconvenience. The implementation switches over to the SmartApp access token to synchronize subscriptions during setup of the config entry, which cannot be done using the personal access token.

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

  • HomeMatic component’s wireless actors are having two RSSI values. The way the component was programmed one of them was being overwritten. With this new change, the rssi attribute of HomeMatic entities has been removed. As a replacement the attributes rssi_device and rssi_peer have been added. The attribute of rssi will no longer be available, you’ll need to update to rssi_device, and you can add rssi_peer now as well! (fixes #20900) (@dagobert - #20902) (homematic docs) (breaking change)
  • You can now specifiy an action when calling the yeelight_start_flow service on your yeelights. The default action will be ‘recover’ if you do not specify something else. This action will be taken after the flow stops. (@zewelor - #21195) (light.yeelight docs) (breaking change)
  • Custom platforms that override a built-in platform that has a component, should now also include the component in the custom_components/ folder. So if you want to override hue/light.py with a custom version, you will also need to provide/copy over hue/__init__.py. See details in main section about this change. (@balloob - #21070) (breaking change)
  • Automatic discovery of TP-Link switches, bulbs and dimmers. This is a continuation of #15329 and adds support for automatic discovery of TP-Link bulbs, switches, and dimmers based on the new config flow. The integration needs to be enabled either in the integration configuration or alternatively by adding tplink component to the configuration file. As the devices are now configured on the component, this is a breaking change for light.tplink and switch.tplink. (@rytilahti - #18091) (tplink docs) (light.tplink docs) (switch.tplink docs) (breaking change)
  • Enhance SmartThings component subscription. See details in main section about this change. (@andrewsayre - #21124) (smartthings docs) (breaking change) (new-feature)
  • The iperf3 sensor platform has been separated into a component and a sensor to remove the service from the sensor platform. Configuration options have changed, please review the documentation and select the correct options. (@rohankapoorcom - #21138) (iperf3 docs) (sensor.iperf3 docs) (breaking change) (new-platform)
  • The google_travel_time platform no longer has an update service, use homeassistant.update with the appropriate entity_id(s) instead. (@rohankapoorcom - #21153) (sensor.google_travel_time docs) (breaking change)
  • Add ADB server functionality to Fire TV. This change removes the get_source configuration option. (@JeffLIrion - #21221) (media_player.firetv docs) (breaking change)
  • With the addition of the SmartThings Cover platform, the SmartThings Sensor platform will no longer represent Door, Garage Door and Window Share attributes. Additionally, if the cover device reports battery status, the value will be present as a state attribute (battery_level) and not a discrete sensor. (@andrewsayre - #21192) (cover docs) (smartthings docs) (breaking change) (new-platform)
  • The Toon component was broken some time ago, so now requires a Toon API developer account and can be configured using the Home Assistant integrations. Support for Switches & Smoke detectors has been removed. (@frenck - #21186) (toon docs) (breaking change) (new-platform)
  • Addition of config for trusted networks auth provider. It is a breaking changes for users who manually configured trusted network auth provider. An invalid config error will be thrown and HA won’t be able to fully started. (It is NOT a breaking changes for user who didn’t manual configured trusted network auth provider.) (@awarecan - #21111) (breaking change)
  • For some HomeMatic devices the sabotage attribute is replaced by error. The value (if not 0) is a device specific error code. (@dagobert - #21009) (homematic docs) (breaking change)

Beta Fixes

All changes

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

Did someone forget to “push the release button”? The version is not yet available on the site for further details in the new components. :thinking:

Edit: Nvm… I was to excited. The documentation is up. Great work guys! :muscle:

3

the post looks unfinished, maybe they forgot NOT to push the post button? ahaha

4

I need to say a really big THANK you for the new “breaking change” format.

I really like that there are more and better explanations included in the notes about what changed and a summary of how to fix it and/or what to look for in the docs. It’s a great first step to improve communications between devs & users.

Good Job! :+1:

7 Likes
5

I’m not seeing the updated package on PyPi, is it pending?

EDIT: It is now.

6

Nothing broke from b3 so awesome.

Great work again guys…

7

I have seen 0.89 on PyPi now.

8

Yep, it is now!

9

Does anyone know if 0.89 has fixed the issue with 0.88 which stopped older browsers from being able to log in as detailed here?

Someone mentioned that 0.89 may have a fix couldn’t confirm 100%

10

Suppose to be fixed. Let me know if not.

Frontend fixes are not included in the release notes.

11

Ok, thanks very much, that’s great if it’s been fixed. :slight_smile:

Once I’m able to update, I’ll try logging on my device which was unable to login using 0.88. I’m using HassIO so it takes a while for the docker image to be deployed.

12

I’m getting a weird error when running the Check Home Assistant Configuration add-on, it doesn’t seem related to my config

[Info] Install done, check config now
Traceback (most recent call last):
File “/usr/local/bin/hass”, line 11, in
sys.exit(main())
File “/usr/local/lib/python3.6/site-packages/homeassistant/main.py”, line 375, in main
return scripts.run(args.script)
File “/usr/local/lib/python3.6/site-packages/homeassistant/scripts/init.py”, line 67, in run
return script.run(args[1:]) # type: ignore
File “/usr/local/lib/python3.6/site-packages/homeassistant/scripts/check_config.py”, line 84, in run
print(color(‘bold’, “Testing configuration at”, config_dir))
File “/usr/local/lib/python3.6/site-packages/homeassistant/scripts/check_config.py”, line 44, in color
from colorlog.escape_codes import escape_codes, parse_colors
ModuleNotFoundError: No module named ‘colorlog’
[Error] Wrong config found!

1 Like
13

Getting same error as TravlinMax.
I had only installed the addon this morning and it ran fine. Just ran it again and got the error

1 Like
14

Scratch that, still getting the weird error.

15

I’m obviously not a dev but thinking about the “great migration” I’m wondering how it all works if there are two custom components using the same platform? I’m assuming the devs of those two (or more) custom components would need to somehow collaborate and come up with a hybrid?

I’m just thinking that I have three “sensor” custom components so how does that work? Which custom component will the “sensor” component load?

I can see this easily getting confusing. I’m already confused. :crazy_face::wink:

16

hassio on qemux86 - I got it a few hours ago.
https://hub.docker.com/r/homeassistant/qemux86-64-homeassistant/tags

1 Like
17

Let’s say you have 3 sensor platforms that you want to override with custom things, for example: nest, coinbase and zha. You would not have to copy over the sensor component, but instead your config folder should have these three folders and appropriate files:

  • <config>/custom_components/nest/
  • <config>/custom_components/coinbase/
  • <config>/custom_components/zha/
3 Likes
18

The breaking change format is brought to you by @hdsheena :tada: .

I do want to add a note here, changes like this are not driven by developers. They are driven by the community, which includes both users and developers. Making a list of breaking changes is not limited to developers. This is not an us vs them, this is a community effort.

There are a lot more things around releases and running the community where anyone can get involved, from triaging issues during the beta, notifying authors of new features that forgot to add docs.

10 Likes
19

Which would those files include? Some files from the standard component or just the modified custom files?

If it’s just the modified files then I would think that the confusion may be overblown since that is the way I have everything right now. For example i have right now:

/custom_components/authenticated/sensor.py
/custom_components/feedparser/sensor.py
/custom_components/nws_alerts/sensor.py

What other files would need to be moved into those directories?

20

did google location sharing brake for anyone else? I removed base_url (under http) as it is causing issue somewhere else. may be that caused it.

EDIT: fixed in 89.1