Getting Hue emulation working with Alexa again


I’m struggling to get Hue Emulation working with Alexa on OH3. For now I did the following:

  • Pairing is working fine, devices are discovered by Alex
  • Setup nginx reverse proxy with config below
  server {
    listen 80;
    location /api {
      proxy_pass http://localhost:8080/api/;

Anyhow, I get an exception by the Hue Emulation binding during startup:

2020-12-23 07:56:23.037 [WARN ] [ache.cxf.phase.PhaseInterceptorChain] - Interceptor for {}WebClient has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not receive Message.
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage( ~[bundleFile:1.0.9]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.WebClient.doInvoke( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.WebClient.doInvoke( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.WebClient.invoke( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.SyncInvokerImpl.method( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.SyncInvokerImpl.method( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.SyncInvokerImpl.get( [bundleFile:1.0.9]
	at org.apache.cxf.jaxrs.client.spec.InvocationBuilderImpl.get( [bundleFile:1.0.9]
	at [bundleFile:?]
	at java.util.concurrent.CompletableFuture$UniApply.tryFire( [?:?]
	at java.util.concurrent.CompletableFuture$Completion.exec( [?:?]
	at java.util.concurrent.ForkJoinTask.doExec( [?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec( [?:?]
	at java.util.concurrent.ForkJoinPool.scan( [?:?]
	at java.util.concurrent.ForkJoinPool.runWorker( [?:?]
	at [?:?]
Caused by: SocketTimeoutException invoking Read timed out
	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance( ~[?:?]
	at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance( ~[?:?]
	at java.lang.reflect.Constructor.newInstance( ~[?:?]
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException( ~[bundleFile:1.0.9]
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close( ~[bundleFile:1.0.9]
	at ~[bundleFile:1.0.9]
	at org.apache.cxf.transport.AbstractConduit.close( ~[bundleFile:1.0.9]
	at org.apache.cxf.transport.http.HTTPConduit.close( ~[bundleFile:1.0.9]
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage( ~[bundleFile:1.0.9]
	... 18 more

I wonder why it’s requesting /description.xml and not /api/description.xml?

When I try to turn the lights off with Alexa, Alexa responds “Light does not respond”.

Any idea what could be wrong here?

Try adding the following in you nginx config:

 location /description.xml {
                proxy_pass http://localhost:8080;

Do you see anything in the event log when asking Alexa to control the light?

With adjusting the proxy config as suggested, I got rid of the exception now. But I still have the same issue (“XXX does not respond”). There is nothing in the event log.

If you look in the Alexa app do you have any duplicates for your lights in the devices section?

No, I also deleted all devices before doing the pairing process.

Do you have anything else you can use to check if the Hue Emulation is working, e.g. the “Hue Control” app for Android?

Are you able to capture the HTTP traffic to/from port 80 to see what’s going on?

Have you found the source of the problem? It is the same for me, Items are found by Alexa, but I can no longer control them.

Are you using 3.0 or 3.1 snapshot?

Can you try the latest snapshot to see if it makes any difference?

Can you capture the HTTP traffic going to/from port 80 when trying to control the light and post it here?

1 Like

@vbier is this a fresh install of OH3 or is it an upgrade from 2.x?

If it was an upgrade, can you try clearing the unique bridge id in the advanced settings for Hue Emulation. Restart OH, forget all devices in Alexa and then enable pairing and rediscover devices.

I upgraded from 2.5.

I just spent the last hour to remove the devices, changed the bridge UUID (making it empty does not seem to set a new UUID, it stays empty) and rescanned the devices.

The devices that I had found the last time seem to be devices that had been cached in one of my echos. When unplugging it, no devices are found at all. So I removed my iptables rule and set up nginx with the following config file:

server {
  listen 80;

  location /api {
    proxy_pass http://localhost:8080/api/;

  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;

I then used the alexa web page to remove all devices and triggered a rescan. No devices were found.

I then removed the hueemulation and dropped the linked jar in my addons folder, restarted openHAB and my items were found by the following rescan and are working as expected.

Thanks for your help.

Glad you got it working.

To summarise for other users having the same problem.

The problem with devices not responding is probably due to Alexa caching and you need to change the uuid to workaround that. After you have cleared the uuid you need to restart OH for the Hue Emulation to generate a new one. It’s best to let a new one be auto generated in the correct format rather than trying to set it manually.

If using 3.0 the uuid needs to be in the format of 48:49:22:9A:9B:5A:E8:B2 and this is used as the prefix to generate a unique ID for each light. Without the uuid in that format Alexa will not discover devices.

If using 3.1 the uuid should be a proper uuid format (as was the case in 2.x) and the Hue Emulation generates Alexa friendly unique IDs without using the uuid as the prefix.

I too have this problem.
Where should I change the UUID?

I’ve tried the addon jar but that gave the following error:

20:21:10.576 [ERROR] [          ] - bundle (279)[] : The configurationAccess field has thrown an exception
20:21:10.579 [ERROR] [          ] - bundle (279)[] : The cs field has thrown an exception
20:21:10.581 [ERROR] [          ] - bundle (279)[] : The discovery field has thrown an exception
20:21:10.583 [ERROR] [          ] - bundle (279)[] : The lightItems field has thrown an exception
20:21:10.585 [ERROR] [          ] - bundle (279)[] : The rules field has thrown an exception
20:21:10.587 [ERROR] [          ] - bundle (279)[] : The scenes field has thrown an exception
20:21:10.589 [ERROR] [          ] - bundle (279)[] : The schedules field has thrown an exception
20:21:10.591 [ERROR] [          ] - bundle (279)[] : The sensors field has thrown an exception
20:21:10.593 [ERROR] [          ] - bundle (279)[] : The statusResource field has thrown an exception
20:21:10.595 [ERROR] [          ] - bundle (279)[] : The userManagement field has thrown an exception
20:21:10.600 [ERROR] [          ] - bundle (279)[] : The activate method has thrown an exception
java.lang.NullPointerException: null
        at ~[?:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke( ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?]
        at java.lang.reflect.Method.invoke( ~[?:?]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod( ~[bundleFile:?]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500( ~[bundleFile:?]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke( ~[bundleFile:?]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke( [bundleFile:?]
        at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke( [bundleFile:?]
        at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.getService( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable( [bundleFile:?]
        at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents( [bundleFile:?]
        at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable( [bundleFile:?]
        at org.apache.felix.scr.impl.Activator.loadComponents( [bundleFile:?]
        at org.apache.felix.scr.impl.Activator.access$200( [bundleFile:?]
        at org.apache.felix.scr.impl.Activator$ScrExtension.start( [bundleFile:?]
        at org.apache.felix.scr.impl.AbstractExtender.createExtension( [bundleFile:?]
        at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle( [bundleFile:?]
        at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle( [bundleFile:?]
        at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified( [osgi.core-6.0.0.jar:?]
        at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified( [osgi.core-6.0.0.jar:?]
        at org.osgi.util.tracker.AbstractTracked.track( [osgi.core-6.0.0.jar:?]
        at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged( [osgi.core-6.0.0.jar:?]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.container.Module.publishEvent( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.container.Module.start( [org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start( [org.eclipse.osgi-3.12.100.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle( [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles( [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess( [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process( [bundleFile:3.6.4]
        at [bundleFile:3.6.4]
20:21:10.615 [ERROR] [          ] - bundle (279)[] : The configStore field has thrown an exception

If you’ve dropped the jar in addons you need to also uninstall it from the UI.

The bridge id can be found in the advanced settings for the Hue Emulation:

thanks. I did a fresh install due to a multitude of errors and this has not returned.

Whenever I attempt to install or start the latest 3.1 SNAPSHOT on openHAB v3.0.1, I hit the following errors:

openhab> list -s | grep hue
197 x Installed x  80 x      x

openhab> bundle:start
Error executing command: Error executing command on bundles:
        Error starting bundle 197: Could not resolve module: [197]
  Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"

openhab> bundle:install
Bundle IDs:
Error executing command: Error installing bundles:
        Unable to install bundle org.osgi.framework.BundleException: Error reading bundle content.

Does the latest SNAPSHOT version of Hue Emulation maybe require openHAB v3.1?

Hello Mike,

i use in OH3.0 the emulation to connect openhab with my free@home Homeautomationsystem.
Everything works fine since i have to much Items in OH3.

My free@home System finds only emulated Items with nummeric ID:


I installed more and more bindings /items, so the emualtion generates ID’s with a letter ID:


Would this fix in 3.1 with the prefix Bug from the bridge uuid ?
Or is it possible to generate the item id manuelly ?


It’s not possible to control how the unique id is generated and it will be the same in 3.1.

However there’s another light id which is used and this will always be an integer in 3.1 rather than hexadecimal in 3.0, so unless it’s definitely the unique id which is causing the problem you might find 3.1 works for you.

1 Like

Thanks for your fast reply!

Thats good news.
Integer should works for me, i think free@home is not much different to the Amazon devices …

Do i have to generate a new Bridge ID in 3.1 ?
When so, than i stoped my working so far …

Do you know when 3.1 stable would release ?

Thanks for your great work !

getting my Hue Emulation not to work after having installed the reverse proxy nginx and runnning openhabian 3.1 as suggested is very frustrating for me.

I am wondering if this could be the reason for the Alexa discovery failing:
UPnP discovery test answer: “service not registered”. (screenshot of “”)


If this is my problem, how do i solve this?

The reachability test gives me positive answers, so that should not be the problem.
I deleted the bridgeID, uninstalled and reinstalled the binding, started the discovery from multiple devices with Hue Emulation V2 or V1 and with or without “unknown user keys”.

Thanks for your help in advance!


From another thread with UPnP and Hue emulation problems I found the idea to try different ports in the advanced settings of the Hue emulation. Setting it to port 8080 worked for me.
Problem solved for me!
By the way, the api-page stills says UPnP service not registered, but Alexa found my devices.