Z-wave (Schlage) Lock Support on OH1

I know this topic has been discussed multiple times in google groups but is there any update on this? For most part the answer has always been that this will be in OH2 and OH2 is just a few months away but that was also the same response back in February. It will be really good to have a more realistic timeline on this.

I did see some posts about someone having a working implementation but was never merged into the mainstream code.

The issue is also with the fact that MySQL persistence is broken in OH2 and Security Classes are not yet implemented and I am looking for both these features.

1 Like

I don’t think we’ve said that security classes will necessary be implemented in OH2. This is a complex issue given that the security classes aren’t documented. I suspect it will be implemented in OH2 at some point as it will be needed for ZWave+, but it’s not top priority.

MySQL works fine on OH2 - just use a version that’s a little old (older than 1.6.1) - before a startup synchronisation was added as this extension isn’t supported in OH2 and that means that all persistence services that were changed in OH1 to support this don’t work. This is being reverted I think…

@chris Good to know that there is an option to use mysql with OH2
Also, I was referring to your comment here. It does not commit to a OH2 release but it conveys a message where the development on the security command classes will be in OH2 and thus the availability.

Please see here here and here for previous postings on OH compatibility with Z-Wave locks.

I don’t intend to be bashful or rude but the information is too confusing. Looks like someone has a partially working code and then no updates on these with references to OH2.

I am willing to spend sometime towards the development of these features if I can be guided initially on setting up the dev environment. I do JAVA development using eclipse as a part of my job but it is on a windows platform. Not much of a Git or Maven user but I can learn quickly.

My point wasn’t that someone was committing to doing this in OH2, but more that I was suggesting not doing it in OH1! I’m well aware of the posts on locks…

Like anything in OH, this is a community supported package, so it needs someone to work on a feature. Some work was done, but I’ve not heard anything recently, and I have a suspicion that it would require significant work as I know OZW rewrote this as it had problems (and the problem version was the one OH security was based on). At some point, I might take a look at it, but at the moment there’s a few too many other things to look at (like getting the OH2 binding working, and sorting out the required features in ESH!).

If you want to work on it, then feel free, but be warned, it’s not simple. Many have tried (well, many have said they will try :smile:) and as you see, we don’t have this yet :frowning:

So, if you want to implement it, please go ahead. I’m happy to answer questions, but be prepared for a (very!) steep learning curve…

Or spending lots of money of course… hmm, and then having to contribute a obfuscated binary jar. Meh, that won’t even fly with the licensing. Summary, save your money and lose some hair and sleep.

Hi! Any news about imlementing LOCK/DOOR_LOCK command classes in the Z-Wave binding? I’ve recenlty bought a Z-Wave door lock VIS_ZM1702, installed it into the door, but discovered that unfortunately it can’t controlled via BASIC command class. It’s a big pity. I’m a java Senior Engineer and have some free time, maybe I can help with implementation?

Even without the full control, I am planning on putting one in as well. I am curious, do you get some functionality from z-wave still, for like locked/unlocked status, or does everything communicate through the secure channel?

Sorry, I have already demounted it back, and replaced temporarily with an old one.
But it’s written in the manual that you can see the status of the lock by the BASIC class.

Just throwing my hat into the ring of someone who would want Kwikset Lock zwave support. It was one of the first zwave devices I bought. Unfortunately well before I discovered this forum and found out it wasn’t supported.

Hi Chris -
It’s been awhile… but I finally squashed the last showstopper bugs in the security classes (don’t get me wrong, there are still other bugs I’m working on).

I’ve got the security command classes working to the point here where 1) the secure pairing process works consistently and 2) I can lock and unlock my kwikset lock via zwave successfully. I’m almost ready to have others test but… to pair securely, the controller has to be forced into include mode while its still running OH.

For my testing, I just hardcoded:
zConfigurationService.doAction(“binding/network”, “Include”);
but I assume there must be some OSGIish way to do this so we can trigger it via a UI?

I tried a couple of things via the OSGI prompt but got nowhere so I figured I would just ask

Thanks!
Dave

@dbadia thats excellent news. I have been working on getting your code changes merged witht the OH2 base since yours was from 1.6 or so. Can I try and test your code against my schlage lock? If its ok with you, can you confirm that your code is update on your git repo?

@dbadia also if the include is triggered from habmin/2 would it work?

Hi, you can force controller into inclusion mode from HABmin or HABmin2 (from z-wave binding configuration page).

@roher that sounds great… but I can’t find it
I am looking under Configuration tab -> bindings tab -> org.openhab.binding.zwave. I see properties on the right half of the screen but it only shows PORT, Heal Time, and Enable SUC Mode
This is with habmin 1.6

I am probably just missing the obvious… thanks!

@mganapa Yes, that would be great if you could test it against your schlage lock. My github is not up to date, let me update that as there are critical race condition fixes in my local repo.

Are you able to test with 1.6 or do you need to use OH2?

@dbadia can we do this in OH2. Your girhub is at 1.6 and OH1 is at 1.7.1 As @chris has mentioned it would be additional work to make it available in both 1.7.1 and 2 but my guess is a lot of folks will want it it OH1 since there Are a lot of bindings that need to be moved to OH2.

I have a Kwikset 910 TRL ZW SMT CP lock I can test it on. I’m using OH 1.7.1 so hopefully you will have that version to test/implement.

Again, this is a lot of work to get working. My recommendation is to focus on OH2, although there is still no version of OH2 zwave released which clearly doesn’t help…

Clearly it can never be retrospectively added to 1.7.1 since we are now working on 1.8 which will be the last version of OH1 (at least as per current planning). Since this is meant to be released quite soon (maybe next month?) I think it’s unlikely that the security classes will be implemented in OH1…

Just my thoughts - there’s a lot of work to get this implemented - it would be good to see if someone wants to pick it up…

@chris the zwave binding from 1.7.1/1.8 works with OH2. When you say take this over, do you mean making the zwave binding compliant with OH2 arch? @dbadia just mentioned that he has the security classes implemented for 1.6.
At this point I would proceed as below:

  1. Test multiple locks/manufacturers with the 1.6 version that @dbadia has written.
  2. Once basic functionalities are tested fine we can port it over to OH2 and proceed with further development.

@dbadia can you have your git repo updated so that i can start testing with 1.6?

Yes, it would be worth thinking about looking at the OH2 version before too long.

However, my main point is to make sure you’re using a recent version. As I said, it’s unlikely that we’ll get this into the last version of OH1 before it’s end of life. Therefore, we will need to port it across to the OH2 version which will hopefully be available soon - I just need to get some changes into ESH.

One of the problems we had before is that unfortunately Dave started to implement this at the same time I did a major refactor of the binding. As the versions diverged it’s quite a bit of work to get it ported. I’m just trying to avoid the same issue again since we are again in the same situation with a major rewrite of the binding compared to the current version.

One other point - you should note that the version implemented by Dave was a port of the OZW implementation which didn’t work well. OZW rewrote the classes - I’ve not looked at this in any detail, so I don’t know what the problem was with OZW, and I don’t know what they did to fix it, but I would suggest looking at what they did to ensure we don’t have similar issues in OH.