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

David_Graeff · January 24, 2019, 12:09am

You should tidy up your addons.cfg indeed.

There is one thing you can for me. Please use the same address like mentioned in the troubleshoot section but ending with /api/testuser/lights. I’m on a phone and can’t look up the correct address, testuser might be wrong.

However “lights” is the important part. That’s where Alexa will find the items. You should see a JSON response. Go to /api/testuser/config/whitelist to see all existing users.

Then enable pairing mode and use another name than testuser, and watch the logs if the new user is indeed added.

Alestrix · January 26, 2019, 11:22pm

Hi David,

here’s the prettyprinted json output of /api/testuser/lights:

{
	"1": {
		"state": {
			"bri": 0,
			"ct": 500,
			"on": false,
			"reachable": true,
			"mode": "homeautomation",
			"alert": "none"
		},
		"type": "Color Temperature Light",
		"modelid": "LTW001",
		"uniqueid": "5d643ec4-256f-4f48-b01f-2f103a115318-1",
		"manufacturername": "Philips",
		"swversion": "66012040",
		"friendsOfHue": true,
		"colorGamut": "2200K-6500K",
		"hascolor": false,
		"name": "Rollladen Esszimmer Terrasse",
		"config": {
			"archetype": "classicbulb",
			"function": "functional",
			"direction": "omnidirectional"
		},
		"capabilities": {
			"certified": true,
			"streaming": {
				"renderer": false,
				"proxy": false
			},
			"control": {}
		}
	},
	"2": {
		"state": {
			"bri": 0,
			"ct": 500,
			"on": false,
			"reachable": true,
			"mode": "homeautomation",
			"alert": "none"
		},
		"type": "Color Temperature Light",
		"modelid": "LTW001",
		"uniqueid": "5d643ec4-256f-4f48-b01f-2f103a115318-2",
		"manufacturername": "Philips",
		"swversion": "66012040",
		"friendsOfHue": true,
		"colorGamut": "2200K-6500K",
		"hascolor": false,
		"name": "Licht Wohnzimmer",
		"config": {
			"archetype": "classicbulb",
			"function": "functional",
			"direction": "omnidirectional"
		},
		"capabilities": {
			"certified": true,
			"streaming": {
				"renderer": false,
				"proxy": false
			},
			"control": {}
		}
	},
	"3": {
		"state": {
			"bri": 0,
			"ct": 500,
			"on": false,
			"reachable": true,
			"mode": "homeautomation",
			"alert": "none"
		},
		"type": "Color Temperature Light",
		"modelid": "LTW001",
		"uniqueid": "5d643ec4-256f-4f48-b01f-2f103a115318-3",
		"manufacturername": "Philips",
		"swversion": "66012040",
		"friendsOfHue": true,
		"colorGamut": "2200K-6500K",
		"hascolor": false,
		"name": "Rollladen Wohnzimmer Ost",
		"config": {
			"archetype": "classicbulb",
			"function": "functional",
			"direction": "omnidirectional"
		},
		"capabilities": {
			"certified": true,
			"streaming": {
				"renderer": false,
				"proxy": false
			},
			"control": {}
		}
	},
	"4": {
		"state": {
			"bri": 0,
			"ct": 500,
			"on": false,
			"reachable": true,
			"mode": "homeautomation",
			"alert": "none"
		},
		"type": "Color Temperature Light",
		"modelid": "LTW001",
		"uniqueid": "5d643ec4-256f-4f48-b01f-2f103a115318-4",
		"manufacturername": "Philips",
		"swversion": "66012040",
		"friendsOfHue": true,
		"colorGamut": "2200K-6500K",
		"hascolor": false,
		"name": "Rollladen Esszimmer S?d",
		"config": {
			"archetype": "classicbulb",
			"function": "functional",
			"direction": "omnidirectional"
		},
		"capabilities": {
			"certified": true,
			"streaming": {
				"renderer": false,
				"proxy": false
			},
			"control": {}
		}
	},
	"5": {
		"state": {
			"on": true,
			"reachable": true,
			"mode": "homeautomation",
			"alert": "none"
		},
		"type": "On/Off plug-in unit",
		"modelid": "Plug 01",
		"uniqueid": "5d643ec4-256f-4f48-b01f-2f103a115318-5",
		"manufacturername": "OSRAM",
		"productname": "On/Off plug",
		"swversion": "V1.04.12",
		"hascolor": false,
		"name": "Rolladenautomatik",
		"config": {
			"archetype": "classicbulb",
			"function": "functional",
			"direction": "omnidirectional"
		},
		"capabilities": {
			"certified": false,
			"streaming": {
				"renderer": false,
				"proxy": false
			},
			"control": {}
		}
	},
	"6": {
		"state": {
			"bri": 0,
			"ct": 500,
			"on": false,
			"reachable": true,
			"mode": "homeautomation",
			"alert": "none"
		},
		"type": "Color Temperature Light",
		"modelid": "LTW001",
		"uniqueid": "5d643ec4-256f-4f48-b01f-2f103a115318-6",
		"manufacturername": "Philips",
		"swversion": "66012040",
		"friendsOfHue": true,
		"colorGamut": "2200K-6500K",
		"hascolor": false,
		"name": "Rolladen Wohnzimmer Terasse Sued",
		"config": {
			"archetype": "classicbulb",
			"function": "functional",
			"direction": "omnidirectional"
		},
		"capabilities": {
			"certified": true,
			"streaming": {
				"renderer": false,
				"proxy": false
			},
			"control": {}
		}
	}

After enabling pairing (and echo device discovery fix in case that makes any difference) and opening the url
http://192.168.4.70/api/testuser2/config/whitelist
I see the new user “testuser2” is being added compared to just /api/testuser/config/whitelist:

{
...
	"testuser": {
		"name": "Formerly authorized device",
		"createDate": "2019-01-19T01:08:44.405",
		"lastUseDate": "2019-01-26T23:48:54.245"
	},
	"testuser2": {
		"name": "Formerly authorized device",
		"createDate": "2019-01-26T23:48:59.473",
		"lastUseDate": ""
	}
}

After a refresh, also the “lastUseDate” gets a value.
The other users (not shown here) are numerous echo entries (one with a timestamp a few minutes ago, probably from another device discovery attempt I just did) and my smartphone (twice).

Accessing http://192.168.4.70/api/testuser2/lights also shows the six devices. When disabling the Alexa Fix while keeping pairing mode enabled and accessing http://192.168.4.70/api/testuser3/lights I receive a “Not Authorized” JSON message.

All Echos in da house (one Echo and two Echo Dot) run version number 628568520.

For reference, here’s the description.xml from one of the two Tasmota devices. Just deleted them and they were rediscovered via the Alexa website without complaints:

<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.4.52:80/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Amazon-Echo-HA-Bridge (192.168.4.52)</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2012</modelName>
<modelNumber>929000226503</modelNumber>
<serialNumber>dc4f2237dcab</serialNumber>
<UDN>uuid:f6543a06-da50-11ba-8d8f-dc4f2237dcab</UDN>
</device>
</root>

You should tidy up your addons.cfg indeed.

Never touched it, everything was done through PaperUI. The weird state of mqtt action add-on probably happened due to OpenHAB version hopping. I enabled legacy plugins now to make MQTT Action Add-On show up (never had it enabled before) and clicked uninstall. Logs look better now.

PS: For reference, these are the discovery messages I see in tcpdump on my OpenHAB VM coming from the Echoes:

Echo

M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900
Man: "ssdp:discover"
MX: 3
ST: upnp:rootdevice

and

M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900
Man: "ssdp:discover"
MX: 3
ST: ssdp:all

Echo Dots

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 15
ST: urn:Belkin:device:**

and

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 15
ST: urn:schemas-upnp-org:device:basic:1

Port 1900 is owned by the OpenHAB Java process.

David_Graeff · January 26, 2019, 11:47pm

Tasmota is emulating a first gen bridge, that’s the only difference I can spot.

The description.xml and discovery itself works. Otherwise the echos would not appear in the whitelist.
But Amazon is apparently expecting something from a second bridge gen that we are currently not emulating correctly. It worked a few weeks ago for me, but who knows what they have changed in the meantime.

3rd party apps are working?

Alestrix · January 27, 2019, 1:12am

Just installed and tested two Android apps:

“Hue Hello” finds one of the Tasmota emulated hue bridges and can use it alright. The app would not let me manually add OpenHAB’s IP address (app limitation).

“Hue Essentials” occasionally finds one of the Tasmota emulated bridges, but cannot connect to it. It does not find the OpenHAB emulated one during automatic discovery. When manually adding OpenHAB’s IP address, the bridge is found and all devices are showing up. They cannot, however, be switched from the app (no reaction “in real live”).

ADDENDUM: Since that “no reaction” behavior made me suspicious I did some more checks and just now realized that the Homematic Binding, which close to all my things are bound to, somehow got borked on my upgrade Odyssey between OH 2.2 (OH 2.3?) where it worked nicely a few days ago - before I precipitantly entered apt-get upgrade - and OH 2.5 M1 that I am running now. Deleting and re-adding of the Homematic bridge does not help (“communication error”).
While I seriously doubt that this is directly related to Alexa not wanting to discover my devices (the “Rolladenautomatik” switch is not bound to Homematik and is also not found by Alexa) I believe that I should setup my whole OpenHAB install from scratch before doing any more tests. Who knows what else is broken on my setup. I hope to be able to do this within the next two to three weeks.

PS: This might also be noteworthy about when I did that tcpdump I wrote about above. I saw that

there was no answer from openhab to the multicast discovery request coming from the Echos
the Echos did not directly contact openhab’s IP (no retrieval of description.xml or anything else)

David_Graeff · January 27, 2019, 1:39am

The upnp library might be bound to the wrong network interface. That’s the only explanation I have atm. Personally I bind all of my network related bindings to all available interfaces but haven’t updated the upnp part for this service as far as I remember.

Alestrix · January 28, 2019, 10:54am

Listening on all interfaces:

# netstat -anup| grep -e 1900 -e 5353
udp6       0      0 :::5353                 :::*                                4532/java
udp6       0      0 :::5353                 :::*                                4532/java
udp6       0      0 :::1900                 :::*                                4532/java
udp6       0      0 :::1900                 :::*                                4532/java
udp6       0      0 :::1900                 :::*                                4532/java

In some other post I once saw a snippet from a netstat output where openhab specifically binds to the 239.255.255.250 multicast address, but AFAIK the ::: address implies not only all IPv6 but also all IPv4 addresses, including multicast.

Alestrix · January 29, 2019, 8:37am

Now this is embarrassing… as most of the times, the error was located between keyboard and chair

A new install from scratch, including OS, of OH2.4 did not solve the problem, neither did downgrading to 2.3 or 2.2. It turned out, when I tried it the first time (when it worked), I defined the iptables rewrite rules from CLI. Later I thought I was smart and did it via Webmin (for reboot-persistency). That caused the default policy to be changed from ACCEPT to DROP and while I had explicit accept rules for TCP ports 22, 80 and 8080, there was none for UDP port 1900, causing discovery of OpenHAB by Alexa to fail.

For reference, here are the ports I have opened now in hopes it might be useful for someone:

GUI: Ports tcp 80, 443, 8080, 8443
CLI/ssh: tcp 22
Language Server: tcp 5007
Discovery: udp 1900, 5353
Homematic Callback: tcp ports 9125-9130 (just 9125 is probably enough in most cases)
MQTT: tcp 1883
plus some more speciffic to my install

Hue Emulation works like a charm now, I can even change the color of my cheap MiLights from my Echoes without any Alexa Smart Home skills installed.

Seaside · April 1, 2019, 11:45am

For those who want to run openhab on port 80, I can recommend to not run it as root.

You can do this:

sudo crontab -e

add the following line

@reboot setcap CAP_NET_BIND_SERVICE=+eip /usr/lib/jvm/zulu-embedded-8-armhf/bin/java

This will allow java to run on port 80.

Regards, S

Seaside · April 1, 2019, 7:09pm

I can’t get the HUE Emulation binding to work in openhab 2.5.
I have had it running half a year ago or so.

Feels like something basic is missing,
I’m running on port 80. If I do:
wget http://myip/description.xml I get a 404 (where myip is ofc replace with a correct ipnr).
Running bundle:list shows:

openhab> bundle:list|grep -i hue
246 │ Active │  80 │ 2.5.0.201903310913    │ Hue Emulation Service
openhab>

openhab> http:list
ID  │ Servlet                │ Servlet-Name    │ State       │ Alias         │ Url
────┼────────────────────────┼─────────────────┼─────────────┼───────────────┼──────────────────
20  │ ServletContainerBridge │ ServletModel-6  │ Deployed    │ /rest         │ [/rest/*]
136 │ AudioServlet           │ ServletModel-2  │ Undeployed  │ /audio        │ [/audio/*]
136 │ AudioServlet           │ ServletModel-4  │ Deployed    │ /audio        │ [/audio/*]
139 │ IconForwarder          │ ServletModel-45 │ Deployed    │ /images       │ [/images/*]
188 │ AsyncProxyServlet      │ ServletModel-12 │ Deployed    │ /proxy        │ [/proxy/*]
188 │ ChartServlet           │ ServletModel-9  │ Deployed    │ /chart        │ [/chart/*]
189 │ IconServlet            │ ServletModel-15 │ Deployed    │ /icon         │ [/icon/*]
191 │ ResourceServlet        │ /start:web      │ Deployed    │ /start        │ [/start/*]
191 │ DashboardServlet       │ ServletModel-18 │ Deployed    │ /start/index  │ [/start/index/*]
211 │ AsyncServlet           │ ServletModel-22 │ Deployed    │ /upnpcallback │ [/upnpcallback/*]
237 │ RRD4jChartServlet      │ ServletModel-25 │ Deployed    │ /rrdchart.png │ [/rrdchart.png/*]
241 │ ResourceServlet        │ /basicui:web    │ Deployed    │ /basicui      │ [/basicui/*]
241 │ CmdServlet             │ ServletModel-28 │ Deployed    │ /basicui/CMD  │ [/basicui/CMD/*]
241 │ WebAppServlet          │ ServletModel-31 │ Deployed    │ /basicui/app  │ [/basicui/app/*]
243 │ ResourceServlet        │ /paperui:web    │ Deployed    │ /paperui      │ [/paperui/*]
244 │ ResourceServlet        │ /habmin:web     │ Deployed    │ /habmin       │ [/habmin/*]
245 │ ResourceServlet        │ /habpanel:web   │ Deployed    │ /habpanel     │ [/habpanel/*]

Anyone have it working in 2.5 ?

Regards S

Niclas_Pflug · May 26, 2019, 3:20pm

hi, i have the same problem. 2.4 and 2.5 Snapshot HUE Emulation doesnt work with Alexa.

NCO · December 7, 2019, 10:08am

Awesome

NCO · December 7, 2019, 10:12am

I just recongized that I do not discover any devices with the web (alexa.amazon.com), but after trying:
“Alexa, discover devices” all devices have been disovered.

NCO · December 7, 2019, 10:22am

Shouldn’t a rollershutter be another type?
I don’t see Information about how to expose rollershutters checking openHAB Hue Emulation - System Integrations | openHAB

David_Graeff · December 7, 2019, 10:25am

Ehm. You know Philips Hue do you? They have no ZigBee based rollershutters so their protocol also doesn’t support it so Alexa doesn’t support it, via The local Hue protocol at least.

Alestrix · December 7, 2019, 8:37pm

I emulate the rollershutters as dimmable lights and that’s what they show up as. You can then move the rollershutters all the way down by saying “set xyz to 99%”. When using 0% or 100% it’s going to be translated to OFF/ON somewhere along the way which causes my Homematics to not react at all. While this can probably be fixed with a rule I never bothered to. You should also be able to use Alexa routines to make “her” act on more natural sounding commands, like “move xyz up/down”.

NCO · December 9, 2019, 5:53am

Thanks.
I thought, that the 2.5 binding supports „real“ Rolleshutter items.
I will try it your way instead.

NCO · April 20, 2020, 6:04pm

I tried another round of getting Hue emulation to work (like months before).
I started with the official doc and set the iptables according to the docs (port 80).
After enabling the device pairing, all my items have been discovered.

When I open the descriptions.xml, I get:
grafik

…/api/status returns:

Reachability test

|URL|Responds?|Ours?|
| --- | --- | --- |
|http://192.168.68.28:8080/description.xml|no|no|
|http://192.168.68.28/description.xml|no|no|

When starting discovery:

2020-04-20 19:53:45.950 [INFO ] [io.hueemulation.internal.ConfigStore] - Using discovery ip 192.168.68.28
2020-04-20 19:53:45.955 [INFO ] [io.hueemulation.internal.ConfigStore] - Hue Emulation pairing enabled for 60s
2020-04-20 19:53:46.296 [DEBUG] [ueemulation.internal.upnp.UpnpServer] - Self test fail on http://192.168.68.28/description.xml: java.net.ConnectException: Connection refused (Conne$
2020-04-20 19:53:46.330 [DEBUG] [l.upnp.HueEmulationConfigWithRuntime] - Cannot restart thread

But I can discover all Switch items.
Unfortunately they do not respond to Alexa.
AND:
http://192.168.68.28:8080/api/testuser/lights
does not return any lights.

scottk · April 20, 2020, 9:33pm

It doesn’t seem the Hue Emulation binding is receiving your http requests. I suspect that may be because of your configuration. I use the following in /etc/rc.local (my OpenHAB server is running CentoOS 7):

/sbin/iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

I haven’t changed any of the “standard” ports used by OpenHAB, it still listens on TCP port 8080 for incoming http requests. As I noted above, I configure the Hue Emulation binding through the PaperUI:

Note that I set the Optional Discovery Web Port to 80.

I had some problems with the Hue Emulation binding a few months back, but now that I’m running a 2.5.x-SNAPSHOT, I haven’t experienced any problems. I have not been successful using the Switchable tag for my switch-only (non-dimmer) items.

NCO · April 21, 2020, 5:17am

Thanks, Scott.

I did not change any of the standard ports either and use the same routing stuff from the docs:
sudo iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
(sorry, I forgot to mention this).

Is that how it’s supposed to be? I would like to actually use just switched from hue emulation
(Coffee machine, Car Heater, Irrigation, …)

KidSquid · April 21, 2020, 5:57am

I was running into a very similar situation where I could not get Alexa to see any of my tagged devices. I had put off the port redirection as I had read both positive and negative reviews of implementing it. I can tell you that once I enabled the port redirection, deleted my items from alexa.amazon.com then put the binding in discovery mode, and finally I clicked on the big blue discover button on the alexa website…after discovery was complete…like magic Alexa was back controlling the house.