This might be relevant? 2016-10-13 11:06:42.281 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Node advancer: UPDATE_DATABASE 2016-10-13 11:06:42.283 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {} java.lang.NullPointerException at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass$CommandClass.getCommandClass(ZWaveCommandClass.java:622)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.advanceNodeStage(ZWaveNodeInitStageAdvancer.java:715)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.handleNodeQueue(ZWaveNodeInitStageAdvancer.java:230)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.ZWaveIncomingEvent(ZWaveNodeInitStageAdvancer.java:1294)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:546)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:249)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:213)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:207)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1303)[204:org.openhab.binding.zwave:2.0.0.201610121647] 2016-10-13 11:06:47.109 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 33: Timeout while sending message. Requeueing - 2 attempts left!
I got two of my FGD-212’s initialized and serialized to nodeXX.xml now.
Cloned the binding from git, removed the next line from the device definition and recompiled the binding locally: <property name="commandClass:ASSOCIATION_GROUP_INFO">ccRemove</property>
If you can grab the latest version (ie todays) it would be useful to see what is logged. I updated the logging last night so if it doesn’t work I’d like to see the log.
So - update the binding, delete the XML and restart - send me the log if it doesn’t work…
Hmm. @chris I might have just worked something out… I had some typos in my .items file, and now that I fixed them, several Things seem to be initialized! This wasn’t expect, at least to me … I thought that the Things initialization was independent of the items associated to them.
I now have node33 on ‘Node initialising: STATIC_VALUES’
Thing initialisation is independant of items - there’s definately no link so if something changed, it’s probably coincidental.
Yes - this was in the log I looked at earlier. I still need to think through this. It means that the bug from yesterday is fixed, but there is still something else at play that I need to work out.
Unfortunately this device also reports this command class into the endpoints, so I need to remove these as well. I’ve made a fix, but will merge it tomorrow.
The binding here is sending the request, it receives the response from the stick to say it received it, and it then receives the request packet which tells us the device also received it. We don’t however receive the data that we asked for, so the transaction times out.
Interesting. This looks to be the same issue as the Fibaro device, which would have made me think it was a binding issue with not interpretting the standards correctly. However I asked the ZWave people and they said that the device should respond.
Is this systematic - ie does it happen every time that the binding sends this message, or is this a one off? If it’s a one off, then that’s fine, and we have retries to handle such issues, it’s the systematic problems I’m more concerned with… (I guess this happens every time, but just to confirm rather than assume ;)).
I’ve just merged this change - please let me know how it works (or if it works). In theory it should now also remove the command class from the two endpoints…