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

Tags: #<Tag:0x00007f43488d34d8> #<Tag:0x00007f43488d33e8>

No, I didn’t. The comments aren’t something I normally look very often.

It’s the standard “problem” with ZWave - it provides many different ways of doing things and the database needs to be trimmed down to try and provide one way that works…

I’ve added more error checking into the database now so duplicate channels will raise an error.

Thanks for confirming and also providing the info earlier :slight_smile:

If they are working, then you probably don’t need to, but to keep everything consistent, I would recommend it.

1 Like

I can also confirm, that this is the same issue that I reported on Jul 26 and that it is now working.


Remember to update the date of build at the top of this thread. It is still dated 23rd Aug. It would be great with at buiild number or date on the jar file.


1 Like


Good point - thanks.

I just use the standard for OH2, so they are always the same name for snapshots. You can find the dates in Karaf though.

Just for the record: I think it’s very good that it always has the same file name, makes it easy to just fetch the file straight into the addons folder, overwriting the old version. Different file names would increase the risk of users screwing up by running multiple versions. Guess that won’t be a problem much longer though :slight_smile:

1 Like

Glad it got solved. Why it could be added as thing with those channels once but not readded once deleted is unclear for me… But hey… It works :slight_smile:


Here is a script for installing/upgrading the dev binding…

1 Like


When will you consider merging into the daily snapshots? I ordered Qubino Devices and from what I read they most likely will only work with this new version of the Z Wave Binding. But I’m not sure if i should use it for a productive installation :smiley:

Probably in 1 week time. I am away this weekend, so will probably do this late next week.

See also this thread -:

You can, and you should start asap i.e. by following the manual install instruction at the top of the thread.
You should be done with this and all the follow-up work (such as to delete/recreate your things) by the time you need it when your devices arrive.
I guess there might be quite a number of people to raise questions, to need help, or to complain (cause they didn’t read the announcement …) once chris puts this to out to the public (@chris hope there won’t but be prepared).

I still have not been able to securely include my BE469 lock. Can anyone suggest another free program (Linux or Windows) that I could use to try securely including this device, and then copy the security key over to openhab?

You cannot/mustn’t copy the lock’s security code (or any other FWIW). Read the beginning of this thread about the secure inclusion process. You can set (or read) the controller’s security key using habmin or PaperUI.

And see a couple of posts up in this thread: some locks (older ones, for the most part) require the controller to be really close to the lock for this to work, and “really close” means less than 3 meters.

This is correct, but if you know the key already, then you can securely include using different software. So, if you use different software, set the key and include, then set the same key in openHAB, and you can use the device just fine.

Yes, I mean the security key for the controller. There isn’t one for the lock itself, is there?. I see where it is in habmin (for copying it to/from the other software). I just wanted to mention it because I know some other tools do not make it easy for the user to access or change that security key.

I have tried inclusion with the lock at various ranges from 0.1 to 1.5 meters.
I have secure inclusion enabled for all devices in order to attempt this (although I did try security devices only once).
I have tried low-power, high-power, and network-wide inclusion.
I start the inclusion process in habmin, and it reports inclusion started.
I put the lock into inclusion mode, and immediately openhab reports inclusion successful (not secure inclusion) and I get a new thing (without “using security”), but the inclusion process continues until it times out. At that point, the lock shows an ‘X’ to report failure, and habmin reports “Secure inclusion failed”

I then exclude the device before attempting again with a different configuration.

@peter_oh can you remind me of the problem we had with your system? I have a vague recollection that the only thing I could see in logs we looked at was other traffic going on at the same time? Is that correct, or am I imagining that? (I can’t find the previous conversation that I think I remember :sunglasses:).

The entire exchange was here, posts 3073-3079. In the last response you said the device just doesn’t seem to be responding to the security messages. I’ll grab a new log of my latest attempt in case that helps.

Here’s a log from version
It starts with me excluding node 40, a previous attempt for this lock, and continues with node 41 being included, but not securely, with the user experience as I described:

I put the lock into inclusion mode, and immediately openhab reports inclusion successful (not secure inclusion) and I get a new thing (without “using security”), but the inclusion process continues until it times out. At that point, the lock shows an ‘X’ to report failure, and habmin reports “Secure inclusion failed”

Is that timeline (immediate inclusion of a non-secure version of the Thing) appropriate for secure inclusion, or has it already gone wrong by that point?

If it was successfully excluded, and the exclusion resets the device (which is normal, but not guaranteed on every device) then it should be fine.

I have one of these devices (BE469) here which I bought for initial testing when developing the secure protocols and it should be ok once excluded.

I went through this same pain. My lock was close to 10 cm away from my z-stick controller. The trick was to bring it so close, they touched during inclusion.

1 Like

For most devices, this is not necessary, and not recommended. For the devices I’ve tested, including the BE469 that I have, it was certainly not necessary.

Maybe there are some old devices out there that still need this, but it should be the exception rather than the rule (still worth keeping in mind if things don’t work :wink: ).

Yes, I understand. I just wanted to emphasize that you may think you are close enough to the controller, but you may not be. Over 20 tries at 20cm did not work. The first try at 1cm worked. FWIW, my other same model lock securely included at a distance of ~ 1m.