Z-wave (Schlage) Lock Support on OH1

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

@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!

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

@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.

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

@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.

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.

@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?

I spent a lot of time migrating Daves code to 1.7 after a major refactor (at Daves request) which is why I suggested using this as the starting point. The problem is that from 1.6 to 1.7 there were major changes in the binding that may take quite some time to port across - the more you do on 1.6, the bigger the problem will become and it would be better to start from 1.7.

@chris I am sorry I was not aware of this. So does that mean that these changes are also now a part of the 1.8 branch? @dbadia & @chris so which version can now be used to test the door lock feature. I don’t see the DoorLockCommandClass in any of the 1.7 branches.
Let me know if I can help with the code for this.

No - they weren’t merged to master as it wasn’t tested (I didn’t / can’t test it as I don’t have any devices). It is therefore still in the 1.7 codebase… 1.7 codebase is very similar to 1.8 though so it wouldn’t be a major issue to merge.

However, reading Daves message above, it looks like he might have merged my changes into his anyway, so this might all be sorted…

I just pulled his git source (1.6 branch) as per the instructions on the wiki. Guess what the version is when I compile and run the code 1.7? Now I am really confused. Too many versions in the mix. 6 is afraid of 7 because 7 8 9 :imp:

At what point did you see this? During inclusion? After inclusion? It’s been so long since I started this work I can’t remember if I had to add anything or not. Either way, see my thoughts below, I think we can fix this in the near future.

Regarding the branch questions and confusion… My 1.6 branch is actually closer to 1.7 (I’ll call it 1.6+) as in my git inexperience I merged some of Chris’ 1.7 changes into my fork that which caused 1) a nightmare merge for Chris and 2) a bunch of git commits that I can’t do anything with. The only reason I kept my 1.6+ branch is because it does work. Also worth mentioning the code that got merged by Chris wasn’t working consistently and I ended up refactoring a lot to get to my current 1.6+ which is very consistent.

I did to take your advice @chris and did a manual merge over to my 1.7 branch (still local, have pushed to remote yet). Once that works (think I’m pretty close), I’ll go to 1.8 (OH1 master) and continue the dev work there to see if there’s any way we can get this into the 1.8 release. It probably seems like I’m wasting time going from 1.6+ -> 1.7 -> 1.8 but at this point I’m most comfortable taking baby steps. and I hope it will go quick since, overall, the changes look pretty minimal.

Hopefully this explains enough to move forward :slight_smile:

*typo above: my 1.7 changes are still local, I haven’t pushed to remote yet…

@dbadia this seems to happen after the device is paired. Interestingly I messed the key step in your test procedure (sorry it was past midnight for me)

  1. I did not set a network key in my openHAB.cfg
  2. I did not see any messages during inclusion as described in your test procedure.
  3. However, the device showed up in my habmin with a green dot (active node). Previously, When I included the device in my 1.7.0 instance habmin showed it with a red dot.
  4. The only messages I could find for node 2 was the statement “could not find device in the device database”. My zwave logging is set to trace level.

I will be testing again today and I will make sure that I don’t skip any step.

Should I be testing your 1.7 branch this time?

@mganapa
no worries about the missed steps, it happens
unfortunately, I don’t know anything about the red dot vs green dot in habmin. But I can say that since the network key wasn’t set, there’s no way the secure pairing took place.

Keep testing with my 1.6+ branch for now, my 1.7 changes are still local at the moment. The code is all very similar so any findings in 1.6+ I’ll just fix in 1.7 or master and we’ll continue testing there

Happy testing
Dave

@dbadia and @chris good news. Locking and Unlocking works with my schlage BE469 Chamelot locks.
Followed the testing procedure to the ‘T’ and below are the observations

  1. Pairing was successful
  2. Lock and unlock actions work
  3. Battery status is possibly working. Possibly because it first showed 96% and then changed to 97%. Not sure if this is a rounding off issue somewhere or if it is temperamental.
  4. Lock status does not reflect in the contact item. I believe this is expected. However, the item is defined with refresh_interval of 10 seconds but the log shows 0 seconds. No command class found for item = Door_Basic, command class name = sensor_binary, using 0 refresh interval.
  5. There is a consistent error from the zwave binding [ERROR] [b.z.i.protocol.ZWaveController:643 ]- handleApplicationCommandRequest
    You can find all the logs and relevant screenshots [here][1]
    Inclusion process starts at line 42630 of the zwave-door.log. Since I am using the same controller all my other nodes are logged as well. Sorry for the mess in there. Let me know if you need me to trim those out and I will do that first thing tomorrow.

Great work Dave! You deserve more than a few beers :smile:
[1]: https://drive.google.com/folderview?id=0B6KlY2RKD0tMbzdLUXNMbzl1WWc&usp=sharing

@mganapa that is great news! I’ll look through the logs to see about the battery status change. Lock status isn’t working for me either, but the log you posted is an important clue, sounds like I might need to add a new command class to get that to work.

There is at least one major hack in the code I need to fix, but I think I know how to approach that now.

No worries about the other nodes in the log, it’s a good test to have other node activity at the same time to try to flush out any bugs (although the security logic is specific to the node so it should be ok…)

@chris I looked at the latest refactoring that the OZW guys did. Looks like they fixed some issues that I already had here and moved a lot of the crypto logic into their Driver object (which I believe maps to our Controller). Personally I’d rather keep as much of the crypto stuff in the security class and keep the Controller as is

I’m porting my changes over to OH1 master. From what I’ve learned about git, it will be much easier for me to branch off of that in order to keep my commits clean and mergeable. Hope to have it ready for testing in the next few days

@mganapa Thanks for posting all of your logs. Looked through them, overall things look good. Here are my thoughts:

  1. Logs look good

  2. Logs look good

  3. Battery status - Looks like the 96%, then 97% is just what the lock sent:
    NODE 22: Battery report value = 96
    NODE 22: Battery report value = 97
    so I think we’re good on that one

  4. Yes, this is expected since I couldn’t get it to work either. Not sure why, as BASIC should report the status. Maybe others can help out here as I don’t have much experience configuring the items. Perhaps we just need to modify this line in some way to get it work:

    command=sensor_binary,refresh_interval=10

  5. It’s safe to ignore [ERROR] [b.z.i.protocol.ZWaveController:643 ]- handleApplicationCommandRequest since this was just leftover debug code I had added. I’ll likely remove it in the next build

I’ve moved my development work over to OH1 master. You’ll see I’ve updated the testing instructions to use the security-beta-test branch from my git clone. I’m hoping that, with some more progress, we could get these changes included in OH 1.8. Think we’re off to a good start!

Hello Dave,
I found out that the schlage lock supports the following command classes.
Secure Classes:

  • ANTITHEFT_V2
  • ASSOCIATION
  • BASIC
  • BATTERY
  • CONFIGURATION
  • DOOR_LOCK_V2
  • ALARM_V2
  • USER_CODE

Non-Secure:

  • APPLICATION_STATUS
  • MANUFACTURER_SPECIFIC
  • FIRMWARE_UPDATE_MD
  • SECURITY
  • VERSION_V2

I don’t see sensor_binary in this list. I would really like to have some info on the various z-wave command classes and their operations. I know this is proprietary but I have see some references to leaks I wonder where these leaks are :smile:

How can I contribute more towards this?