Alexa cannot find any devices anymore with the HueEmulation Service

I am on OH2.4

same probs for me.
I rely heavily on MQTT and Hue for most of my home automation.

Is it possible to roll back to Hue 2.3 :frowning:

This is a debilitating bug - why on earth did anyone think this was worthy of pushing into production?

I am a huge fan and long term user of Openhab, but get very annoyed by constant ā€˜breaksā€™ after upgrades. I used to run whatever was available, but recently as my house has gotten more and more dependent on OH, have stuck with stable releases, Seems this is not stable at all :frowning:

Does OH 2.5M1 resolve the HUE issue?
Can I upgrade just the HUE emulation component then?

Thanks

@David_Graeff - thanks for your help so far.
I have managed to find another discussion that appears to have the answer and solution. Iā€™ll try this tonight:

seems 2.5 does resolve the bug and the current workaround is addition of the .jar file to the add-ons folder.

Itā€™s almost like OpenHab needs a ā€˜critical patchesā€™ type release framework that allows these kinds of things to be managed properly.

Irrespective - thanks for your help.

OH has no ā€œstableā€ releases. They are just called stable thatā€™s all. It is quite safe to use OH 2.5M1 because no breaking changes happened in that time period. But MQTT and Hue emulation (and also Hue) got a few fixes, as I said above.

Unpaid, freetime developers and no voluntary release testers :wink:

There are discussions on the website generation repository to create more of the binding documentation automatically. Maybe a box with breaking changes for the last couple of versions would help to decide if an upgrade is safe.

Iā€™m still on OH 2.3 (on my Synology) and try to use the hueemulation-2.5.0 (jar in addons folder) - unfortunately without success and I really donā€™t know why. Using hueemulation-2.4.0 everything does work (as dimmable lights), using hueemulation-2.5.0 the items are exposed correctly and found by my Echos and my Harmony Hub, but not responding when e. g. I try to switch an item using Alexa (although I do see the state changing on the debug window for a few seconds).

So, do I have to use OH 2.4 at least in order to get hueemulation-2.5.0 working correctly?

The release of these changes was a bit rushed, and we all learned from that, so the point youā€™re making is has valid. The more we step up to test before a release, the fewer bugs there will be, or a PR can be kept out of it. But PLEASE be mindful of your tone, and be respectful of the generous contributions made by the developers and testers in the community!

1 Like

Sorry Scott - I am not having a pop at developers, testers or the community. I am eternally grateful. My point was that the debilitating change was known (from what I understand) - but buried in release notes. I kind of feel like to should have remained in the test builds until resolved - or a workaround patch was available.

Apologies if anyone was offended - not my intention.

1 Like

Hi guys, I know my question is maybe a little bit off topic, but do you have an answer for me?

Hereā€™s some log when I try to switch an item using my Echo Dot:

15:26:04.727 [WARN ] [.eclipse.jetty.servlet.ServletHandler] - Error for /api/7170e5a2-8b48-4081-bd37-2aee4bc14be6/lights/11/state
java.lang.NoSuchMethodError: org.eclipse.smarthome.core.library.types.OnOffType.from(Z)Lorg/eclipse/smarthome/core/library/types/OnOffType;
	at org.openhab.io.hueemulation.internal.dto.HueDevice.applyState(HueDevice.java:217) ~[240:org.openhab.io.hueemulation:2.5.0.201902110612]
	at org.openhab.io.hueemulation.internal.RESTApi.handleLightChangeState(RESTApi.java:399) ~[240:org.openhab.io.hueemulation:2.5.0.201902110612]
	at org.openhab.io.hueemulation.internal.RESTApi.handleLights(RESTApi.java:329) ~[240:org.openhab.io.hueemulation:2.5.0.201902110612]
	at org.openhab.io.hueemulation.internal.RESTApi.handleUser(RESTApi.java:183) ~[240:org.openhab.io.hueemulation:2.5.0.201902110612]
	at org.openhab.io.hueemulation.internal.RESTApi.handle(RESTApi.java:143) ~[240:org.openhab.io.hueemulation:2.5.0.201902110612]
	at org.openhab.io.hueemulation.internal.HueEmulationService$1.service(HueEmulationService.java:179) ~[240:org.openhab.io.hueemulation:2.5.0.201902110612]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[31:javax.servlet-api:3.1.0]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848) ~[85:org.eclipse.jetty.servlet:9.3.21.v20170918]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [85:org.eclipse.jetty.servlet:9.3.21.v20170918]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [183:org.ops4j.pax.web.pax-web-jetty:6.0.9]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [82:org.eclipse.jetty.security:9.3.21.v20170918]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [183:org.ops4j.pax.web.pax-web-jetty:6.0.9]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [85:org.eclipse.jetty.servlet:9.3.21.v20170918]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [183:org.ops4j.pax.web.pax-web-jetty:6.0.9]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.Server.handle(Server.java:534) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [84:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [76:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [87:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [87:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [87:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [87:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [87:org.eclipse.jetty.util:9.3.21.v20170918]
	at java.lang.Thread.run(Thread.java:745) [?:?]

sorry for pulling this up.
But my Alexa wont find anymore Hueemulation exposed devices.
I am on a recent 2.5 snapshot.

Is there a approach how to find a root cause to this?
I did the standard ā€¦ reactivating pairingā€¦ pairing timeout a loooooong time etc.

stopped working for me :frowning:

openHAB core has renamed some packages recently which broke the hue emulation service (as in ā€œit waits endlessly for a signal that is never sendā€).

A community member has already proposed a hot-patch, which Iā€™m currently vetoing as only snapshot users are affected and that particular piece of code will disappear anyway.

Please try the migrated and extended hue emulation service instead:

well

19:58:01.765 [ERROR] [org.openhab.io.hueemulation          ] - bundle org.openhab.io.hueemulation:2.5.0.201904160954 (293)[org.openhab.io.hueemulation.internal.rest.StatusResource(424)] : The setUpnpService method has thrown an exception
java.lang.NullPointerException: null
	at org.openhab.io.hueemulation.internal.rest.StatusResource.remoteDeviceAdded(StatusResource.java:132) ~[?:?]
	at org.openhab.io.hueemulation.internal.rest.StatusResource.setUpnpService(StatusResource.java:59) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BindMethod.invoke(BindMethod.java:42) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1813) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.bindDependency(DependencyManager.java:1637) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.bind(DependencyManager.java:1625) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:308) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:114) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:983) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:956) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:901) [43:org.apache.felix.scr:2.1.14]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) [?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService

despite the NPE the hueemulation is active
I can open descpription.xml on 8080

however alexa wont find any devices. it did run on 8080 in the past.
is the redir to port 80 in the meanwhile absolutely mandatory?
or does UPNP in the selftest below fail due to the NPE above?

selftest

Self test

To access any links you need be in pairing mode!

Pairing mode: On

44 published lights (see http://192.168.1.1:8080/api/testuser/lights)
524 published sensors (see http://192.168.1.1:8080/api/testuser/sensors)

UPnP discovery announcements: NOT OK

Reachable?

URL Status

Users

It is not, but Amazon Echos are very picky in some countries with some firmware versions. Port 80 helps a lot. UPnP discovery announcements: NOT OK is related to the exception you see. That particular class is responsible for testing if that works.

Anyway thanks for the report, I will fix that issue. As soon as the Echos starting to look for hue bridges and after you have refreshed the self test page, you should see the echo as new user.

There is not much magic involved actually. If you can see the items published and discovery.xml is accessible and upnp works, amazon should find the hue emulation service.

ok seems I wait for the fix then

I saw there was a new jar with yesterdays date. Not sure if it contains the mentioned fix.
If so ā€¦ I got another NPE:

08:50:08.474 [INFO ] [.io.hueemulation.internal.ConfigStore] - Hue Emulation pairing enabled for 100000s
08:50:08.697 [ERROR] [org.openhab.io.hueemulation          ] - bundle org.openhab.io.hueemulation:2.5.0.201904160954 (294)[org.openhab.io.hueemulation.internal.rest.StatusResource(438)] : The setUpnpService method has thrown an exception
java.lang.NullPointerException: null
	at org.openhab.io.hueemulation.internal.rest.StatusResource.remoteDeviceAdded(StatusResource.java:132) ~[?:?]
	at org.openhab.io.hueemulation.internal.rest.StatusResource.setUpnpService(StatusResource.java:59) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BindMethod.invoke(BindMethod.java:42) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1813) [43:org.apache.felix.scr:2.1.14]
	at org.ap
ache.felix.scr.impl.manager.DependencyManager.bindDependency(DependencyManager.java:1637) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.bind(DependencyManager.java:1625) [43:org.apache.felix.scr:2.1.14]

@David_Graeff
I just installed the new jar from today.
another NPE. maybe interesting for you.

17:26:26.972 [WARN ] [mulation.internal.rest.StatusResource] - upnp service: adding services failed
java.lang.NullPointerException: null
	at org.openhab.io.hueemulation.internal.rest.StatusResource.remoteDeviceAdded(StatusResource.java:156) ~[295:org.openhab.io.hueemulation:2.5.0.201904201115]
	at org.openhab.io.hueemulation.internal.rest.StatusResource.setUpnpService(StatusResource.java:71) [295:org.openhab.io.hueemulation:2.5.0.201904201115]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.inject.methods.BindMethod.invoke(BindMethod.java:42) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1813) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.bindDependency(DependencyManager.java:1637) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.DependencyManager.bind(DependencyManager.java:1625) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:308) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:114) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:983) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:956) [43:org.apache.felix.scr:2.1.14]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:901) [43:org.apache.felix.scr:2.1.14]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) [?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461) [?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624) [?:?]

This time everything should still start up.

I have no idea why specific upnp services can cause this. Iā€™m already testing everything for being null.

@David_Graeff well self test says upnp Not Ok.

Anything I can test for you?

@David_Graeff

I recently upgraded to snapshot of OH and also to the latest version of hueemlulation

now again I have an NPE :frowning:

anything you know?

No immediate idea. Itā€™s worth a bug report though.

1 Like