0.80: Lovelace updates, webhooks, TRÅDFRI switches

Blog
1

October 12, 2018. 12 days into Hacktoberfest and it’s been busier than ever on the repositories. On the main repo, 43 open, 104 closed. How the documentation team is still alive, I don’t know: 26 open, 234 closed. If you’ve opened a contribution that is pending a response, that’s probably because we’re busy elsewhere or are taking some well deserved rest.

Alright, new release, we got some cool stuff! Let’s start with our Lovelace UI. We have integrated into Lovelace UI some of the custom cards that our amazing community have built, making them easily accessible to all users. The cards are Gauge and Sensor:

lovelace-glance-sensor.png1016×382

Next up is a new way to get data into Home Assistant: webhooks. With the introduction of auth and with the introduction of long-lived access tokens, we realized that it’s still annoying to have to give full HA access to an app just to get a piece of information in Home Assistant. So with webhooks we can generate unique URLs that are inprobable to guess, and data delivered to the webhook will only go to the designated automation or component. This feature is available for component developers to integrate, or for users via the new automation webhook trigger.

config-ifttt.png1400×686
Configuring IFTTT via th integrations panel.

On the devices side, we got basic support for the new IKEA TRÅDFRI switches, Honeywell evohome controllers (EU-based) and if you want to control your pool, you can now do that with the new AquaLogic integration.

New Platforms

New Features

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

Beta Fixes

All changes

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2018/10/12/release-80/
5 Likes
2

Hurricane Michael took out electricity and the whole ceiling will crumble down to my bed. The tree fell through the roof and drenched my components along with my $900 Marantz receiver in water. Thankfully, my server and desktop computer is safe.

20181010_153749
20181010_1537491646×3292 1.97 MB

My mom’s house is in Altha, FL. That’s where I live.

1 Like
3

Just FYI you also need to remove ‘expose_by_default’ from the configurationa.yaml entry for the Google Assistant component in 0.80 otherwise that component fails to load.

2 Likes
4

This part didn’t change. expose_by_default should still work. Could you submit an issue in Issues · home-assistant/core · GitHub if it breaks.

5

I am running 0.79.3 HA in docker, but 0.80 is not showing up.

6

Like with Hass.io, docker images take a few hours to appear.

1 Like
7

Great work!

One question about webhook

Can the zone enter/leave be placed on the same automation?

  • enter
  • leave

Thanks!

8

Thanks, good to know.

9

Can the new webhooks be used with Owntracks? I tried previously with the long-lived access tokens and couldn’t get that to work. This is the only thing keeping me on the legacy password.

1 Like
10

PR is already open https://github.com/home-assistant/home-assistant/pull/17034

1 Like
11

Perfect! Thanks!

12

Did you mean exclude_entities? - had to remove that for it to work for me.

Also, when setting it up in Google Assistant I kept getting a popup about “check for connection”, had to set the “Client Secret” on the Google Console to match the “project_id” inside the HASS Configuration for it to work - even then Google Assistant threw up the same error, but added HASS anyway…

13

I am seeing below error since upgrading frequently appearing while using the UI.

2018-10-12 22:10:47 ERROR (MainThread) [aiohttp.server] Unhandled exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/aiohttp/web_protocol.py", line 410, in start
    await resp.prepare(request)
  File "/usr/local/lib/python3.6/site-packages/aiohttp/web_response.py", line 300, in prepare
    return await self._start(request)
  File "/usr/local/lib/python3.6/site-packages/aiohttp/web_response.py", line 608, in _start
    return await super()._start(request)
  File "/usr/local/lib/python3.6/site-packages/aiohttp/web_response.py", line 367, in _start
    await writer.write_headers(status_line, headers)
  File "/usr/local/lib/python3.6/site-packages/aiohttp/http_writer.py", line 110, in write_headers
    self._write(buf)
  File "/usr/local/lib/python3.6/site-packages/aiohttp/http_writer.py", line 67, in _write
    raise ConnectionResetError('Cannot write to closing transport')
ConnectionResetError: Cannot write to closing transport
14

Just wondering - did anybody try the new Google Assistant auth with the apache proxy?


I’m always getting “Account linking failed”.
It worked perfectly before though. And I’ve even setup a new “skill” in the “Actions on Google”.
I’m gonna try to debug it further.
15

That sounds not right, client secret can be any string, we didn’t verify it. We didn’t change exclude_entities config, could you make sure your yaml file format is correct?

16

If you can login your HA via your proxy, Google Assistant auth should work as well, they are using same OAuth flow.

17

Okay. Weird. Thanks for the info!

18

This is more of an example of a tree traversal than a webhook, but you could write an automation to close that new hole. Probably need some sort of cover device. :scream_cat:

:smiley:

1 Like
19

Heheh… Automation cannot function without electricity. :slight_smile:

'cause we don’t have robots yet that can do all the heavy lifting! That is, if robots have Home Assistant pre-installed. :slight_smile:

20

I finally figured it out.
It seems like that now you need a valid SSL certificate.
Previously a self issued certificate was enough. It might be worth to add this information to the docs.
Thanks for your help!