Null pointer exceptions and 500 - Internal server error when configuring z-wave smoke detector

  • Platform information:
    • Hardware: 64-bit 4 cores/2GB RAM/128GB HDD (This is actually a virtual machine, but these are the specs it’s been dealt)
    • OS: Debian Stretch (9.5)
    • Java Runtime Environment: Zulu
    • openHAB version: 2.3.0

I’ve got an existing z-wave network in openHAB and it been working as well as one can expect. Today I got a new type of sensor, the Fibaro FGSD002 Smoke Detector. Adding it with the zwave binding is no problem. But then I wanted to set a location on the thing in openHAB and noticed that any time that I edit the thing I get an “ERROR: 500 - Internal server error” notification in the lower right hand corner of the browser. The location does get updated, but overall I’m not getting the data I expect from the device (temp readings, alarms etc.) so something seems off. I have no problems configuring any other of my Z-wave devices. In the log I get this:

2018-09-03 15:16:20.180 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:8fd25296:node8/config'
java.lang.NullPointerException: null
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleConfigurationUpdate( [222:org.openhab.binding.zwave:]
        at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration( [108:org.eclipse.smarthome.core.thing:0.10.0.oh230]
        at []
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke( ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?]
        at java.lang.reflect.Method.invoke( ~[?:?]
        at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$ [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.ServerRuntime$ [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.internal.Errors$ [169:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors$ [169:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process( [169:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process( [169:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process( [169:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.process.internal.RequestScope.runInScope( [169:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.server.ServerRuntime.process( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.ApplicationHandler.handle( [170:org.glassfish.jersey.core.jersey-server:2.22.2]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl( [167:org.glassfish.jersey.containers.jersey-container-servlet-core:2.2
        at org.glassfish.jersey.servlet.WebComponent.service( [167:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service( [167:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service( [167:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service( [167:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service( [15:com.eclipsesource.jaxrs.publisher:]
        at org.eclipse.jetty.servlet.ServletHolder.handle( [85:org.eclipse.jetty.servlet:9.3.21.v20170918]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle( [85:org.eclipse.jetty.servlet:9.3.21.v20170918]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle( [183:org.ops4j.pax.web.pax-web-jetty:6.0.9]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at []
        at org.eclipse.jetty.server.session.SessionHandler.doHandle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle( [183:org.ops4j.pax.web.pax-web-jetty:6.0.9]
        at org.eclipse.jetty.servlet.ServletHandler.doScope( [85:org.eclipse.jetty.servlet:9.3.21.v20170918]
        at org.eclipse.jetty.server.session.SessionHandler.doScope( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle( [183:org.ops4j.pax.web.pax-web-jetty:6.0.9]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.eclipse.jetty.server.Server.handle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.eclipse.jetty.server.HttpChannel.handle( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at org.eclipse.jetty.server.HttpConnection.onFillable( [84:org.eclipse.jetty.server:9.3.21.v20170918]
        at$ReadCallback.succeeded( []
        at []
        at$ []
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume( [87:org.eclipse.jetty.util:9.3.21.v20170918]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume( [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$ [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at [?:?]

I tried updating the Z-wave binding to 2.4.0-snapshot but the problem persists.

The Thing definition for the device may have been updated. You updated the binding, but to use an updated Thing definition, you need to delete it and rediscover to pull in the new definition. This does not mean exclude/reinclude. Just delete the Thing, start zwave discovery from Habmin or PaperUI, and add the Thing from the Inbox. Hopefully this helps! If not, then I’d suggest updating to the development version of the binding, and/or upgrade OH to a recent snapshot or milestone build. I kind of remember a similar error that was resolved in a snapshot soon after the 2.3.0 release.

Well as I said I’m on 2.4.0-snapshot for the binding. So I tried re-adding the thing. The first thing I noticed is this in the log:

2018-09-03 19:36:01.140  [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 8: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
2018-09-03 19:36:01.142 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:8fd25296:node8' to inbox.

Now, openHAB doesn’t get all the device info for a little while, this happened before as well, since the thing is battery powered and wants to sleep etc. Might the error above be related to this? openHAB not knowing what kind of thing this is until it starts talking?
Anyway, I’ll wait with testing to edit the thing until its identified properly. I’ll let you know how it works out.

Eh… Then I got this:

2018-09-03 19:48:32.018 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 8: setupNetworkKey useSchemeZero=false
2018-09-03 19:48:32.079 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2018-09-03 19:48:33.419 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 8: Already processed another send data request for this callback Id, ignoring.
2018-09-03 19:48:33.423 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 8: Already processed another send data request for this callback Id, ignoring.

Guess I’ll try exclude/reinclude as well… :stuck_out_tongue:

Phew, excluding a device is not that easy. Excluding it with the controller is simple enough, but then I had to restart openhab as well to make it go away from the inbox. That took me a while to realise. Could not understand how I had it lying next to me with the battery out and was still found :smiley:

Searching for new devices:

2018-09-03 20:25:25.050 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:8fd25296:node9' to inbox.

Then I added it:

2018-09-03 20:25:45.618 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 9: setupNetworkKey useSchemeZero=true
2018-09-03 20:25:45.619 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 9: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.

So I’m guessing that my secure include works. How to know when it is done? In paper UI it is now listed as unknown device - Node 9. No info about it being in any certain state, just online.

Sorry 5iver, I can tell that you’re already trying to reply. I’m documenting everything I do right now in this thread. :slight_smile:
So I tried to wake the smoke sensor up to make it send more data about itself. I got this in the log, but no difference under Configuration -> Things -> Node 9:

2018-09-03 20:31:26.974 [ERROR] [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/plain, type=class java.util.Collections$UnmodifiableCollection, genericType=class java.util.Collections$UnmodifiableCollection.
2018-09-03 20:32:18.311 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 9: Already processed another send data request for this callback Id, ignoring.

Yeah OK back to my original problem. Editing the thing adding a location gives the 500 Error and null pointer stuff again… What do I do now?

The snapshot version has newer Thing definitions than the 2.3.0 release version of the binding. The security error is odd, since the snapshot version does not have security. Have you set any of the security options in the binding configuration? If you want to use security, you’ll need the development version of the binding.

This is normal. If the device is battery powered, you will need to wait for it to wakeup, or you can wake it manually (check the manual).

I disagree. In Habmin, you just select the controller> Tools> Show advanced settings> Exclude devices.

Have you tried Habmin, and does it give the sames result?

Wait what? No security in 2.3.0 or 2.4.0 snapshot? You mean no secure include? Wow that’s news :smiley: I’ll turn off secure include and re-add the device again then… That explains why I’m not getting any data from it.
I’ll give habmin a try for editing, but for exclusion it simply said it could not find the device node 8 when I tried excluding it from there. Maybe because it wasn’t done with the inclusion?

Wow yeah ok, I read up some here: OH2 Z-Wave refactoring and testing... and SECURITY
I’ll try turning off secure include then :sweat_smile: and see if that helps. One WOULD think that if a feature isn’t available there’d be no option to turn it on. But then one would be wrong haha

Edit: Hang on! In the link above it says that security IS in the snapshot?

I agree, but it should be resolved soon…

The snapshot binding is built from the master branch. The binding in the first post of the thread you linked is built from the development branch. The jar is called org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar, which tends to confuse people into thinking that security is in the snapshot, but this is the only version with security. If your smoke detector requires security, you’ll need that binding.

But using the dev version may not resolve the 500 errors…

Alright! Thanks! :slight_smile:
Do you think the errors (500 and null pointers) I’ve been getting might be related to this?

Edit again: Didn’t see you last edit there. I’ll try the dev version anyway and we’ll see if the errors are still there.

The 500 errors may have been resolved in an OH snapshot build, but it may have been in the development binding… I don’t recall exactly.

I left out a step… after enabling exclusion, you need to set the device for exclusion too. Same process as inclusion.

You may want to try this…

Remember to delete all of your zwave Things, except the controller. If the dev binding doesn’t fix the 500 errors, the next thing is to try updating to an OH snapshot build.

Okay I ended up staying awake far to long messing with this and in the end I messed things up really bad :stuck_out_tongue: (Note to self: never ever remove the z-wave controller thing unless you remove the other z-wave things first!) I ended up reverting the virtual machine running openHAB to an earlier snapshot and disabled security for now. I’d really like it, but it’s more important for me to get something stable working for now. After that I included the smoke detector again and it’s working fine. I do still get 500- and nullpointer errors when editing some of my z-wave devices, but the edits seem to work anyway.

Thank you for working with me trying to solve this. I feel like I’m chickening out here, but the problem with doing things like this (testing other binding versions etc. having to add/remove devices and including/excluding) is that it messes up everything. My persistance settings and db, my rules, my sitemaps and so on… The psychological factor of investing 100s of $ and nothing working is getting to me so I opted to turn off security instead of spending more time on getting it to work, even though I’d really like it. I’m also questioning how much work I’ll have to put in to this the day that 2.4.0 is released. Maybe with some clever formatting and actually manually writing those item files it won’t be that bad.
Anyway, thank you again. :+1:

You shouldn’t need to exclude anything… just delete and rediscover the Things to pull in the updated Thing definitions. Here is a rule that will do it for you…

I’ve thought about putting this into the manual install script, but I’ve gotten little to no feedback on it, so I haven’t bothered. :slightly_smiling_face:

Having a good backup is very handy! If you’d like some more help if/when you get the nerve up, just ask! You are very welcome!

Fwiw I think puttning the the delete and rediscover rule in your script would be a great idea :blush::+1:

1 Like