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

No - not in their own right. In an RF environment, especially in the home where there are lots of noise sources, walls, multipath issues etc, it will definitely happen…

However, clearly if a device has no route through to another device, then it’s a problem.

As an example, node 29 has a one way link to node 1. This means node 1 can receive node 29, but node 29 doesn’t directly receive node 1. However, nodes 18, 19 and 26 can all act as repeaters - ie there are green lines (bi-directional links) linking node 29 and node 1 through these 3 devices, so this is a good link as the controller has 3 options for routes to node 29.

Ok, understood now :slight_smile: .

Thank you - This makes a lot more sense and is logical now.
I guess things updated from my previous post as the mesh looks much better now. I just never seen all that red before and was confused.

Ok, so kinda strange. I know in the past I was able to control my lock, but had let my time with OH2 slip and now back looking at everything, upgraded OH2 and the Binding here to the latest, even removed my lock from HabMin and re-added it.

However, Habmin is not reporting the either door status or battery level, yet everything seems correct in Habmin and not seeing any issues. Habmin even says it did it a heal on the lock device this morning. Its been over a day without any door or battery status.

And the batteries in the lock are fresh new batteries. I can manually enter lock codes to lock and unlock the door.

Lock shows healed as of 2:55 am this morning.
lock

The batteries in the lock may have been previously dead for a week or more. Is it possibly I actually need to unpair and repair the lock to the controller?

That’s fine - this has nothing to do with the operation of the lock, and nothing to do with command classes or security.

Maybe the key has changed or something? What happens if you stop the binding, delete the XML and restart the binding?

Also, what do the logs show is happening if you use the viewer?

Fixed.

I stopped OH2, confirmed the secure key was correct, deleted the xml file, and restarted and rescanned the device.

Took a few minutes for OH2 to see it and wake up the device, but now working again.

On a side note. Is there anyway of knowing who unlocks the door based on their user code? Or any rules created that tells when the door was unlocked or locked?

Yes, and Yes…

Good morning!
@chris - in the device database, will it matter if the alarm command class is marked as Sec as opposed to only UnSec as long as the Device is securely included ? Or will alarm command class data be sent unencrypted if only UnSec is marked?

No. This setting in the database does nothing. It’s really just there for information.

The binding will use security if the device needs it. The device will list the command classes it wants securing and the binding gets this info directly from the device - not the database.

1 Like

I’ve just made a new version of the binding available (same link as before).

This changes a few things, so please let me know if there’s any issues.

The main thing this adds is a new stage in the device initialisation to handle the ZWavePlus Lifeline association group automatically. The binding will automatically set this to report to the binding, even if it’s not set in the database. It also will remove other devices from the lifeline group to ensure that it’s set to report to the binding. It will also use the multichannel association if there are multiple endpoints and the normal association group if there’s no endpoints other than the root.

The above was implemented to try and resolve issues with devices that are now starting to use a new concept that ZWave has defined. Many devices seem to be buggy in this respect so it’s not been the easiest to get working, and will likely still have issues with some devices (namely, older V1 Qubino devices seem to have issues still).

Any problems, just shout :wink:

2 Likes

I haven’t seen any new issues so far. Still get these though, when saving an association, healing, etc…

2017-11-12 13:33:28.982 [ERROR] [marthome.io.rest.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:07cb40a2:node8/config' for thing 'zwave:device:07cb40a2:node8': null

I was hoping the latest ESH update included in the snapshot build (I’m on 1078) would have the extra logging, but ESH PR 4403 is still open.

Thanks for the feedback @5iver. Yes, I’ve not updated the logging for the REST exception. I’ll try and do that in the next few days but I’ve been working to get the major updates to the ZigBee binding done so I can get a consolidated update released…

@chris thank you, Chris, for your effort.

However, I have installed the latest update of the binding, and noticed that manual changes(example unlocking the Yale deadbolt by hand get updated in UI) Have you noticed that or is it just glitch on my side?
Cheers
Roshan

Can you provide a log so we can see where the issue is - or at least I’d suggest to look at the log yourself in the first instance. Probably it’s not the binding, although if this is a ZWave plus lock it might be (but I don’t think any Yale locks are ZW+ at the moment so I don’t think it will be this).

I haven’t seen NPEs in Karaf for a while, but these popped up (OH snapshot 1078, zwave 2.2.0.201711121803)

Exception in thread "Timer-113" java.lang.NullPointerException
        at org.openhab.binding.zwave.internal.protocol.ZWaveNode$WakeupTimerTask.run(ZWaveNode.java:1417)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)
Exception in thread "Thread-215" 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)

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