The new storage system that I’m using is the json storage. That interface is also used to store Things and Items that are created via Paper UI etc. But unfortunately it resets after every start and non of the core developers has answered my help request yet. See also https://github.com/openhab/openhab2-addons/issues/4602.
I have the exact same issue, I though I am the only one and it is so annoying.
Similar scenario, I have 3 Scenes:
- “Home Cinema”: turn on AVR, switch to HDMI1, turn on Projector, turn on PC (WOL)
- “Android”: turn on AVR, switch to HDMI2, turn on Projector
- “Nintendo”: turn on AVR, switch to HDMI3, turn on Projector
Before the update it was no problem to trigger an Item Scene to ON when it was already ON, the rules fired again, this does not happen anymore after the update.
Why this is an issue:
- Someone turns on the scene “Home Cinema”
- Someone forgets to turn it off and the projector and AVR turn of automatically after 30min inactivity or someone uses the remote and switches manually → the state of the scene “Home Cinema” is still ON
- Now the status of the item “Home Cinema” in OH is still ON but the devices are actually OFF
- In the past I could just say “Turn Home Cinema On” and everything would turn on again, this now does not happen anymore as the status is already ON.
I can also not determine during runtime what scene apparently is currently on as some devices do not report the status back properly
Are you on OH 2.5M1? The OH2.4 release was more or less very unfortunate for the hue emulation service and MQTT binding.
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 
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
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 
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 
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.