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 
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 
*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)
- I did not set a network key in my openHAB.cfg
- I did not see any messages during inclusion as described in your test procedure.
- 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.
- 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
- Pairing was successful
- Lock and unlock actions work
- 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.
- 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. - 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 
[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:
-
Logs look good
-
Logs look good
-
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 -
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
-
Itās safe to ignore
[ERROR] [b.z.i.protocol.ZWaveController:643 ]- handleApplicationCommandRequestsince 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
How can I contribute more towards this?
I am also available to assist. I have three wireless locks (Kwikset 910, 912). I could provide any data youād like.
@chris and @dbadia so is using command=BASIC vs command=SENSOR_BINARY, respond_to_basic=true the same? I thought these were different. Maybe I can try another test on the lock with the item defined as
Contact Door_Basic "Front door sensor" (GF_Office) {zwave="#:command=BASIC,refresh_interval=10"}No - itās not the same.
command=BASICwill only respond to the BASIC command classcommand=SENSOR_BINARY, respond_to_basic=truewill respond to both SENSOR_BINARY and BASIC
Depending on the device, the result may be the same, but if the device sends responses using the SENSOR_BINARY class, then the first one wonāt work.
@chris so as per the command classes supported for my lock, I should not expect SENSOR_BINARY to work but use BASIC instead? I just want to see what the response of the lock is in relation to the status of the lock.
Since it looks like the lock doesnāt support SENSOR_BINARY, I guess you shouldnāt expect it to work
@chris Yes, I believe the status is within the DOOR_LOCK CC but I would rather poke and probe than twiddle my thumbs 
@mganapa I was actually playing with this earlier today. Iāve updated the wiki to show the following which is working a little better in terms of showing status.
Switch Door_Lock āDoor Lockā (GF_Office) {zwave=ā3:command=door_lockā}
Contact Door_Basic āFront door lockā (GF_Office) {zwave=ā3:command=door_lock,refresh_interval=20ā}
Number Door_Corridor_Battery āDoor lock battery level [%d %%]ā (GF_Office) { zwave=ā3:command=batteryā }
I also made some code fixes to my 1.8 testing branch to get this working.
BUTā¦ for me at least, the icons are backwards. I see the lock with the red X when door is locked, and the lock with the green checkmark when the door is unlocked.
So Iām wondering if this is:
- The way all locks report status OR
- Some anomaly with kwikset locks OR
- Some anomaly with the kwickset 910 lock OR
- A combination of 1, 2, or 3 above with the direction the lock faces (left opening door vs right opening door).
So if anyone could help with testing to gather some more data. Please use the code and configs from the wiki at Home Ā· openhab/openhab1-addons Wiki Ā· GitHub
Then test to see if the status gets updated. Note that it takes about 20 seconds for the status to update on the OH UI and the events.log file. Try sending a lock/unlock request via OH and also just walking up to the door and manually turning the lever.
I donāt need to see log files or anything, just looking for a generic report of āitās backwards for me tooā or āthe icons are working for meā and which side of the door your lock is mounted on when looking at it from the inside. My kwikset 910 is mounted on the left.
Thanks!
Dave
@dbadia Here are my results
- The door does not lock or unlock with every request. The attempts to do so are successful sporadically. Thid was not the case with the 1.6 branch where every attempt to lock or unlock was successful.
- Battery level is no longer displayed. I just get a -.
- The lockstatus per icon is reversed. The display string also says open when lock is closed and vice-versa. My lock is mounted on the right (facing door from inside the house).
- The log states that product not found in database. I did not see any error in the log for 1 and 2 above. But then its 2 in the morning so I will have to examine the logs in detail tomorrow. Attached is the screenshot of my sitemap when the door was unlocked. .
