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

Hmm. Strange. I stopped OH2, recopied the 2.2 binding over and now the error is gone. I had copied the one from post 1713 the first time. But maybe I had bad download or something.

But now that I’m back looking more into my OH2 setup etc, I noticed I can’t seem to control my lock. It shows secured in Habmin, but it does show a red x for listening. I went and manually used the lock to try and wake it up, but uncertain why I couldn’t control it. Habmin shows it online and secured.

lock

That is probably correct - battery devices typically don’t listen permanently.

So following up on my attempts along with @nolan_garrett - I’ve been successful using OpenZWave Control Panel in a docker container to get the job done.

  • @mhilbush - thanks for the input, it appears the creator of the image forgot to adjust for instructions on docker hub vs local testing he was likely doing to build it initially. I’ve been doing the same lately for some side projects. In my case mine was /dev/ACM0 too. It was fairly easy to get up and running, but the security part took a little more thought mapping in the options file.

So along with the same lines as Nolan’s instructions, the idea is to stop OH2, pull your stick, plug it into the host for the container (preferably one that can be brought within proximity to the device) - include using the OZWCP, then plug back into OH and startup. I can happily report I’ve now got the new secure node running alongside the rest of my setup with no fuss. I’m posting outside this thread (as it’s big enough!) and so as to hopefully not detract much from the core focus of folks who are successful here.

If you’re interested it’s been posted HERE

1 Like

@chris i’m trying to understand a few features to fully understand my zwave network. This thread + google searches didn’t really come up with any definate answers so i hope you can help me out with a quick explination.

I’m running your latest Oct snapshot of zwave binding. My Z-Wave Network Viewer looks like this within HABmin:

  1. What does it mean when a node is RED circled. eg. Node 12, 11, 27, 14, 28, 13, 15? The one thing i notice is that they are all battery devices.

  2. What do the red arrows indicate?? eg. Node 15 has a red arrow to Node 1 (Controller)

  3. When i select advanced settings for the Zwave Serial Controller. what does “Synchronize Network” do?
    image

To add to this, all of my THINGS are green check marked:

The red circle means the device is a battery device.

It means it’s a one way link.

It synchronises the network with the master controller - if you don’t have multiple controllers in your network it should do nothing.

Sorry - I’m not sure what you mean - or more to the point, why you mention this. Isn’t that normal and what you want? This means the devices are online - that must be good, right?

Thank you so much for the clarification. Are one way links bad or is that just a feature of the specific devices?

The last point about my THINGS green, just wanted to say there was no problems with any items as i assumed the red stuff meant problems. This was just an informational post.

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)