From what I can tell in your log, the device is not a zwave plus device, so doesn’t support lifeline, so the binding is not using the multichannel association. Basically, it’s working the same as before for this sort of device.
ok, I see and have to agree - latest fixes has not changed behavior of FGBS001 (which is not ZWave plus). It is still doing the same = not working properly (as originally reported by @dan12345 here) 
I identified some further changes which I’ll add tonight - we can see if that helps…
1 Like
I had 10 of these NPEs in Karaf this morning. Related to this, I have a lock and a garage door opener that are marked as not using security (it did not come up after the last few restarts). I had deleted XMLs a few days ago to get the latest database definitions, and they have never completed initialization. They seem to have lost most of their neighbors too. Replacing batteries in the locks did not help. Another lock is also marked as not using security, but it has at least created an XML but hasn’t completed initialization (and 44 neighbors). I expect that it will come up properly after a restart. I have another lock and garage door opener that had their XMLs deleted too, but are working and have completed initialization. Also, I have two dimmers, a motion sensor, and a door sensor that are currently stuck in Update Neighbors (manual wakeups did not get them moving). Definitely something weird going on with my network ATM!
Anyhow, this exception wasn’t caught by the binding…
java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.chooseProvider(Cipher.java:893)
at javax.crypto.Cipher.init(Cipher.java:1249)
at javax.crypto.Cipher.init(Cipher.java:1186)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.generateMAC(ZWaveSecurityCommandClass.java:518)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageDecapsulation(ZWaveSecurityCommandClass.java:302)
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1150)
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:421)@chris I wanted to throw out a suggestion for lock user codes as you continue to work through the binding refactoring. I’ve been experimenting a bit with HomeSeer lately and what they do is pull the user code value and send them out on the alarm channel by adding a 5xx to the start of them. So I get a first alarm message telling me that the door was unlocked with a user code and then immediately afterwards a 5xx message giving me the user code which was used. That made it pretty easy to filter out the user codes using a regex but just as easily could have set a trap to grab them following the unlocked by user message. They take a similar approach for new user codes added / user codes removed reporting (using 6xx and 7xx respectively) so not sure how they deal with if your device issues more than 99 user codes (maybe they add a digit 5xxx to those devices).
If you look here at the lock rule done by 5iver, you can see this is being done where you can determine which lock code was used to open the door/lock. I would think maybe a similar rule to could be used to monitor for a new user code added or deleted?
Currently, I am getting Notifications on my phone when my door is unlocked and by who based upon the user code. Works pretty well.
I’m not sure I undertand what is different with your suggestion compared to what is currently implemented? If the channels are configured for each device, then there is a lock channel to provide the state of the lock, and an alarm channel that provides all the information available, including the user codes. You should be able to use a regex to process this if that’s your weapon of choice, or you can process it as a json object and I think @5iver has published some rules to show this.
Maybe I miss something about your suggestion (sorry if so)?
Just trying to make it easier for the next round of less technical users when you move this to stable. I have a similar setup to parse the json files for the raw channel but always assumed that was a temp fix until you figured out another way to handle it to make it simpler. So just sharing how HomeSeer is doing it to give you options as you think through it.
I see this in the log for every device after a restart of the binding. I assume it has to do with the association/lifeline changes, but node_1_null looks odd and might be why Habmin shows all associations as just an X.
2017-11-14 10:38:45.114 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 224: Update ASSOCIATION group_org.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup@6c07f87f: Adding node_1_nullI would prefer that there were attributes attached to a state, so we could directly provide multiple bits of information in a single state. Unfortunately, this is not the way ESH works, and I don’t really like providing different bits of information in multiple items as then someone has to correlate all these different parts, and that is not very simple to do reliably.
https://www.eclipse.org/forums/index.php/m/1759688/#msg_1759688
Until there’s a more coherent way of approaching this in ESH I think what we have is fine.
I’ve made a change to try and resolve this.
Please try the latest version and let’s see if it helps.
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! 