[hueemulation] Binding - Not detecting new devices

Setup, Configuration and Use Installation
1

Have been running the Hue Emulation Binding for years with no problems to control a variety of switches & color light bulbs throughout the house. As I added a new Echo to the network the other day, the latest 5th gen Amazon Echo (just released in late October 2022) via the Amazon App, I noticed during its setup process all of my devices controlled via this binding turned red/offline within the Alexa App. And suddenly all of my voice control is seemingly broken!

I’ve rolled through every angle I could think of to fix this thus far, such as:

  • Rebooting EVERYTHING (hardware, networking, Echos, OpenHAB server)
  • Attempted all available troubleshooting steps in the documentation on the Hue Emulation binding & threads on this forum
  • Deeply reviewed my /api/status and /description.xml pages - appear to be fine
  • Confirmed my nginx proxy is still working as expected (all endpoints work over 80/8080 just fine)
  • Confirmed during ‘start discovery’ via a physical Echo and alexa.amazon.com, it is hitting my Openhab hueemulation endpoints, which I can see via the nginx logging
  • Confirmed ‘Reachability test’ on the /api/status page is returning YES for both ‘Responds’ and ‘Ours’.
  • Studied the API GET response directly; and all looks good there - includes metadata on the expected 56 light ‘things’ which are all tagged correctly at the item level within my Openhab model - nothing was changed there.
  • Deregistered all Echos and smart home Devices and re-registered just a couple (the pre-5th Gen Echos), re-tried discovery from both the web and multiple physical devices (same results, nothing new provided by the hueemulation binding found)
  • Changed Unique Bridge ID via the binding configuration, removed all smart home devices via alexa.amazon.com & stopped/cleared Openhab caches/restarted Openhab server many times
  • Tried ’ Logout and create new device id’ via /amazonechocontrol
  • Enabled DEBUG logging in Karaf console with following; nothing obvious of concern is captured:
log:set debug org.openhab.io.hueemulation
  • Attempted to ‘start discovery’ while in combinations of hueemulation binding pairing config states (i.e. ’ Pairing: Add Unknown User-keys’ and ‘Pairing: Temporarily Emulate V1 Hue Bridge’, toying with IP/Port, etc)
  • For further testing, installed ‘Hue Essentials’ App on Android. The app immediately sees my Openhab hueemulation service and can see and control everything without issue after being paired… However Echo discovery process still isn’t finding anything ‘new’ when connecting to hueemulation.
  • Studied my item IDs to make sure they are short and unique.
  • Reviewed various issues/suggestions on HA-Bridge; [hueemulation] github issue trackers

In all cases, currently nothing new controlled via Openhab Hue Emulation is discovered by my Echos. I’d suggest that everyone using Alexa with the Openhab Hue Emulation binding - to save you potential headaches here, be cautious of adding a 5th gen device to your Amazon account! Otherwise kindly chime in here and let us know that its working fine for you! :slight_smile:

If anyone can provide some thoughts/help/advice here to get this resolved, it would be much appreciated!

  • Platform information:
    • Hardware: RPI4
    • OS: Openhabian
    • Java Runtime Environment: openjdk version “11.0.13” 2021-10-19 LTS
    • openHAB version: 3.3.0
2

Yay! Got it back online and working after some serious trial and error! Hopefully this helps someone else. For whatever reason, as soon as I added my first 5th Gen Echo into the mix, it seemingly triggered re-discovery and broke everything. Not positive as to precisely what fixed it, but here is a summary of changes I made along the way:

-I’m now running a dual stack IPV4/IPV6 network configuration (new router), which may be different since the last time I needed to run Hue Emulation discovery. In my nginx proxy configuration (as suggested in the Hue Emulation documentation), added this in addition to the listen 80; to handle IPv6 too:

listen [::]:80;

-Set the Hue Emulation binding config to:

Optional Discovery Address: Empty (was previously an IPv4 address)

Optional Discovery Web Port:  8080 (was previously unset)

Unique Bridge ID:  00:ec:81:52:63:1a:94:72 (A proper UUID instead of a short string.  This can be anything in hexadecimal.  From my research, in the past years there have been breaking changes related to the Alexa API with the IDs needing to be 9 octets for discovery to work.  Note that the item ID is appended to this Unique Bridge ID 8 octets by the Hue Emulation binding!)

And the big one to note that may have seriously slowed down my time to resolution here - the Openhab Hue Emulation binding doesn’t actually update the 'uniqueid’s until a full Openhab service restart! For instance, even though the bridge ID changed via the Web UI configuration, and was displayed in various places such as /api/status and /description.xml, when looking at raw individual API requests, the old Bridge config value was still in use. This seemingly caused an odd mismatch between what was being broadcasted via uPNP vs what Openhab would actually control! Long story short, always fully restart the Openhab server service if you change the Hue Emulation’s Unique Bridge ID! Here is an example of such API requests my Echo’s were making during a device discovery request, which I captured via the nginx logs:

/api/4d4e98be-4641-4637-a2ef-9d2aea766187/lights

After the above config changes, restarting Openhab, and re-running discovery - BAM - 40+ new devices were detected and working again via voice control even on my new 5th Gen Echos. Its an early Christmas miracle!!! :smiley:

Super happy to have my gear controlled mostly via the LAN once again instead of introducing heavy reliance on the cloud! Granted, Alexa commands wont work without internet, but I always favor keeping it all ‘in house’ as much as possible. :slight_smile:

.

2 Likes
3

Also, for others out there, I came across multiple references on the forums stating the Openhab [hueemulation] binding is no longer supported. Curious to know if that is the case, and if so, why there is there no mention in the official documentation here:

.

2 Likes
4

While my original issue above is a bit different, this is also related - Alexa was discovering only SOME of my exposed devices via [hueemulation] depending on their automatically generated Unique ID.

BIG thanks goes out to @MikeJMajor for helping identify & develop the fix, as well as submitting a proper PR here!

5

I apprechiate this topic with all of your findings.

Since I moved my openhab instance from a raspberry pi with docker to a vm in proxmox on a amd64 PC alexa doesn’t find any Devices…

I tried all combinations of v2, v1 and New Keys but it does not work for me, even when I create a New bridge id or Set it manually. I searched many many hours for a solution because I thought it relates to proxmox.

I don’t understand why the hue Emulation creates a uuid with a completly different style than the one you mentioned.
I tried yesterday to Set the bridge id to 00:ec:81:52:63:1a:94:72 but I only got errors that the Format is incorrect.

Then I updated to the Milestone 6 of 3.4.0 and the error is gone.

All4hue works like perfectly and discovers the bridge with all of the bridge id types.

In the ngix access log I only get the following line while the alexa App is searching for Devices and the bridge is in pairing Mode.

192.168.178.72 - - [16/Dec/2022:13:22:19 +0100] “POST /api HTTP/1.1” 302 5 “-” “-”
1

6

Thanks Dustin!

Based on your description I would suspect something is up with either the hueemulation settings and/or your nginx configuration. Once I managed to get this working again, the nginx logs were showing HTTP Status Code of 200 for each request, whereas yours is a 302. During discovery I saw requests hitting nginx running on my OpenHab server from every Alexa device on my home network.

I’d also make sure your servers /api/status and /description.xml pages are responding by visiting them directly in the browser and studying the response.

Hope that leads you in the right direction!

.

1 Like
7

@Desmond206x - For completeness sake, here is my FULL nginx configuration. I think you could be missing the /api/ handling which is throwing the 302, as mentioned in the documentation!

server {
  listen 80;
  listen [::]:80;
  location / {
    proxy_pass                              http://localhost:8080/;
    proxy_set_header Host                   $http_host;
    proxy_set_header X-Real-IP              $remote_addr;
    proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto      $scheme;
  }
}

server {
    listen 80;
    listen [::]:80;
    location /api {
      proxy_pass http://localhost:8080/api/;
    }
}
1 Like
8

I don’t know what was really wrong, but I tested your configuration and my nginx won’t reload because of two server with the same name. So I added the server name property but the /description.xml and /api/status won’t work anymore.

After a bit of testing I tried your part with the /api inside my server block as a second (third, because I have another location) location.

The two addresses worked again and alexa has found all of my devices :grinning::+1:

I think it was the /api part, but I don’t get why, because the url worked fine without it, even on port 80. I even didn’t find the part in the documentation about this additional needed Config…

Thank you very much for the help!

My complete Config

server {                                                                             listen 80;
  listen [::]:80;

  location /weatherstation {
   proxy_pass http://127.0.0.1:8080/httplistener/weatherstation;
  }

  location / {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }

  location /api {
    proxy_pass http://localhost:8080/api/;
  }
}
1 Like