Alec,
Thanks for the confirmation. I, too, have one Kwikset and have been using the Vera/MIOS binding for proper OH support. This is good news.
Just have one more device that isn’t supported properly (GD00Z-4) in OH/openzwave. Stupid unsupported BARRIER CC.
@daemonalec Thanks for testing. My 2 kwikset locks have been working well for about a week now. Still have some stuff on my todo list but overall things are working well.
@mganapa @Nicholas_Waterton I think this is a good time for you to retest on your networks to see if things are still flaky with your other devices.
@gottsman
There’s been progress on the barrier class, see this thread
@chris My branch has fallen far behind 1.8 master and I’d like to bring it up to date. I submitted PR4073 which has some minor whitespace changes. Once that’s in I can get my branch up to date. Just want to avoid mixing whitespace and logical changes in the same commit.
Dave
@chris So I was looking at the OH1 thermostat database xml but nothing is jumping out at me. Where should I be looking to understand this better?
Hi Dave
As I said - I don’t think this is needed. Isn’t it the label the user sees that matters? I don’t think the enum name makes any difference - so long as the channel is set with the right name, what goes on under the hood doesn’t matter. Given the binding can’t easily have two sets of numbers for the same command class, we can only do this I think?
Also I’m going to try and copy your secure stuff over to the OH2 binding in the coming days. This is going to be a bit ‘fun’ when it comes to maintenance as we’ll have two versions and we’ll need to try and keep any changes updated in both 
.
I’ll take a look at the PR again - I’m not a fan of the large commits as it can be difficult to trace stuff, but given the IDE is formatting and there’s no control, we probably need to do it…
Cheers
Chris
If you wait a little longer for the OH2 merge then I might be able to submit a PR for it. I have re-merge my OH1 changes anyway because of the massive amount of whitespace changes so I’m going to create a new branch and try to squash the commits down to one.
Hi Dave
I can do if your planning changes, but this is all going to have to be manually copied over - we won’t be able to manage a PR for the OH2 stuff. If your planning significant changes then I can hold off though?
Chris
Ok not sure why this isn’t sinking in for me 
So if we use the channel to “override” the default alarm types for a particular door lock model, would those overridden values also appear in the events log?
Thanks for helping me understand this
Dave
Well, what appears in the events log now is not related to the command class. The event log logs the item that changes, and the value that it changes to - the value however is not the enum that is used in the command class - it’s normally either 0 or 255. So, the same is true in the OH2 binding.
From the 0/255, an item would normally use a translation/mapping to change this to read correctly for the respective alarm (open/closed, alarm/ok…). This is handled by selecting the correct channel - see here for the current list of channels that zwave supports. This list can easily be updated, and then we can set any alarm type to be associated with a particular channel…
Does that make sense? Or maybe I completely misunderstand what you’re trying to do in which case it might pay to reiterate this in case I’ve lost the plot 
. I think though that you just want to show the correct alarm label, and conditions for an alarm, even if it’s not what is set in the command class, and if so, this can easily be done without changing the code (and in fact it can’t be fixed by changing the command class).
I finally got the courage to try compiling the security testing branch and pairing my Danalock Circle, and I’m happy to report that everything initially worked as expected. I have automatic relocking enabled and although it doesn’t seem to send a message immediately when it relocks, openHAB picks up on it after 10-20 seconds. Further testing seems like some unlock/lock commands from openHAB are ignored though, not sure why. I will keep playing with it! It looks like the lock and openHAB isn’t always agreeing on the nonce. When this happens, the lock will send an update saying it is still locked and openHAB will flip the switch back instead of trying to unlock again.
Unlocking and locking is near instant when it works, it takes around 1 second from clicking the button to the lock reacting.
The rest of my z-wave network seems to behave as normal. Figuring out the initial state of all the devices felt a little slower than with the regular z-wave binding but I don’t know if that’s just because of all the extra debug logging.
Thanks for all your hard work! 
Have these changes been merged to openhab addons master on github? I’ve checked the 1.9.0 build on cloudbees and I can’t tell from the commits whether they have all been put in. I’m looking to add my Schlage Camelot Deadbolt but don’t have the motivation to set up an entire IDE to build the one binding.
Or am I wrong and it’s more than just the zwave binding that needs updating?
No - it’s not currently in the master branch.
@dbadia - I finally received the Z-Wave module for my lock, so ran some first tests today - gotta say there’s a lot of great work in here 
. I’ve managed to get it running in OH2 (kind-of!) and the porting wasn’t too bad. Currently it bombs out while doing the security handshake and I wouldn’t be surprised if I’ve missed something in the copy process from your OH1 branch, but it’s getting there…
Anyway, if you wanted to take a look, it’s in this branch. I’ve got a few other jobs to do before my partner gets home but will continue with this in a day or so…
Cheers
Chris
@chris That’s great! If you post your log file somewhere I can look at the error to see where the problem might be. I have a tool that will format the handshake process so it’s easier to see what’s going on.
Also, I have finished my “clean” diff of the security changes OH1, you can see them here.
It might be easier to see what’s changed with that as a reference.
Dave
Thanks Dave,
I’ve sent you an email with the log…
Cheers
Chris
Got it, thanks. Think I see the problem. Looks like ApplicationCommandMessageClass in your fork still needs to have my changes merged in from here
I think that will fix it.
Dave
Thanks for the feedback Dave. I’ll take a look at this over the weekend.
Cheers
Chris
Thanks Dave - that put me on the right track and after a couple of hours of jiggering around, all looks good I think .
Cheers
Chris
I’ve been having trouble getting an Aeotec Multisensor gen5 to connect successfully. It appears that it supports SECURITY extensions, but perhaps the updates to support the SECURITY extensions don’t work for other sensors? Help?
Here’s another data point, I was able to get this all built and working with my Schlage Camelot lock and it seems to work well. It did the secure pairing quickly the first try and i can lock & unlock my door every time with very little delay (1-2 s).
The rest of my devices (~50 of them) all seem to be working well.
The only issue I’m having is the User Codes don’t seem to be working, but I simply programmed the codes I need at the keypad and all is well.
Thanks for all your hard work.