Yes - the binding is still the old one… Also, when posting logs, please format using the </> button so they are more readable.
Hmm. I tried again and it just seems to get the same binding version each time. It SHOULD update when I uninstall/re-install via habmin, shouldn’t it?
Yes, it should. It looks like everything has built - both the bundles and the distribution, so I’m not sure why it’s not updating.
I also do have some update problems at the moment (see my thread). Don’t know if this is a general problem atm.
At least I could update the binding through the karaf console with bundle:update xxx. Maybe you can try this?
Sorry - what thread do you refer to?
What problem do you mean? The issue here is specific to the FGD212 as it seems the device has a bug.
Sorry for misunderstanding. I mean the problem of the binding probably not being updated (automatically). It wasn’t about the problem of the device.
This one: Do I get the latest update with apt-get? Helping eyes needed!
Sorry - I hadn’t seen that thread.
I see elsewhere that people have been able to update to the latest version compiled tonight - I’m not sure how the apt build is built and distributed - it may only be nightly (??). If so, given that builds have been broken for the past few days, it may not update until tonight.
Even after:
bundle:update 204
I still see:
204 | Active | 80 | 2.0.0.201610120746 | Wave Binding
I’m not quite sure what else to try! Well, I guess I should try to manually download the binding next, but I’m trying to do this at the same time as cooking dinner, which is making everything take a while.
I tried again and it finally updated the binding, but node 33 is now reporting ‘Node initialising: UPDATE_DATABASE’
I now see the following:
- node 9: Node initialising: WAIT
- node 21: Node initialising: PING
- node 23: Node initialising: GET_CONFIGURATION
- node 27: Node initialising: WAIT
- node 29: Node initialising: WAIT
- node 30: Node initialising: WAIT
- node33: Node initialising: UPDATE_DATABASE
- node35: Node initialising: STATIC_VALUES
I’ve put a logfile here
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>
I guess you have the version that has fixed firmware - lucky you 
Probably, but I couldn’t get it to work with that line in the device file 
No - as above, we’re trying to fix this for the version that is broken, so sorry for the hassle… It will be resolved in the next day or two.
@chris I’ll be at my house tonight and so able to trigger devices etc. Let me know if there’s anything I can do to help you debug this?
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…
Thanks
Chris
Okay, I just arrived and have updated the bundle to:
204 | Active | 80 | 2.0.0.201610140851 | ZWave Binding
No xml to delete for nodes 33 and 34 because they never initialised…
BTW some nodes which HAD worked before, now seem stuck (e.g. node 28)
Logfile is here
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’
An updated logfile is here
Edit: btw the refresh happened here:
2016-10-14 20:56:25.792 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'rambert.items'
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.