Awesome, thank you! But which one… I’ve reported a few lately…
Exception in thread “Timer-113” java.lang.NullPointerException
Exception in thread “Thread-215” java.util.ConcurrentModificationException
java.security.InvalidKeyException: No installed provider supports this key: (null)
devices getting stuck in initialization
Adding node_1_null
The one I replied to 
. I think if you click the message it shows what message I replied to - it’s the null association name.
Thank you for looking at it!!! Hope I did it all good/clean. Deleted Thing, uninstalled binding, reboot, install binding, add thing, discovery, add Fibaro binary. Linked Binary switches and added association groups. Can see debug output printing when sensor triggers, but the item not updated.
full log from binding install here
Ah! In that case, I still see it using 2.2.0.201711141803…
2017-11-14 13:56:01.566 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 42: Update ASSOCIATION group_org.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup@5052abb: Adding node_1_null
Another thing I’m seeing, which may not be new and I’m only noticing it now, is that I see a LOT of these
2017-11-14 14:24:23.897 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - TID 1295: Transaction event listener: DONE: CANCELLED ->
2017-11-14 14:24:23.897 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 255: -- To notify -- TIMEOUT_WAITING_FOR_CONTROLLER
2017-11-14 14:24:23.898 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - ********* Transaction Response Complete 1295 --
2017-11-14 14:24:23.898 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 88: Node Init response (0) TIMEOUT_WAITING_FOR_CONTROLLEROk, so I’ve noticed that this device is not reporting it supports multi-instance, and therefore the binding is not supporting endpoints. I’ve updated the binding to force this command class in the device to try and solve the device bug.
No idea - the binding hasn’t really changed in a way that would change this, so it’s either not new, or I would doubt it’s related to the binding - ie maybe there’s something else at play?
In searching through old logs, this looks like something that has been happening for a while after the binding starts, but then clears up when the system settles down. We need to get you >100 devices in your test environment! 
is looking very promissing!!!
there was one error during early when adding the thing:
2017-11-14 23:23:01.303 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 28: Endpoint 3 not found. Cannot set command classes.
but then, when trying to save Association Group (Input 1 = OpenHAB Controller):
2017-11-14 23:27:24.757 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Configuration update group_1 to [node_1_0]
2017-11-14 23:27:24.761 [ERROR] [ome.io.rest.core.thing.ThingResource] - Exception during HTTP PUT request for update config at ‘things/zwave:device:zw:node28/config’ for thing ‘zwave:device:zw:node28’: null
and looks like not getting over it 
The first problem is the device says it is only supporting 2 endpoints -:
From the log, either it’s incomplete, or it looks like the device isn’t completing initialisation. Maybe you can check if this device configuration etc is the same as the version that’s in the database?
I will at least try … well, at level of my knowledge.
As I “feel” it atm - the device may have have two binary switches (1&2) and four 1wire temp sensors. I have only switches connected. From what I recall reading - if u add/change the temp sensors you need to exclude the device re-include. Maybe it “adjusts” the number of available endpoints “on fly” - that’s where the discrepancy comes? Just guessing way outside of my comfort zone:)
For now, if you can just confirm the configuration values are the same - i.e. compare what’s in the database with what the manual shows for the firmware version you have (V2.1 I think I saw).
It may adjust the endpoints - not on the fly, but when it’s reincluded. I didn’t check this for now, but the log seems to show that the configuration didn’t complete (unless the log was not complete of course).
my assumption was that it’s full log. from moment the thing was discovered. I did try re-include it once again and got the same errors (though don’t have the second log at my fingertips right-away)
did it and is the same, from what I understand (found only operational manual, nothing more technical). There seems to be two names out there FGBS-321 (older, with fw version in website 1.2) and FGBS-001 (newer, with fw versions 2.1-2.3). Config parameters in user manuals seems the same for both. On some posts people refer to both being the same device, just strange naming.
Ok, thanks. Can you confirm that the device actually completed initialisation? The log seems to stop part way through - maybe it’s just an incomplete log and I’m looking in the wrong direction…
Forgetting the association issue you raised above, and the endpoint 3 error, do the other channels work?
I will do another try when get back home at evening and confirm/share the log
as I understand, I need to add the association to hab controller - with out that it won’t work. Same http error when trying to save the other two association groups.
Other channels - like the alarm instead of binary sensor? no, none of them working (I do not have any 1wire/temp sensors connected to it; using just the two binary inputs).
Yes, but the initialisation should do this automatically if everything is working correctly.
Can you make sure the next log also provides some examples of these messages. If possible, please try and be systematic about this part so that there’s some way for me to know which ones are from which sensor/input.
So, here is clean start fro moment when Node 31 discovered … adding it … getting “initialization complete” in the log
Node31.tz
checking association groups - they are empty (which, I guess, means initialization completed, but with errors). trying to save any - got http error.
When sensor triggers - no messages in log (I assume - it is because Association groups empty; at least - with 1024 versio of binding there were no msgs in log untill association groups got manually set and saved; then messages log msg showed up, but did not trigger the linked items)
Unfortunately this log also does not complete the initialisation - I don’t know why, but again it is stopping in the middle of initialisation and before the associations are configured.
This time the logging stops during the UPDATE_DATABASE phase and this phase does not complete
Are there any exceptions being logged in the console? Something must be stopping the initialisation, but there’s nothing showing in the log.
I will get one of these devices for testing to try and get this fixed.
at least it is consistent 
there was other user with same sensor and similar problem - I also pinged him to try it out/try to repeat/share the log.
exception in console - would it be var/log/syslog ?
ha, actually there is one NPE, right at that time 22:36
Nov 15 22:36:35 openHABianPi start.sh[17524]: Exception in thread “Thread-320” java.lang.NullPointerException
Nov 15 22:36:35 openHABianPi start.sh[17524]: at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
Nov 15 22:36:35 openHABianPi start.sh[17524]: at org.openhab.binding.zwave.internal.protocol.ZWaveEndpoint.getCommandClass(ZWaveEndpoint.java:79)
Nov 15 22:36:35 openHABianPi start.sh[17524]: at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.doStaticStages(ZWaveNodeInitStageAdvancer.java:703)
Nov 15 22:36:35 openHABianPi start.sh[17524]: at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.access$9(ZWaveNodeInitStageAdvancer.java:524)
Nov 15 22:36:35 openHABianPi start.sh[17524]: at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:199)
otherwise nothing suspicious. is it any good?
