Yea I’ve tried to get HA bridge working for weeks now but no luck. I agree that Installing and setting up everything is really easy. However, there is a problem with HA bridge working with SSL certificates from LetsEncrypt. Every time I try to connect to HASS via HA bridge I get this error:
Error on calling url to change device state: https://xxxxx.dyndns.org/api/services/homeassistant/turn_on?api_password=xxxx
BWS is helping me diagnose my issue. It looks like I’ve got a path issue to my local SSL cert. I’m working through how to fix this. I’ll report back when I get it working.
Please do; this is why I didn’t bother setting up HA-Bridge. Now that I have Google Home in the mix I’d like to revisit it but I also use Let’s Encrypt.
You are right, I forgot about that - this was why I went back to running without a certificate. I started looking at an alternative to lets encypt but things got way past my understanding very quickly. I’ll have to wait for someone else to work this out.
I am on a Pi and tried to set it up last night, but got errors when trying to boot it. Looking at issues on the repo I found that it need Raspbian full, not Lite which I have, to work. Not sure what dependencies are missing.
I used the all in one installer, initially, but that was overkill as I’m not using a zwave stick or mqtt. So I’ll probably re-image Raspbian full and get HA-bridge running on it.
I’m running under the same setup - AIO and Raspbian Jessie full version. As far as I know the only dependency I needed was Java which is in the instructions from @jbardi linked above.
Are you using the BWS version - there’s two Ha-Bridge’s out there that I know of.
Do you have anything using port 80? That is the default port since version 3.2.
Also - did you start it? You will need to set it to launch on boot too. The instruction on the Git have a directory a bit wrong for where it installed on the Pi for me - see here for differences.
Thanks Klathmon, I’ll give it another go when my G.Home arrives. You wouldn’t believe how difficult it is to order something like this in Australia. After a couple of cancelled orders I ended up paying a shipping forwarder to buy it for me.
I felt pretty conflicted letting it go, it took me a fair bit of time to get it to work. I’d like to get the Flash Briefing skill going so might switch back if the SSL Certificate script for Java solution posted on git works for ihgates.
I had it working with the emulated_hue setup in HASS, but it seems to be semi-broken now.
For some reason it’s only showing a single switch out of my whole system (and annoyingly enough it’s the switch to the TV’s power…), but that one switch does work.
I can’t get it to find any other switches/lights, and after disconnecting the philips hue system from google home, it still shows up (but doesn’t work until i reconnect it), and I can’t seem to find a way to get rid of it (even tried resetting the google home).
I have checked the hue API and have confirmed that everything is showing up correctly there, but it just doesn’t want to cooperate.
So the Google Home will try to use the local network Hue API. No cloud needed. This is great news. The bad news is it’s going to require some work to get it functional.
Google Home isn’t happy with the SDP query answer delivered by emulated_hue’s and ignores it. This can be fixed by editing homeassistant/components/emulated_hue.py. In particular:
In particular it appears emulated_hue is missing the hue-bridgeid. Hat tip to the ha-bridge documentation for documenting their responses on this.
For Google Home emulated_hue MUST be listening on TCP port 80. So for now you’ll either have to run it as root (bad) or give python the capability to bind ports lower than 1024:
Another option to fix this would be to add an option to emulated_hue configuration so that you can make the upnp responder say port 80, but really have the TCP listener on a different port, then leverage something like nginx proxy pass.
So this gets the Home talking to emulated_hue and attempting to grab the lights list. And here I’m stopping for the night. It is doing the same thing as Alexa in that if there is something it doesn’t like about the format of the JSON response or the contents of a field it will reject everything and silently fail. In the case of the Google Home it keeps retrying over and over again long after the mobile website tells you pairing failed.
So basically we need to spend some time banging our heads at this. We need to compare our responses to real Hue API, try different values in different fields, etal until we can figure out what is making Home unhappy about the API responses.
Another version -> https://github.com/bwssytems/ha-bridge seems to have direct Emulated Hue support for Google Home in their latest version. According to their dev, if you update to the latest version and run on port 80, it works 100%. Looks like this library is running on Java so I’m not sure there is an easy way to migrate that into Home Assistant.
I had no idea there were so many variants of Emulated Hue bridge.
I was unaware that python can’t bind to lower ports. That’s a major issue that may prevent non-power users from utilizing Home Assistant on a Google Home for now.
I’ve been reading a lot of the hype for the Google Assistant API coming out in December. Depending on the complexity of the fix for the Emulated Hue component, it might be easier to wait until December for the Google Assistant API. It’d be silly to write a whole new emulated hue bridge only to be deprecated in a month.
I have a strong feeling that the Assistant API will enable some very robust options for HA including a new notification platform, integration with the Google Home, and maybe even a fully self-standing Google Assistant platform. It’s not clear if Google will create a Python binding for it out of the box so there may be a significant amount of work required to make it play well with HA.
I’m tagging at @balloob because we had talked briefly via Twitter and wanted to give him an update. I’d love to know what everyone thinks the best steps forward are. I’m loving the Home so far!
I have Home Assistant, Google Home and HA Bridge (version 3.2.1) from bwssytems working good and no issue.
Only thing I would like to improve if possible is when I ask Google Home status of my lights it will be correct for only those light I controlled using Google Home. If I had it turned on/off using Home Assistant Google Home will not have the correct status. The reason I see is when I have configured my light in HA Bridge used POST restful call using service like
URL for on:
http://localhost:8123/api/services/switch/turn_on?api_password=xxxxxx
URL for off:
http://localhost:8123/api/services/switch/turn_off?api_password=xxxxxx
Data:
{"entity_id":"switch.kitchen_light"}
So Google Home have no way to poll the status using that URL, if I use configuration shown below then control doesn’t work as Home Assistant just changes the status of light in Home Assistant but will never send command to the device so next poll that status will over-written.
I’m really hopeful for Actions on Google. The small amount of information that has been given so far is very encouraging! I’m loving my Home as well, so far.
