I am running openHAB 3.4.0.M2 and have Hue Emulation which exposes few items to Alexa.
My problem is that all items/devices (tagged correctly) with an “uniqueid” (which is generated automatically) ending with a number greater than FF are not found by Alexa. The other ones work perfectly. I was wondering if this could be a bug.
Thanks for any suggestions.
1 Like
Also experiencing this issue, running [hueemulation] with OpenHAB v3.3.0. Out of my 42 exposed lights, only 30 items with unique IDs that end with a value under ‘-FF’, or numeric unique IDs of 1-99, are discovered by Alexa. Per my research, this isn’t really a bug but rather a change to how Alexa handles discovery. There were other breaking changes in the past, such as needing 9 Octets in the Bridge ID, reference this related GitHub Issue (habridge):
Digging into the Openhab Hue Emulation code, I believe this function is the culprit of the problem. This ‘unique’ variable should be a sequence of only 2 characters, and as you noticed only use letters A-F when generating the unique ID.
To work around this, I attempted but failed to find where these values are stored. In habridge, there is a device.db file that can be directly edited, but in Openhab it seems these values are stored in JSON DB, and would require some openhab-cli console fun to find and change…
To confirm its not so much of a problem with hueemulation addon, but rather Alexa Device Discovery, I downloaded ‘Hue Essentials’ from Google Play, which finds and controls ALL of my Openhab exposed items correctly.
Any ideas on how to work around this?
1 Like
The Hue Emulation probably isn’t strictly following the Hue API and Alexa seems very sensitive to that whereas other implementations are more lenient in what they accept for the unique id.
The Hue documentation states:
Unique id of the device. The MAC address of the device with a unique endpoint id in the form: AA:BB:CC:DD:EE:FF:00:11-XX
So in the above example we can probably use “00:11-XX” to hold the id of the light rather than just the “XX” which is used now.
This is likely to need a code change to fix. Something along the lines of getHueIDPrefixFromUUID returning 17 characters from the UUID, e.g. “AA:BB:CC:DD:EE:FF” and getHueUniqueId using the 6 available characters to store the the hue id in the format of “00:11-XX”.
2 Likes
As I understand it, you could theoretically use HueEmulation with Alexa with FF (255) items, but with the XX part randomly generated by the item, which with many delete and create actions goes beyond the 255 ID limit very quickly, the use effective is very limited. As suggested, the code should be changed.
1 Like
Thanks for all of your inputs here!
If any of you Java programers are willing to take a swing at this and compile a JAR for hueemulation, I’m more than willing to help beta test and get this resolved for everyone!
Can someone please try this 3.4.0 version to see if it resolves the problem:
2 Likes
I got the following fatal error:
2022-12-06 15:06:17.568 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.io.hueemulation-3.4.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.io.hueemulation [297]
Unresolved requirement: Import-Package: org.jupnp …
Are you running OH 3.4? I suspect all the dependencies have moved on such that it won’t work on earlier versions.
Yes, I run the OH 3.4.0.M3 stable version in a standard Linux OS (Debian).
My test:
- Before I removed the bundle Hue Emulation from GUI “Other Add-ons” then I put the org.openhab.io.hueemulation-3.4.0-SNAPSHOT.jar in /usr/share/openhab/addons
Restart OpenHab app. Nothing happens. - I reinstalled the bundle Hue Emulation from GUI “Other Add-ons”
Restart OpenHab app but the error persists.
I removed org.openhab.io.hueemulation-3.4.0-SNAPSHOT.jar and all it’s fine with the bundle version (and its limits!)
I didn’t see those errors using 3.4.0 M5
Did you follow my test number 1?:
“Before I removed the bundle Hue Emulation from GUI “Other Add-ons” then I put the org.openhab.io.hueemulation-3.4.0-SNAPSHOT.jar in /usr/share/openhab/addons
Restart OpenHab app.”
Yes I did the same as your step 1, i.e. I did not have Hue Emulation installed before I put the jar in the addons folder.
I have understood. When I uninstall the Hue Emulation bundle, also all the relative libreries are uninstalled. For example with the original Hue Emulation installed I have:
307 │ Active │ 80 │ 2.6.1 │ JUPnP Library
but when I uninstall the Hue Emulation, the JUPnP Library will be removed and org.openhab.io.hueemulation-3.4.0-SNAPSHOT.jar will not find it.
1 Like
I must have another binding installed which also uses that dependency. You should be able to install it using karaf console or install Hue Emulation using the UI and manually stop it from karaf and start the new one.
1 Like
Well, I’ll take your advice:
- I stop the Hue Emulation with karaf
- I put org.openhab.io.hueemulation-3.4.0-SNAPSHOT.jar in /usr/share/openhab/addons.
Now I’m testing it and for now everything is running fine (and Alexa recognizes items with ID beyond FF ID!)
2 Likes
1 Like
I noticed the effects of this bug back in around 2020, everyone thought it was a network issue. I gave up trying to add more devices.
Thanks for fixing it. Looks like the PR will include the fix in the 4.0 snapshot.
Anyone know if or when we would see it in anything post 3.4.1. releases?
Can someone share the fixed jar so I can reupload it.
There appears to be little interest in getting the fix pulled in to the 3.4 Branch.