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

Just got this using

Exception in thread "Thread-380" java.util.ConcurrentModificationException
        at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
        at java.util.HashMap$ValueIterator.next(HashMap.java:1466)
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.doDynamicStages(ZWaveNodeInitStageAdvancer.java:1013)
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.access$10(ZWaveNodeInitStageAdvancer.java:1009)
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:203)

did a fresh&clean test with the 1724 version. uninstalled old binding and controller, restarted openhab. added binding, added controler thing (through PaperUI, somehow for this operation can’t understand HABmoin), run “empty” discovery from HABmin, then another one and included the FGBS001 binary sensor. linked binary channels and added association groups.
can see the _ack and _sof messages whenever the sensor triggers, but don’t see changes for linked item (where as when door sensor triggers then there is the _ack and _sof and an item change). Full log from binding install here:

I don’t know what the issue is with the FGBS001, but I don’t think so. What is the actual problem? Is it security related?

As I understood, it may be “multi-channel” related (got it from this post fibaro-universal-binary-sensor-very-confused as dan12345 suggested to me here: fibaro-fgbs001-binary-not-receiving-changes-over-zwave

The problem - Fibaro FGBS001 binary wired up and included in the network. Whenever it triggers, can see some ZWave message in the Debug mode but linked item does not change/do not receive the update. Or I’m doing smtg wrong with config:(

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) :frowning:

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_null

I 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.


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 :wink: . 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…

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