Fixed.
1 Like
Cool! Where can I find info about how to build it? Can I just compile the add-on code and package it into a jar? (If yes, how?)
Just install OH 2.4 milestone 1 or OH 2.5
The only place I can find a precompiled package to download is https://www.openhab.org/download/ and that version I already have installed. Also the build on https://ci.openhab.org/job/openHAB-Distribution/ is four days old.
The remaining alternative I see is to download the sources with git and try to compile it with maven, though it’s been about 8 years I used maven and Eclipse (and svn).
Openhab 2.5 Snapshot 1503 available now. Unfortunatelly rollershutters are still not found. There’s one change though: PaperUI got lost on the way… 
Have you checked all the steps mentioned in the troubleshoot section? Rollershutters are part of the exposable types now.
Description.xml seems ok, Rollershutters are also listed in the api’s debug output.
api debug:
Exposed lights: Rollladen Esszimmer Terrasse: Color Temperature Light on: false, brightness: 0, reachable: true Licht Wohnzimmer: Color Temperature Light on: false, brightness: 0, reachable: true Rollladen Wohnzimmer Ost: Color Temperature Light on: false, brightness: 0, reachable: true Rollladen Esszimmer S?d: Color Temperature Light on: false, brightness: 0, reachable: true Rolladenautomatik: On/Off plug-in unit on: true, reachable: true Rolladen Wohnzimmer Terasse Sued: Color Temperature Light on: false, brightness: 0, reachable: true
description.xml:
<?xml version="1.0" encoding="UTF-8" ?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <URLBase>http://192.168.4.70:80/</URLBase> <device> <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType> <friendlyName>openHAB Hue Emulation (192.168.4.70)</friendlyName> <manufacturer>Royal Philips Electronics</manufacturer> <manufacturerURL>http://www.openhab.org</manufacturerURL> <modelDescription>Philips hue compatible Personal Wireless Lighting</modelDescription> <modelName>Philips hue bridge 2015</modelName> <modelNumber>BSB002</modelNumber> <modelURL>http://www.meethue.com</modelURL> <serialNumber>5D643EC4256F</serialNumber> <UDN>uuid:5d643ec4-256f-4f48-b01f-2f103a115318</UDN> <presentationURL>index.html</presentationURL> <iconList> <icon> <mimetype>image/png</mimetype> <height>48</height> <width>48</width> <depth>24</depth> <url>hue_logo_0.png</url> </icon> <icon> <mimetype>image/png</mimetype> <height>120</height> <width>120</width> <depth>24</depth> <url>hue_logo_3.png</url> </icon> </iconList> </device> </root>
Yet Alexa does not find the devices (pairing enabled, tried with Alexa fix on and off, tried with port 80 and 8080 - forwarding from 80 to 8080 works).
I have two Tasmota-flashed Sonoff devices in the same subnet with their version of hue emulation enabled and they are found and can be controlled by Alexa. I also tried with the Tasmotas’ hue emulation disabled (read somewhere that more than one enabled bridge could mess up the pairing process) but still no candy… 
Did you try with different alexas and also the web-interface? Has tasmota recently updated its hue emulation support? Have you checked the log for devices that requested an API key? The Echoes should appear there while in pairing mode.
Tried it with an Echo and an Echo Dot (each 2nd gen), with the Android App and with the web interface. Each one once without “alexa fix” in the hue emulation config and once with it enabled. All searches resulted in no new found devices.
I honestly do not know. I use the rather old firmware v5.13.1 - never change a running system 
Doesn’t look like it. These are the last couple of lines in openhab.log:
2019-01-24 00:22:16.876 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:22:56.112 [INFO ] [eemulation.internal.ConfigManagement] - Hue Emulation pairing enabled for 600s at /api
2019-01-24 00:23:16.851 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:24:16.932 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:25:16.709 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:25:36.899 [INFO ] [eemulation.internal.ConfigManagement] - Hue Emulation pairing disabled. Service available under /api
2019-01-24 00:25:43.370 [INFO ] [eemulation.internal.ConfigManagement] - Hue Emulation pairing enabled for 600s at /api
2019-01-24 00:26:17.084 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:27:16.716 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:28:16.739 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:29:16.821 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:30:16.884 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:31:16.731 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:32:16.958 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:32:54.320 [WARN ] [nal.protocol.MilightV6SessionManager] - Session timeout!
2019-01-24 00:32:54.565 [INFO ] [nal.protocol.MilightV6SessionManager] - Confirmation received for unsend command. Sequence number: 0
2019-01-24 00:33:16.682 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:34:16.866 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:35:16.870 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
2019-01-24 00:35:43.388 [INFO ] [eemulation.internal.ConfigManagement] - Hue Emulation pairing disabled. Service available under /api
2019-01-24 00:36:16.896 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-action-mqtt'
While annoying, I do not think the mqtt install errors have anything to do with this problem.
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.
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.
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?
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)
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.
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.
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.
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
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
hi, i have the same problem. 2.4 and 2.5 Snapshot HUE Emulation doesnt work with Alexa.
Awesome