Z-wave (Schlage) Lock Support on OH1

Setup, Configuration and Use Items & Sitemaps
, ,
21

I am using all 1.8 bindings with my 1.7.1 install. Since 1.6 was mentioned I thought that Dave was going to get it in the most recent 1.x binding that hasn’t been released, which is 1.8. I take it that the OH 2.0 z-wave binding is significantly different than the 1.8 that is in the oven, so I totally understand if it’s held back until the 2.0 release to reduce it to one stream of development code.

If there is any testing needed no matter what version I’ll do my best to contribute as best I can. Thanks to all for their efforts.

22

Yes, the OH2 binding is structured quite differently than OH1. Most of the protocol layers are similar though, so it can be ported from the version 1 binding, it’s just another step - not impossible, just more work…

23

@chris /all. The last few posts we all have been discussing the same thing and agreeing to it as well. But for the path forward I suggest

  1. Test and fix the pairing/lock & unlock functionality using 1.6
  2. No additional development on the 1.x code base.
  3. Move updates to 2.0 code base and release.
24

I agree - the only thing I would add is that you should have a quick revisit of the OZW code to ensure we avoid the issues they had…

25

@dbadia Can you please chime in? Also, I am still waiting for your git commit : :smiley:

26

@mganapa I need to update git with my latest changes, that code base has a major race condition and doesn’t work. I’m also in the process of writing up the testing instructions on the wiki as the pairing process is different for secure devices

@chris I will look at the OZW code again. I stopped looking at it awhile ago since it was a bit flaky. But I agree it’s worth a revisit if it’s more stable now to see if we can pick anything up.

@everyone
As for where to develop the code I’m going to stick with 1.6 for now since 1) it’s actually working and 2) I’m familiar with it. The flow of the security classes are more complex than the others (series of messages as opposed to request/response) I think it will be easier for me to continue down this path, get things stable, then port over to OH2. It is extra work, but it’s where I’m most comfortable at this point.

My final thought/concern is that if “real life” crops up again (like it has for the past few months), if I have something stable on 1.6 at least someone else can pick up where I left off.

Looking forward to working with the team, this is a really great project!

27

@dbadia Excellent. And yes I can pitch in. I have a steep learning curve more with the Z-Wave communication process than coding. I can work on it for a while but I am expecting a baby in Jan so I will be in the same boat as you and would like to have someone else take this up when no one can’t.

I really wish I can find those leaked documentations on Z-Wave communication protocols

28

Can someone explain to me how to put the controller into inclusion mode via habmin?

@roher mentioned it’s possible but I can’t find the option
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

Thanks!

I am probably just missing the obvious… thanks!

29

I have the include in my 1.7 I will see if I have the same issue on 1.6

30

@dbadia I am able to see include and exclude buttons on my 1.6.2 instance. However, my habmin version is 1.7.0 SNAPSHOT

31

@mganapa
Thanks for the screenshot, which tab is that under?

32

Pasted image1025×494 43.4 KB

This is from my 1.7.1 install but it is the same in 1.6.2.

33

@mganapa perfect,thanks!
will run a couple of tests using the include button there. Hope to have github updated something this evening

34

@dbadia I just cloned your git repo. I will try to test the code with the Schlage in the next few days. Thanks for the update!

35

Ok, the commits to my 1.6 branch are done. See this wiki page for what’s working, what’s not and how to test:

Note that I’ll be abandoning 1.6 and moving my dev work to the 1.7 branch in the near future. The 1.6 git commits got messed up because I pulled in some of Chris’ 1.7 changes along with it so I’m manually merging the code into my 1.7 branch.

Dave

36

@dbadia, I was wondering myself about this when I saw your git repo this evening. I wasn’t sure so I pulled them in. I will try to test tonight time permitting, worst case by tomorrow night CST.
I am using habmin 1.4 (latest release as of today). I will keep you posted.

37

@dbadia just a clarification are you planning to merge your code with 1.7 as opposed to 1.8 which is close to release?

38

@dbadia @chris I have the device show up on my habmin but I see the following in the log file:
NODE 2: No database entry: Manufacturer:59 [ID:5044,Type:6341]
I think the database for 1.6 needs to be updated to include my lock. This is a schlage BE469 Camelot lock. If one of you can point me in the right direction, I can do this myself.

39

Really, I would strongly discourage any work using 1.6. The codebase has evolved so much since then it would be a nightmare to re-integrate. It took me quite a lot of time to integrate it last time, and I don’t want to do it again…

You are probably better off using my codebase unless Dave has changed things a lot recently.

40

@chris like I mentioned above I just want to help test Dave’s code and from a release perspective looks like he is migrating his work to 1.7.
Again 1.6 is only for testing his efforts so far. Would that be an issue?