Alexa does not find Hue Emulation Items (despite having OpenHab running on Port 80)

Tags: #<Tag:0x00007fc1fd4d7af8> #<Tag:0x00007fc1fd4d7a30> #<Tag:0x00007fc1fd4d7940>

Hello Community.

My Problem in short:
I am using OpenHAB 2.3 running on Debian GNU/Linux 9.5 (stretch). I am using OpenHab in combination with the Hue-Emulation because i want to control my KNX installation with an Amazon Echo Dot and Amazon Echo both 2nd gen. The Echo devices do not find the Hue emulated items.

I have never wrote a post in such a forum so i am sorry if something is not formatted the right way. I try to fix it.
I do not want to use the OpenHab Cloud connector.

I already read at least 5 forum posts regarding this topic and this is what i already tried:

  • I checked if the Hue Emulation binding offers the Items to the network. I did this with:
    http://ip-of-OH-server:8080/api/testuser/lights?debug=true
    It shows me my Hue Emulated items… this works.

  • I found out, that the Echo devices are using Port 80 to discover Hue Bridges/Hue Emulated Items.

My first solution was to edit the iptables of my pc, i did this with:

iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Then i set the “optional discovery web port” of the Hue Emulatin settings to “80”.

Then i saved everything and Alexa was able to find the Hue Emulated items, but it stopped working after one day so deleted everything regarding iptables.

Then i tried to change the OpenHab Port from 8080 to 80 in which i already succeeded. The OpenHab log-file : “tail -f var/log/openhab2/openhab.log” shows:

…started Dashboard at http:///ip-of-OH-server:80

Confirmed this further with

“sudo netstat -atn | grep 80”

and it showed me fitting results.
To compare with:

“sudo netstat -atn | grep 8080”
gave no output/results.

Then i let Alexa search for new devices… nothing found…

Then i did the following:

In the File “/etc/default/openhab2” i changed

“#OPENHAB_USER=openhab”
“#OPENHAB_GROUP=openhab”

to

“#OPENHAB_USER=root”
“#OPENHAB_GROUP=root”

I kept the “#”, don’t know if this is relevant.

In the same file i changed

“#OPENHAB_HTTP_PORT=8080” to
“#OPENHAB_HTTP_PORT=80”

Then i executed
systemctl daemon-realod and
systemctl restart openhab2 and
systemctl restart openhab2.service

(is there a difference between the last two commands?)

After that Alexa did not found new Devices…
Then…

I went to “/usr/share/openhab2/runtime/bin/” and edited the file “setenv” and changed:

if( ! -z $(OPENHAB_HTTP_PORT ); then
HTTP_PORT=$(OPENHAB_HTTP_PORT)
else
HTTP_PORT=8080
fi

to

if( ! -z $(OPENHAB_HTTP_PORT ); then
HTTP_PORT=$(OPENHAB_HTTP_PORT)
else
HTTP_PORT=80
fi

Then i executed
systemctl daemon-realod and
systemctl restart openhab2 and
systemctl restart openhab2.service

I hope i didn’t forgot anything… I have worked the last 10h over 2 days on that and maybe i am missing something obvious.
With this Post i summed up at least 5 different related posts which i have read.

Thanks

EDIT:
I dont think that there is another service running on port 8080, its a PC only for OH

The hue emulation got a big update for 2.4, you may want to upgrade to the new release as soon as its out.
The level of emulation increased by a lot and is more like a real hue bridge (2nd square edition).

Cheers, David

Thank you for your answer.

Im working in a group project and i dont think if we want to update. Im going to ask my colleagues.
In the meantime it would be nice if someone/you has an answer because maybe we cant wait for the new release…

Matthias

The problem is: The 2.3 hue emulation emulates a 1st edition hue bridge, and not very accurate, and with the upnp /description.xml on the wrong http path.

If Amazon Echos got more picky about what they consider a hue bridge and maybe even only support the newer bridges, you are out of luck. The old hue emulation will not work anymore.

Ok, then i am going to try a RaspberryPi with the openhab 2.4m5

Edit: But why does it work, when i activate portforwarding via iptables with OH running on Port 8080?

Check http://your-openhab-ip:80/api/description.xml with your browser. Look for the different urls in there if they match with your openhab installation. This is what Alexa initially uses for discovering bridges.

A few hours ago Alexa found the devices, but now after another search they are gone… I changed nothing…

There is only one line with a IP Adresses:

http://oh-ip:80/
and
http://www.meethue.com
index.html

You should know that each Amazon echo variant has a different firmware. Depending on which echo performs the search you will either find devices or not depending on how strict the implementation is. If you perform a search via the Webinterface you will have again different results.

Thank you, thats is the problem.

I have multiple Echo Devices, two of them are a Sonos One with integrated Alexa and the other is an Echo Dot 2 Gen. The Sonos has a newer Software version than the Echo Dot and when i tell my Dot to discover devices everything works fine. When i tell the Sonos or search via the webinterface the items are found sometimes found and sometimes not…

I did this test today with OH still running on Port 80.
I do this for a university project and we do not want snapshots or unstable versions of OH.

so i have to take a break until monday

I’ve been using hue emulation with alexa for ages without any problems. It recently stopped working (when I installed 2.4-M7, I think), saying that the triggered openhab switch isn’t responding.

I was hoping it would get fixed in later milestones, but it doesn’t seem to be. Does anyone know if there’s a problem still to be fixed, or if anything of the set-up has changed?

It was rewritten during the milestones M5 to M8 and works now. But requires the alexas to re-authenticate. The 2.4 hue emulation documentation guides you through everything.

Thanks.

After clearing down all the previously detected devices in the alexa app and running discovery again, it’s found the one item I have with a [ “Lighting” ] tag, but none of the items with a [ “Switchable” ] tag.

So it’s working, but with only one of the types. Any ideas for the fix to get [ “Switchable” ] working?

Neil, are you by any chance from the US? Cause there is an open issue that the rewritten hue emulation does not work for Switchables for the US version of Amazon echos. The reason is, it emulates Osram wall plugs, and those were never sold in the US.

As a workaround go to the service configuration in paper UI and add Switchable to the white light bulb tags. Your switches are then emulated as dimmable lights.

No, I’m not in the US, I’m in the UK. BTW, I should also point out that I’m running alexa on port 8080 (different to this thread title); I posted here because it seemed a similar issue.

FYI: I don’t have any Osram-branded products, but I do have some Belkin Wemo bulbs and plugs (I have a feeling the bulbs are the same as the Osram ones?), and the Alexa detects the wemos plugs independently of openhab.

Making that change has got the 'Switchable" items things working again, thanks.

(oddly, if there’s a space between the comma after ‘Lighting’ and before ‘Switchable’ the items work but alexa says they don’t).

does someone know why Colorlighting tags not gets detected?

Does this mean that I now have to select the Hue V2 Bridge in the Alexa app which requires me to setup an account with Philips? And a Lightify account (needed for the Osram Skill) for Switchable Items?
Because when selecting V1 in the Alexa App, nothing is discovered anymore while it worked great before I updated to OH 2.4 (from repository using apt-get upgrade).
I have the iptables redirect 80->8080 configured and working, Alexa Fix enabled in the Hue Emulation Config, Pairing enabled, Tags set again (they got lost during upgrade since I only had set them via Swagger/REST API), but still nothing. Stupid me didn’t make a snapshot before upgrading :frowning:.

Alex

UPDATE: For some unknown reason the Alexa-App-triggered discovery now found the one Switchable Item in my setup but it is only identified as type “Sonstiges” (“other”) and can not be switched via the App, only some Info can be displayed. All “Lighting” items are still gone. So it’s the opposite behavior of what is reported by @DSTM.

UPDATE2: The old version of the Hue emulation took my rollershutters as dimmable items and thus published them to Alexa (as they have the “Lighting” tag). Could it be that this behavior has changed with the new Hue Emulation? Because /api/testuser/lights?debug=true does not list the rollershutters.

Yes. Rollershutters are not exposed at all. I simply forgot to allow them as well, next to dimmer, switch and group items. I think there is a fix in OH 2.5 snapshot already.

Thanks for the quick reply!
I updated to latest unstable which automatically restarted the openhab service. However, rollershutters are still not discovered and the “Switchable” tagged Item (the #PRESS_SHORT Switch Item of a HomeMatic Virtual Button) is discovered as type “Sonstige”.
Is there anything on top I need to consider?

Info: The installed package is openhab2_2.5.0~S1502-1_all.deb using the openhab repository.

as it’s an easy mistake to make, check in your Hue Emulation config that you don’t have a space after the comma that separates the trigger words. It should be exactly like this: Lighting,Switchable

Hi DSTM,
Thanks for the hint, but this is not the error in my case. Everything is currently setup through PaperUI for easier testing. I added the tags through the REST API and only have at most one tag per item.
Apparently it’s an error in the hue emulation implementation in the OH 2.4 release when it comes to rollershuttters.