OH2 Z-Wave refactoring and testing... and SECURITY

I did it the other way and copied the key from zensys to OH

Yea, that means Iā€™d have to reset everything. Back to square one. :slight_smile:

I donā€™t remember that being an issue but I may have gotten my orginal key before I started my locks. Iā€™d go with @5iverā€™s approach of OpenZwave then since you can copy your key from OH.

From what I read zensys tools doesnā€™t allow you to set a key, but it does expose the key so you could copy it over to open hab. So the way you did it is the only way that would work.

With domoticz I tried to remove and then secure include the lock. Everything seemed to work but alas openhab shows secure=false. :frowning: Iā€™m not sure how you pulled this off @5iver? I added the openzwave usb hardware on com3, went into setup and set the network security key identically to openhab. Then secure included. Did I miss something?

Everything you did looks OK to me. If you select the controller in Domiticz, does it show the actual Security Network Key as the key you entered? You have a BE469, so did it give you a green checkmark after inclusion? I donā€™t recall if I did this when I paired through Domoticz, but I know at times I had to completely reset the lock to get it to work. Were all your devices, including the lock, showing up in Domoticz and did the lock show up as using security? If that was all good, and you used the same key, then it may take a few resets in OH for the security checks to pass. I think I was reinitializing, but I may have deleted and rediscovered.

I did it a second time, exactly the same way and it appears to be semi-working. Thanks, will be a headache for sure until the binding supports this properly.

If youā€™re asking the question, then I assume not :wink: . Iā€™ve tried a number of things, but if itā€™s not working, then thereā€™s the answerā€¦ Iā€™ve checked what Iā€™m doing against the Sigma code and it looks fundamentally the same from the quick check I did.

This is an area that needs to be resolved, but at the moment Iā€™m looking at a bit of binding restructuring to allow adding a load of new features.

Oh, new features? Like what?

Could you also give us some expectations / guestimates on the long term future of this testing version? I mean ā€¦ could this make it into openhab 2.2 eventually? Or do you expect the test version to remain with its parallel life for several versions / years ā€¦ ?

Thanks for everything!

Mostly maintenance, backup, heal, routing information, link quality related functions at the moment.

Iā€™m trying to avoid making multiple sets of breaking changes that require people to re-install their system. My plan had been to merge this into 2.2, but given I want to do a bit more restructuring to incorporate some other features, itā€™s probably better to make it 2.3. (thatā€™s my thinking at the moment anyway).

It might be ok for people who are active on the forum if the binding completely changes, but there are a LOT of people using OH that arenā€™t active here, and breaking their systems isnā€™t really something I want to do (too often anyway :wink: ).

1 Like

I have a problem to report which could be healing related (not sure) ā€¦ my system appears it has lost a node over night - so it is marked offline and its events are marked as warnings in the log. I tried rebooting (openhabian) and even a complete cold start with the stick plugged out, and it still comes up as missing when openhab boots up.

With missing I mean, this (Node 18):

2017-09-17 10:21:49.225 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2017-09-17 10:21:49.305 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2017-09-17 10:21:49.362 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2017-09-17 10:21:49.363 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2017-09-17 10:21:52.707 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2017-09-17 10:21:52.709 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 2: Node found [snip]
2017-09-17 10:21:52.728 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 17: Node found
2017-09-17 10:21:52.729 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 19: Node found
2017-09-17 10:21:52.730 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 20: Node found
2017-09-17 10:21:52.732 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 21: Node found
2017-09-17 10:21:52.733 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 22: Node found
2017-09-17 10:21:52.734 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 23: Node found
2017-09-17 10:21:52.736 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2017-09-17 10:21:52.738 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2017-09-17 10:21:52.739 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2017-09-17 10:21:52.741 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 20
2017-09-17 10:21:52.743 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2017-09-17 10:23:54.880 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 18: Not initialized (ie node unknown), ignoring message.
2017-09-17 10:24:00.015 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 18: Not initialized (ie node unknown), ignoring message.
2017-09-17 10:25:08.175 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 18: Not initialized (ie node unknown), ignoring message.

I looked back through the logs, and see it was still working just before 2 oā€™clock ;

2017-09-17 01:50:12.206 [ItemStateChangedEvent ] - Z18FloodSensor_SensorTemperature changed from 21.42 to 21.34

And tonight at 2:00 (healing?) I got see this error in the log ā€¦

2017-09-17 02:01:23.940 [ERROR] [WaveSerialHandler$ZWaveReceiveThread] - Exception during ZWave thread.
java.lang.IllegalStateException: Queue full
        at java.util.AbstractQueue.add(AbstractQueue.java:98)[:1.8.0_144]
        at java.util.concurrent.ArrayBlockingQueue.add(ArrayBlockingQueue.java:312)[:1.8.0_144]
        at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.processReceiveMessage(ZWaveTransactionManager.java:347)[209:org.openhab.binding.zwave:2.1.0.201709111810]
        at org.openhab.binding.zwave.internal.protocol.ZWaveController.incomingPacket(ZWaveController.java:1216)[209:org.openhab.binding.zwave:2.1.0.201709111810]
        at org.openhab.binding.zwave.handler.ZWaveControllerHandler.incomingMessage(ZWaveControllerHandler.java:650)[209:org.openhab.binding.zwave:2.1.0.201709111810]
        at org.openhab.binding.zwave.handler.ZWaveSerialHandler$ZWaveReceiveThread.run(ZWaveSerialHandler.java:257)[209:org.openhab.binding.zwave:2.1.0.201709111810]

Hi,

I think thereā€™s a small bug that occurs whenever a zwave Item definition is changed to refer to a different zwave device.

Iā€™ve seen this a number of times, but hereā€™s an example:

my items file read:

 Number Button_Battery "Button [%d %%]"  { channel="zwave:device:zstick:node28:battery-level" }

I was having problems with zwave device 28 and so excluded it and re-included it; now itā€™s node 51, so I amended the items file:

Number Button_Battery "Button [%d %%]"  { channel="zwave:device:zstick:node51:battery-level" }

The device seems to work fine, but I get this error occasionally in the logs:

[WARN ] [.thing.internal.CommunicationManager] - Cannot delegate update '100' for item 'Button_Battery' to handler for channel 'zwave:device:zstick:node28:battery-level', because no thing with the UID 'zwave:device:zstick:node28' could be found.

Dan

Iā€™m not sure this can be anything in the binding. Assuming the thing exists then itā€™s up to the system to delegate items to channels and the binding only knows the world of channels.

If you can provide more info then I can take a look, but at the moment thereā€™s nothing I can really do.

thanks - donā€™t worry about it then. Completely unserious problem.

With this last update, the Karaf console has started filling up with these as devices initialize:

Exception in thread "Thread-302" java.lang.NullPointerException
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:409)
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:435)
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialiseNode(ZWaveThingHandler.java:277)
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.ZWaveIncomingEvent(ZWaveThingHandler.java:1277)
        at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:549)
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.setCurrentStage(ZWaveNodeInitStageAdvancer.java:1055)
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.access$5(ZWaveNodeInitStageAdvancer.java:1046)
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:200)

The log has one of these for each device on startup:

2017-Sep-18 02:19:29.770 [ERROR] [eclipse.smarthome.core.thing.internal.ThingManager] - Exception occurred during notification about bridge status change on thing 'zwave:device:07cb40a2:node183': null
java.lang.NullPointerException: null
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:409) [15:org.openhab.binding.zwave:2.1.0.201709172254]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:435) [15:org.openhab.binding.zwave:2.1.0.201709172254]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialiseNode(ZWaveThingHandler.java:277) [15:org.openhab.binding.zwave:2.1.0.201709172254]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged(ZWaveThingHandler.java:504) [15:org.openhab.binding.zwave:2.1.0.201709172254]
        at org.eclipse.smarthome.core.thing.internal.ThingManager$9.run(ThingManager.java:787) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

And one of these for each device after stopping the binding:

2017-Sep-18 02:09:59.849 [ERROR] [eclipse.smarthome.core.thing.internal.ThingManager] - Exception occurred while disposing handler of thing 'zwave:device:07cb40a2:node87': java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
        at java.util.concurrent.FutureTask.report(FutureTask.java:122) [?:?]
        at java.util.concurrent.FutureTask.get(FutureTask.java:206) [?:?]
        at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194) [100:org.eclipse.smarthome.core:0.9.0.201709011622]
        at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83) [100:org.eclipse.smarthome.core:0.9.0.201709011622]
        at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67) [100:org.eclipse.smarthome.core:0.9.0.201709011622]
        at org.eclipse.smarthome.core.thing.internal.ThingManager.doDisposeHandler(ThingManager.java:728) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        at org.eclipse.smarthome.core.thing.internal.ThingManager.disposeHandler(ThingManager.java:716) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        at org.eclipse.smarthome.core.thing.internal.ThingManager.unregisterAndDisposeHandler(ThingManager.java:762) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        at org.eclipse.smarthome.core.thing.internal.ThingManager.unregisterAndDisposeChildHandlers(ThingManager.java:752) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        at org.eclipse.smarthome.core.thing.internal.ThingManager.unregisterAndDisposeHandler(ThingManager.java:760) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        at org.eclipse.smarthome.core.thing.internal.ThingManager.removeThingHandlerFactory(ThingManager.java:983) [107:org.eclipse.smarthome.core.thing:0.9.0.201709011622]
        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.BaseMethod.invokeMethod(BaseMethod.java:229) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.inject.BaseMethod$Resolved.invoke(BaseMethod.java:650) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.inject.BaseMethod$NotResolved.invoke(BaseMethod.java:609) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.inject.BaseMethod.invoke(BaseMethod.java:506) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.inject.BindMethod.invoke(BindMethod.java:658) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1837) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:395) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:375) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:291) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1241) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1136) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:996) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1175) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:127) [40:org.apache.felix.scr:2.0.12]
        at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) [?:?]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:915) [?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) [?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) [?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) [?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:909) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:874) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:139) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:951) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:806) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:788) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:580) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:706) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:523) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:439) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.Activator.access$300(Activator.java:54) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:293) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:285) [40:org.apache.felix.scr:2.0.12]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:307) [40:org.apache.felix.scr:2.0.12]
        at org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:181) [40:org.apache.felix.scr:2.0.12]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903) [?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156) [?:?]
        at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
        at org.eclipse.osgi.container.Module.doStop(Module.java:634) [?:?]
        at org.eclipse.osgi.container.Module.stop(Module.java:498) [?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1661) [?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1580) [?:?]
        at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:270) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:147) [?:?]
        at org.eclipse.osgi.container.Module.doStop(Module.java:636) [?:?]
        at org.eclipse.osgi.container.Module.stop(Module.java:498) [?:?]
        at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.NullPointerException
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.dispose(ZWaveThingHandler.java:526) ~[?:?]
        at org.eclipse.smarthome.core.thing.internal.ThingManager$8.call(ThingManager.java:733) ~[?:?]
        at org.eclipse.smarthome.core.thing.internal.ThingManager$8.call(ThingManager.java:1) ~[?:?]
        at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:?]

FYI, I donā€™t see any stacktraces in the openhab.log using the Sept. 17th version, but I see errors for all my current nodes:
[ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:device:xxxx
Reverted to the original 2.1 version, these errors do not appear and all devices are working again.

Do you have a completely different configuration for the two versions, or are you only swapping the bindings?

I only swap the bindings.

Then this explains the problem. You need to delete all things and add them back when swapping between bindings.

Thanks for the information. I would rather not delete all things, so I guess Iā€™ll either set up an additional environment or just waitā€¦

Iā€™m seeing NPEā€™s every few minutes with the latest build (9/17) that I didnā€™t see in the 9/16 build. I believe itā€™s due to a refresh command Iā€™m calling every minute to make sure my Zwave lock stays up-to-date:

sendCommand(Entry_DoorLock_S,RefreshType.REFRESH)

Here is the debug log:

2017-09-18 15:16:00.023 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Command received zwave:device:15a076229ab:node20:lock_door --> REFRESH
2017-09-18 15:16:00.028 [ERROR] [ternal.profiles.DefaultMasterProfile] - Exception occurred while calling handler: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
	at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:220) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:189) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.DefaultMasterProfile.onCommand(DefaultMasterProfile.java:49) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.CommunicationManager.lambda$2(CommunicationManager.java:177) ~[?:?]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) [?:?]
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) [?:?]
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) [?:?]
	at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) [?:?]
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) [?:?]
	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:270) [?:?]
	at java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566) [?:?]
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) [?:?]
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) [?:?]
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) [?:?]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) [?:?]
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) [?:?]
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) [?:?]
	at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receiveCommand(CommunicationManager.java:172) [109:org.eclipse.smarthome.core.thing:0.9.0.201709121704]
	at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receive(CommunicationManager.java:91) [109:org.eclipse.smarthome.core.thing:0.9.0.201709121704]
	at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:193) [102:org.eclipse.smarthome.core:0.9.0.201709121704]
	at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1) [102:org.eclipse.smarthome.core:0.9.0.201709121704]
	at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181) [102:org.eclipse.smarthome.core:0.9.0.201709121704]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
	at java.lang.Thread.run(Thread.java:745) [?:?]
Caused by: java.lang.NullPointerException
	at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:409) ~[?:?]
	at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleCommand(ZWaveThingHandler.java:945) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.DefaultMasterProfile$1.call(DefaultMasterProfile.java:52) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.DefaultMasterProfile$1.call(DefaultMasterProfile.java:1) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:218) ~[?:?]
	... 27 more