Emulated Hue suddenly stopped working with Echo Dot V2

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.

I have an idea but it’s a longshot.

I’ve seen a few posts on github a few months ago when this happened in relation to the Tasmota firmware’s Hue emulation where some had similar problems. This appears to have been fixed in subsequent master releases. I, like I presume many have with Sonoff Tasmota devices, have had to switch to their emulation since we lost the ability to do it all through HA. As it happens, it works perfectly well. But I miss scripts, badly.

So my idea is, could the answer lie buried somewhere in Theo Arends code?? I appreciate the HA version must be considerably more complex when dealing with so many different devices and scripts but maybe it’s a good starting point?

Just my 2 pence worth (I’m not a programmer lol).

I don’t think so. They may discard all changes in favor of Nabucasa/Home assistant cloud.

A PR to fix the Emulated Hue component has been approved and merged into 0.103.0 due next week by the looks of it.

PR is HERE.

3 Likes

Is that your handiwork? It’s nice to see that component get some love. Now if there was a way to have that component give HA user access to port 80, hassio users wouldn’t be left in the dust. I’m not sure the main dev’s would allow that though.

No, not me, I’ve just been keeping an eye on it.

It’s taken a while because the component has had many changes made to bring it more into line with native Hue configuration I believe.

What’s funny is the guy has kangaroo in the name… One can only assume.

He must be a good bloke :wink:

Did someone already try if emulated hue works again with 0.103.

Haaska works but it’s really slow for me. Takes 2-4 seconds to turn on a light.
Would really hope that it works local again.

Btw if it works again maybe someone can answer if the 2.gen echo dot is necessary for this or it’s also possible with 3. gen now.

Yes, it’s a bit slower than it was, and a little buggy which is a big improvement over it not working at all. Also, I’m running HA in a venv on the Pi3b+, which possibly could have another influence on these results.

I’ve only tested it on scripts so far on my Echo Dot v2. Out of 4 scripts, Alexa said the devices had a malfunction yet they worked anyway. The forth was a script that called the Alexa Media custom component for verbal feedback on some sensors - that didn’t work when I asked her. However, it did when I manually pressed it in the Alexa app.

I also noticed in the app that the device would momentarily say there was a malfunction when going into it, or until turned on or off. Maybe it’s some kind of delay in reporting statefullness or something.

But hey, I’m just so glad it’s back. Nice one :clap:

Well I’m not sure, but I think it worked like this (say there was malfunction) before when you set the port to 80.

You are right but I’d wish to have it as fast as before.
Could someone who already tested this confirm that we still need the seconds gen echo. I ask because maybe the new code works with current models too?