For now I’m using Hue emulation on port 80 for switches and the Openhab Alexa skill for dimmers (and other percentage-controlled devices) and Thermostats. I can live with that for now.
There’s an ongoing discussion about the issue on the Home-Assistant forum.
They’re as frustrated as us. Currently their workaround is to switch port 80 (as suggested by @matthy in this forum), but with some lost functionality. This helps because Amazon’s latest firmware update now uses port 80 for discovery.
It seems that there is nothing that can be done to the Hue emulation binding to fix this since discovery is done by the Echo devices.
BTW, a couple Home Assistant users contacted Amazon and reported the issue. But I doubt two complaints are enough to encourage them to look into it. But I never say never.
Can someone clarify the switch to port 80? Hue emulation always ran on 80… openHAB runs by default on 8080 and then you install nginx or port forward to 80 for hue emulation.
Sorry for the confusion in my last post. We need to redirect port 80 to port 8080. See Matthy’s iptables solution posted earlier.
FWIW, it’s a solution with side affects. I applied the port 80 redirect workaround and everytime I voice command something to turn on, Alexa says “That value is out of range for device [device name].” Fortunately the command is successful. Hopefully a permanent fix is found that restores full operation that prevents this issue.
I have posted about this issue on GitHub, where most of the developers spend their time. Please feel free to update the issue with any more information.
Thanks for reporting it on github. We definitely need their help to update the binding so it is compatible with the latest amazon API. Hearing Alexa’s “That value is out of range for device” is a PIA.
FWIW, some of my rules were broken with the new Alexa API. I found that saying an Alexa command such as Turn On [device] still set the command value to 100, but the state value is set to 99. Actually, for a moment the state is 100, but is quickly changed to 99 for some mysterious reason.
I had rules based on states that were expected to be 100. They were edited to be >=99 and the broken rules were fixed. This does not prevent Alexa’s “That value is out of range for device” response, but at least the rules work again.
I think the problem with the hue-item values that are off by one has already been fixed since 2.5-builds of the hue emulation. I’m using an early 2.5-build of the hue emulation addon with Openhab 2.4-stable to avoid that effect.
That’s unexpected to hear that the ItemState value issue was identified long ago and fixed in 2.5. I’m on openHAB 2.4.0~20181104134837-1 (Build #1412) with the default (built-in) Hue Emulation binding. The existing ItemState value rules worked until the latest Amazon API. Changing the ItemState rule thresholds to use 99 instead of 100 fixed the rules that were affected. Rules that used the Command 100 value did not need any changes.
Regardless, it sounds like I should upgrade the Hue Emulation binding to the latest version. But I’ll wait awhile since fingers are crossed that a kindhearted developer will patch it for the new Amazon API.
I couldn’t find the “2.5” Hue Emulation jar file on the Github repository. So I could use some advice on where/how to upgrade of the revised Hue binding on my trusty OH 2.4 installation.
found this thread realizing a few other people having issues with hue emulation. As described here (Error while loading components of bundle org.openhab.io.hueemulation) some minutes ago the hue emulation bundle does not seem to even start in the very current snapshot build?
I’ve resolved my Hue Emulation issues. My configuration is OH2 2.4 Build 1412 with manually installed hueemulation 2.5.0 (snapshot). In case it helps anyone, here’s some tips.
Use Matthy’s suggested port redirect sudo iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-ports 8080
// EDIT 10-03-2019:
The revised iptables redirect will be lost at reboot. Fortunately there are a few different ways to automate the iptable redirect at boot. I decided to edit rc.local and do it there. Here’s the steps I used:
A. Save the revised iptables to a file using this command: sudo sh -c "iptables-save > /etc/iptables.rules"
B. Launch the editor and load the rc.local file: sudo nano /etc/rc.local
C. Near the end of the file, before the exit, add this line: sudo iptables-restore < /etc/iptables.rules
D. Save the file, exit.
E. Reboot and confirm that the iptable redirect has been automatically loaded.
// End of edit.
Use PaperUI’s default tags (Switchable, Lighting, ColorLighting). Ensure Optional discovery web port is set to 80. Set Pairing Timeout to 90 seconds.
I found it necessary to have Amazon “forget” all known devices and then rediscover them. I achieved best device discovery using the latest Firefox on my Win10 system. So if you have poor success with the Android Amazon app or with discovery via your echos, then use Win10 Firefox and go to https://alexa.amazon.com. Keep in mind that the discovery timer shown in the browser ends much sooner than the actual discovery access time. Always wait another minute (or wait until the echo dot lights stop their circle blink) before doing a browser refresh to see any newly populated devices.
The hue emulation binding added a clever feature (see the github 4339 pull request) that forces a item reload whenever a tag is changed. This is the magic sauce I needed to restore fussy items that refused to be discovered. The workaround is to change the item’s [Lighting] or [Switchable] tags to [ColorLighting], then do a discovery. This should allow discovery to occur. Then go back and restore the original tags and perform another discovery to correct the tags. When a device refuses to be discovered, this little trick works every time for me.
I could not get Number items to be discovered. My workaround was to change them to dimmer items. For example, I changed this Number item: Number Echo_Test "Echo Test [%d]" <light> (Echo_Test) ["Switchable"]
to this: Dimmer Echo_Test "Echo Test [%d]" <light> (Echo_Test) ["Lighting"]
That’s a summary of several days of hair pulling. The good news is that I no longer hear the “That value is out of range for device [device name]” whenever I tell Alexa a command. My only unresolved issue is with group items; They work, but Alexa responds with “Sorry, [device name] appears to be malfunctioning.”
Overall I’d say it’s not as good as the old configuration. But it is working well enough that I’m satisfied with the outcome.
Do you have a reverse proxy running in addition to this below?
I ask because I run reverse proxy to get my hue emulation on port 80. I was under the impression that port 80 was required as amazon only send/looks on port 80.
I have the same problems. Yesterday I update fom openhab 2.3 to 2.4. But I can’t install the hueemulation 2.5.0 (snapshot).
2019-10-03 09:38:55.698 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.io.hueemulation-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.io.hueemulation [255]
Unresolved requirement: Import-Package: org.openhab.core.automation
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
Where can I find the 2.5 snapshot .jar for Hue Emulation (or any other add-on, for that matter)?
I’m running a webserver on port 80 on my OpenHAB box. It sounds like there is still no resolution for making Alexa discovery work? Mine was working using HA-Bridge until about 3 weeks ago. I wasn’t aware that there was a Hue Emulation add-on until after my problems started, but I plan to switch to that once it starts working again.
