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

How often is the first one happening?

IIRC, I think I have seen it show up once every OH startup since updating the binding, and there is only one instance of the error when it has shown up. I really don’t recall seeing it before updating the binding, but I wouldn’t bet my life on it.

I don’t think it should be related to the update, but like you, I wouldn’t be my life on it :wink: . It’s a bit of a strange one as I can’t quite see how it can happen…

The other issue I’ve made a change so it would be interesting to see if it comes back. It probably doesn’t happen every time anyway…

is this supposed to fix the Fibaro FGBS001 issue as well?
Did try quickly and not seeing it working end2end. though new log item seems to fired when the fgbs001 activates (but maybe it’s just me).
20:38:48.270 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_serial_zstick_zwave_serial_sof changed from 339 to 340

will try to do another/clean test in few h.

Just got this using 2.2.0.201711131724:

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:
Node23.7z

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

@rgerrans

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.

image

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.

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.