still not working for me…
Replacing the original file with this version fixed my problems with emulated hue. I hope this fix will find it’s way into the official repository soon.
THANKS!!!
Works like a charm. But Alexa still say “out of range” if I try to switch my self-made ZigBee On/Off lights (see pic) on. But it works. How can I fix it?
"11": {
"etag": "ee8f180822e81afc030e5e72d7e24d7b",
"hascolor": false,
"manufacturername": "HCO",
"modelid": "ZLL-OnOffLight",
"name": "Esszimmer Lampe",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": "1000-0003",
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:9a:1b:3e-01"
},
https://ottelo.jimdo.com/philips-hue-osram-lightify/ (via IC JN5168)
Did you remove the “old” devices one by one in the Alexa app before searching again? “Remove all” doesn’t seem to work correctly.
I removed the device from the alexa app, then rediscovered. It started working again, -ish. A few devices still claim something was out of range or there was a problem, yet they still work.
The emulated_hue is so badly written and hacked together that I’m just going to switch to the hue emulation in deconz for my zigbee devices. Which, btw, works 100% flawlessly.
@cexshun
What did you mean you switch to the hue emulation in deconz?
@mamoel
Yes, I removed each device one by one via app. The problem with my self-made zigbee bulbs is not soo big. But I have another strange problem. I’ve 3 Philips bulbs grouped together via light group method to “light.sofa”:
light:
- platform: group
name: Sofa
entities:
- light.sofa_lampe_1
- light.sofa_lampe_2
- light.sofa_lampe_3
In my emulated_hue.yaml:
host_ip: 192.168.178.10
listen_port: 80
off_maps_to_on_domains:
- script
- scene
expose_by_default: false
exposed_domains:
- light
- group
- switch
entities:
.......
light.sofa:
name: "Sofa"
hidden: false
.......
And when I say “Alexa Sofa Brightness 50%”, Alexa say: You have more than one device with that name… When I remove “Sofa” via Alexa App, Alexa say: no device with name Sofa. Whats wrong? Simply “Alexa switch Sofa on” or “off” works!
I am removing all zigbee devices from HA emulated hue. Then instead using deconz hue component to have Alexa interact with zigbee devices. Zwave devices will unfortunately remain on the HA hue component.
After trying ALL the different free options out there for Amazon integration, HA-Bridge seems to be the best. This is the only option where Alexa doesn’t respond with some strange error message. Documentation for HA-Bridge is somewhat lacking but it isn’t too difficult to figure out and I REALLY like that everything stays local with no need to punch holes in my firewall. I got it working with dimmers, switches, and even scripts.
Directly integrating with HA was problematic but MQTT and executing a little bash script to call HA via REST API works fine.
I read about the option to use HA bridge the first time.
Could someone sum up the differences, pro‘s and con‘s of HA Bridge, haaska and Alexa smart home skill?
@tjedmunds:
Terry, would you mind to share in more detail how you did the integration with HA? It seems there are scripts required to do that. Any other things to be aware when following the HA-Bridge installation instructions?
Thanks
Per request, here is what I learned about HA Bridge to get it working.
I downloaded the jar and installed Java on my Debian server following the instruction on their main github page. The docker image didn’t start successfully and I eventually gave up trying to figure out why.
Next I configured MQTT on the Bridge Control tab with my IP and port of MQTT. Most of my lights are connected to HA via MQTT so I figured that would be the fastest way to get the lights to respond since HA would just be another hop before HA sent the MQTT message. Also, the Home Assistant integration in HA Bridge always throws a null exception after configuring the IP and port. I opened an issue for that and again have abandoned that for now.
To configure a light I added them as follows:
Name =
Device Type = switch
Map Type = MQTT
On Items: Type = MQTT Message. Target Item =
Off Items: same as On Items but changed payload from ON to OFF
Dim Items: only add if switch is dimable, and used the “intensity.percent” in the payload, for example:
{"clientId":"ha-bridge","topic":"smartthings/Lamp One/level/cmd","message":"${intensity.percent}","qos":"1","retain":"false"}
An example MQTT JSON to turn one of my devices on:
{"clientId":"ha-bridge","topic":"cmnd/GarageLight/POWER","message":"ON","qos":"1","retain":"false"}
I also have several HA scripts that control my Home Theater, stereo receiver, TV, and Shield. To run those via Alexa I call a bash script from HA-Bridge which sends the request to HA (since HA integration is not functional for now). For example,
On Items: Type = Execute Command Target Item = ha-run-script home_theater_on
The bash script looks like this:
#!/bin/bash
# Usage: ha-run-script {script}
curl --silent -X POST \
-H "Authorization: Bearer <insert a long-lived token here> " \
-H "Content-Type: application/json" \
-d "{\"entity_id\": \"script.${1}\" }" \
http://<insert HA IP here>:8123/api/services/script/turn_on
I am also migrating to a more generic bash script called ha-run-service that can run ANY HA service and not just start a script:
#!/bin/bash
if (( $# != 3 )); then
echo Usage: ha-run-service {domain} {service} {entity}
exit 1
fi
curl --silent --request POST \
--header "Authorization: Bearer <insert a long-lived token here> " \
--header "Content-Type: application/json" \
--data "{\"entity_id\": \"${3}\" }" \
http://<insert HA IP here>:8123/api/services/${1}/${2} >>/dev/null
I set the walled garden config per the doc to limit what scripts HA-Bridge can run and from what directory (recommended).
Judging by what’s written here, this appears it will not work if you have HassOS running HassIO.
I happen to run HassIO from docker, but HA-Bridge needs to be on port 80 or at least do the proxy or firewall trick to route the /api/ requests from 80 to whatever port you are using. I have apache on port 80 and proxy to HA-Bridge. If you are using the Raspberry Pi HassIO then unless someone figures out a way to set up this bridge on port 80 as an addon I think a 2nd Pi would be needed. Also, it still might be possible to fix emulated hue. It would be useful to compare the api responses between emulated hue and HA-Bridge as obviously there is some difference which confuses Alexa. It’s not just the port 80 issue.
Yep, so my suspicions are correct.
I don’t think users with HassOS can even install HA-Bridge let alone get around this issue. HassOS is very limited. I believe someone would need to build a docker container with HA-Bridge as a HassIO add-on before we even look into the port 80 issue.
EDIT: And for those reading. HassOS does not mean HassIO. HassOS is the operating system that manages HassIO. There are multiple ways to install HassIO: Through Docker on Any OS, or the Image that contains HassOS and HassIO. If you’re a beginner, you most likely installed HassOS and HassIO.
True, but this would’t be the first addon that just isn’t available to HassIO users. See lircd.
Has anybody tried this HA-Bridge add-on from NotoriousBDG?
https://community.home-assistant.io/t/request-ha-bridge-ha-bridge-addon-for-hass-io/26254/2
Any suggestions for this issue for now? Or only cloud or haska?
I copied the updated hue_api.py that was posted in this thread, but I still had the problem of alexa complaining after I changed the brightness. Turning lights on/off worked without problems though.
I then set up haaska. It was a lot of work, but this works pretty well.
Has there been any word recently from amazon if this is going to be fixed?
I sent an email to amazon telling them that an update broke things because it no longer scans port 8300. Maybe if they are nagged enough someone might eventually escalate it to their software team and revert that update that broke hue compatibility.
I doubt anything will change. I suggest preparing for the worse.