Why can't emulated Hue work with OnHub or Google Home?

@iantrich I am using the Maker channel and it is working very well! Here is how I am triggering my bedtime scene:

URL = https://my-url.org/api/services/scene/turn_on?api_password=XXXXXXX
Method = Post
Content Type = application/json
Body = {“entity_id”: “scene.bed_time”}

The guy in the video is using https://github.com/bwssytems/ha-bridge. Which is awesome and there is tons of material on how to get it working with Home Assistant. It will take out the IFTTT step in my current setup and hopefully speed up response time.

1 Like

Excellent! Looks like I’ll be ordering a home now - already using Ha-Bridge for Alexa.

1 Like

@BarryHampants Do you find Ha-Bridge to be more responsive than the emulated Hue bridge in HA? Trying to decide if I should go to the trouble of setting up ha-bridge or just wait till we get Google Home to be supported in HA.

Ha bridge is quite easy to set up. Emulated Hue never really worked for me, almost always fails on boot 19/20 for me and hasn’t worked once since I got my dots. I have a shell_command permissions error within my install though so may be nothing to do with Emulated Hue. Will try a fresh install when I have time.

The great thing about Ha Bridge is being able to rename actions when I find Alexa has some sort of conflict with my naming scheme, and only adding stuff I want to add. You can run both so give it a shot.

Here you go.

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

@ih8gates has had an issue open on this for about a month now with no luck. I hope it get resolved soon :confused:
Issue link: Trouble connecting to server using LetsEncrypt SSL certificate

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.

2 Likes

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.

Thanks!

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.

I am using BWS. Here is my exact problem:

https://github.com/bwssytems/ha-bridge/issues/220

Not an option for me - I like my Alexa integrations.

Just wanted to chime in. The Emulated Hue Bridge in home assistant DOES work with Google Home just fine.

you need to set the listen_port to 80, but once you do that it works great!

1 Like

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.

Just tried that, no luck. Do you have it working with the built in emulated hue inside of HASS or the one that HA Bridge has?

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.

1 Like

Spent a couple hours fighting with a Google Home.

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:

    resp_template = """HTTP/1.1 200 OK                                                                                               
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=60
EXT:                                                                                                                                           
LOCATION: http://{0}:{1}/description.xml                                                                                                        
SERVER: FreeRTOS/6.0.5, UPnP/1.0, IpBridge/0.1                                                                                                  
hue-bridgeid: 001E06FFFE123456                                                                                                                  
ST: urn:schemas-upnp-org:device:basic:1                                                                                                         
USN: uuid:Socket-1_0-221438K0100073::urn:schemas-upnp-org:device:basic:1                                                                                                                                                                                                                        """        

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:

 setcap 'cap_net_bind_service=+ep' /opt/home-assistant/ha-py3env/bin/python3

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.

5 Likes

This is super solid. I can confirm a lot of this as I spent a good amount of time last night trying to figure out the same problem.

Some things I’ll add -> HA uses this version of Emulated Hue https://github.com/blocke/ha-local-echo

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!

Cheers!

2 Likes