ID lock 150 Can't change values /error message log


I have two ID lock 150 and after i have made a new clean installation of Openhab the locks doesnt work as they should.
I have tried OH2 and OH3 with the same results now and I am wondering if it has to do with the resent update of the lock… I am now on version 1.6.
The locks are excluded and reset to factory default before new inclusion.
Everytime I browse or change my settings for the ID lock-thing I get a long error i the log:

2021-06-02 07:33:37.651 [ERROR] [internal.JSONResponseExceptionMapper] - Unexpected exception occurred while processing REST request.

java.lang.NullPointerException: null

at org.openhab.binding.zwave.internal.ZWaveConfigProvider.getConfigDescription( ~[?:?]

at org.openhab.core.config.core.ConfigDescriptionRegistry.fillFromProviders( ~[?:?]

at org.openhab.core.config.core.ConfigDescriptionRegistry.getConfigDescription( ~[?:?]

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.cxf.service.invoker.AbstractInvoker.performInvocation( ~[bundleFile:1.0.9]

at org.apache.cxf.service.invoker.AbstractInvoker.invoke( ~[bundleFile:1.0.9]

at org.apache.cxf.jaxrs.JAXRSInvoker.invoke( [bundleFile:1.0.9]

at org.apache.cxf.jaxrs.JAXRSInvoker.invoke( [bundleFile:1.0.9]

at org.apache.cxf.interceptor.ServiceInvokerInterceptor$ [bundleFile:1.0.9]

at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage( [bundleFile:1.0.9]

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( [bundleFile:1.0.9]

at org.apache.cxf.transport.ChainInitiationObserver.onMessage( [bundleFile:1.0.9]

at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke( [bundleFile:1.0.9]

at org.apache.cxf.transport.servlet.ServletController.invokeDestination( [bundleFile:1.0.9]

at org.apache.cxf.transport.servlet.ServletController.invoke( [bundleFile:1.0.9]

at org.apache.cxf.transport.servlet.ServletController.invoke( [bundleFile:1.0.9]

at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke( [bundleFile:1.0.9]

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest( [bundleFile:1.0.9]

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet( [bundleFile:1.0.9]

at javax.servlet.http.HttpServlet.service( [bundleFile:3.1.0]

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service( [bundleFile:1.0.9]

at org.eclipse.jetty.servlet.ServletHolder.handle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.servlet.ServletHandler.doHandle( [bundleFile:9.4.20.v20190813]

at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle( [bundleFile:?]

at org.eclipse.jetty.server.handler.ScopedHandler.handle( [bundleFile:9.4.20.v20190813]

at [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.session.SessionHandler.doHandle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.ContextHandler.doHandle( [bundleFile:9.4.20.v20190813]

at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle( [bundleFile:?]

at org.eclipse.jetty.server.handler.ScopedHandler.nextScope( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.servlet.ServletHandler.doScope( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.session.SessionHandler.doScope( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.ScopedHandler.nextScope( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.ContextHandler.doScope( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.handler.ScopedHandler.handle( [bundleFile:9.4.20.v20190813]

at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle( [bundleFile:?]

at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.Server.handle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.HttpChannel.handle( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.server.HttpConnection.onFillable( [bundleFile:9.4.20.v20190813]

at$ReadCallback.succeeded( [bundleFile:9.4.20.v20190813]

at [bundleFile:9.4.20.v20190813]

at$ [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce( [bundleFile:9.4.20.v20190813]

at [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( [bundleFile:9.4.20.v20190813]

at org.eclipse.jetty.util.thread.QueuedThreadPool$ [bundleFile:9.4.20.v20190813]

at [?:?]

I can not get this right… It only happens with the ID locks.


The recommended way for zwave is to NOT use a Things file due to the high potential for problems.

This error looks related to the REST API, not zwave. I suspect that problem relates to a different addon or configuration.

There were large breaking changes in the REST API for OH3.

Thank you.
I am not using a file, i added the ID Lock from inbox after including.

The openhab installation is fresh with only z-wave binding. Nothing else. Tested with two controllers and oh2.5 and oh3. Rpi3b and rpi4 also. Maybe I am missing some addons/java?

@Kattlukt Was this issue solved? I have the same issue with the new entry in the database for IDLock 150 FW v1.6.


Hopefully this will be fixed in the latest version.

1 Like

I think I am on to something here…
My parameter 7, config_7_1, was set to -106.
I managed to change that to 0 after a number of tries.
Now it stays at the value 0 and I can change everything!

My guess is that is a different issue to what was in the original post as the exception above is from the config provider - not the config handler.

It would be useful to know what device this is for - do you have the database reference please?

I guess you came from a version that had the former FW v1.6 device. This was removed for some reason in December 2020 and max version for IDLock 150 was 1.5. A new entry for FW v1.6 is added to the database (you need snapshot release to get it). I had the same “null” error message in the log. See my post here on how I got rid of it: IdLock 150 FW 1.6 - #20 by vegarroe

Be aware that you have to diferentiate between the locks FW and the Z-Wave module FW.

My solution, hopefully it will stay stable:

  • unlink items and delete thing
  • stop openHAB
  • delete the userdata/zwave/network_xxxxxxxx__node_yy.xml
  • clean cache (sudo openhab-cli clean-cache)
  • update to openhab snapshot
  • start openhab
  • discover and add thing