Z-wave (Schlage) Lock Support on OH1

Setup, Configuration and Use Items & Sitemaps
, ,
101

Just wanted to update on my little project’s status.

After a bit of farting around, the rooted Wink hub setup is working fantastically. Took 2 days to get its current state which is that Openhab can lock & unlock the door as well as get status updates on all the lock settings. I’m now working on the code to be able to change these settings (alarm mode, etc).

One of my main motivations for going with OpenHab over simply a stock Wink setup was so I could get the door to automagically lock when I left my house and unlock when I was coming home using geofencing - this is something that the stock setup won’t do for security reasons. (Personally, I don’t care about potential security issues… I’m doing this for convenience… if someone wanted to break into my house they’d just throw a rock through my window.) That’s working fine, too, but still needs a bit of tweaking to get the timing right. For the curious, I implemented another user’s suggestion of my dd-wrt router polling for the Wifi connection of my and my wife’s cell phones… if both are not connected then the door locks… if one connects then it unlocks the door.

All of this is happening locally (i.e. not going up to the Wink cloud) which is significantly faster and more reliable than using Wink’s system.

Overall it’s been quite satisfying especially knowing that, with the Wink hub, I’ll be able to quickly and easily integrate Lutron switches (my next addition) into the system using the exact same method.

If anyone is interested, I can try to write up a bit more detail on what I did. I don’t want to hijack this thread with this, though, as I think getting the lock to work with the Z-Stick is a worthy endeavour as it will likely be slightly faster than my setup (the ssh connection to the wink hub to change the aprontest setting takes 1-3 seconds) and would be easier for those not interested in the hub rooting process.

102

@dbadia looks like you have a new commit. Should I test that out or should I wait till you have more updates?

103

@mganapa yeah, I pushed a few updates this morning. Hold off a little longer on testing though, I see at least one more problem I want to try to resolve here before you test again.

Also, been meaning to reply to your other post with the logs. I did find a bad bug where the controller was issuing double requests to the lock, then the lock would reply twice, and so on… until the controller and the lock became overwhelmed and then errors and weird things happen (as you saw). I let it run overnight to reproduce what you saw (I only have 2 nodes so it took a little longer, but I saw the same instability. So that’s good, if I can reproduce it, it’s much easier to fix :smile:

From what you posted, it looks like the original secure pairing failed, but the regular pairing stayed intact. Ideally, the zwave code would recognize this situation and unpair, but I haven’t figured out a way to do that yet. From what you and Bill have posted, it sounds like the green check mark will appear on the lock in either case. So from here on out, you should check your logs for “Secure Inclusion complete” or “Secure Inclusion FAILED” after you do the pair.

Anyway, I’ll let you know when it’s ready for more testing. Don’t want you wasting your time while I know there are still lingering issues I need to fix.

Thanks
Dave

104

I’m also trying to get my lock to work. It’s a Yale Real Living Touchscreen Deadbolt (with Zwave module).

I’m running Openhab 1.71 (could go to 1.8 if I need to). I have a bunch of Zwave stuff already, but thought I would give your binding a go.

Downloaded your latest commit (beta branch), an compiled it (I added my Yale lock to the database first).

Took about 6-7 goes, but got the secure inclusion to finally work (using Z-Stick Gen 5). Now I can lock and unlock (works quickly as well), it is a little sporadic, sometimes misses a lock/unlock, but not bad. Battery even reports correctly. Had some problems with my other Z-Wave devices, but mostly deleting the .xml files and re-initializing worked (Fibaro RGBQ LED controller was the worst, but got it to work). Aeon MS6 sensors (I have 4) are a little fiddly - had to continually wake them up to get them to respond, but got them there in the end.

On restarting Openhab, lock does not always connect properly. Sometimes the secure communications seems to fail - not too often though.

Status feedback does not work. The Yale seems to raise an ALARM when the lock status changes, with a value of 1 and a type depending on if it was a manual lock/unlock or Zwave lock/unlock. This is what I get in the log for a Z-Wave lock:

2015-11-10 13:18:20.668 [DEBUG] [ApplicationCommandMessageClass:135 ]- NODE 27: Incoming command class SECURITY (0x98)
2015-11-10 13:18:20.675 [DEBUG] [.p.c.ZWaveSecurityCommandClass:596 ]- NODE 27: MAC Authentication of packet verified OK
2015-11-10 13:18:20.675 [DEBUG] [.p.c.ZWaveSecurityCommandClass:617 ]- NODE 27: decrypted bytes 00 71 05 18 01
2015-11-10 13:18:20.677 [DEBUG] [ApplicationCommandMessageClass:135 ]- NODE 27: Incoming command class ALARM (0x71)
2015-11-10 13:18:20.678 [DEBUG] [ApplicationCommandMessageClass:95  ]- NODE 27: After decrypt, found Command Class ALARM, passing to handleApplicationCommandRequest
2015-11-10 13:18:20.678 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-10 13:18:20.679 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-10 13:18:20.681 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Auto Lock (24)

I added the Alarm type 24 “Auto Lock” to the code myself (so I could see what was happening - otherwise you get an “Unknown Alarm type” message.

The alarm types are:
22

105

OK hit the wrong button there…

Alarm types are:
22 Manual Unlock
21 Manual Lock
24 Auto Lock
25 Auto Unlock

It sometimes misses the Z-Wave Unlock command (but I am a long way from the controller in my testbed set up, so not too worried about that yet).

It would be really great if we could get this working for the upcoming 1.8 release (or after…). I’m not really a java programmer (c is my thing), but I’m willing to help.

Any idea what to do with the ALARM types to update the UI? I added the codes, but not sure where they hook into the UI.

Keep up the good work!

106

Update!

After much fiddling I have it fully working. The feedback from the lock works correctly - I just have to be patient, after the refresh period, the status does update as locked or unlocked.

Great news.

Please let me know when there is anew commit, as I would like to keep on top of this.

Thanks!

107

@Nicholas_Waterton thats promising. I have been holding off from further testing as per @dbadia and will wait till he has a more stable commit.
@dbadi let me know if you need my assistance in more than testing. I know i have mentioned this before but still feeling guilty about letting you deal with this on your own.

108

The rest of my ZWave items are still flakey with this binding. Aeon MS6 keep having to be woken up on a restart, and my Fibaro RGBW LED Controller stops working. Having a hard time getting everything to work at once.

The ALARM values the Yale lock sends are SENSOR_ALARMS, but so far no luck in intercepting them. It looks like they are passed on to Openhab, but I can’t capture them.

109

@Nicholas_Waterton thanks for testing. @mganapa saw some general flakiness with other nodes as well. I’m pretty sure the issues you are seeing with the non-secure nodes is just the controller being overwhelmed by the security requests (the code base you are running sends too many, which results in a lot of back and forth. Eventually it clears up, but it takes awhile, hence the delay in the lock status updating, devices appearing to be offline).

I haven’t pushed anything to github lately, but I have been busy on the 1.8 branch:

  • bit the bullet and did a lot of refactoring. It took up a couple hours but it should make the code easier to troubleshoot and maintain going forward.
  • wrote a log parser that makes it easier to visualize what’s going on with the security messages, failures, etc
  • added a gateway to help control the number of security messages and strip out duplicates. The goal being to stop the controller from being bogged down with too many security messages.

I haven’t pushed anything to github yet, as I have a few more changes to make and I want to test the code as much as I can here first.

@Nicholas_Waterton do you happen to have the logs from your failed secure inclusion attempts? Would like to see if there’s anything I can do to sure that up.

Good question, I’ll have to take a look. I have a Yale lock here that I’ve been meaning to try out. Thanks for posting the codes and the meanings

I’d like to. I’m not aware of a timeline for 1.8, but it we could at least get the basics working (and not interfering with other nodes) that would be great!

110

OK, some more update (and if you can let me know when you have a new update to try I’d appreciate it.

I have the ALARMS working. If you add:

        MLOCK(21, "Manual Lock"),
        MUNLOCK(22, "Manual UnLock"),
        ALOCK(24, "Auto Lock"),
        AUNLOCK(25, "Auto UnLock");

to ZWaveAlarmCommandClass.java in the enumerated list of supported alarm types, then you can catch the alarms in the items list like this:

Number Door_Status2a "Front door lock status ALARM Received [%d]" <lock> (gGF, Doors, Yale) {zwave="27:command=alarm"}
Number Door_Status2ag "Front door lock status General Alarm Received [%d]" <lock> (gGF, Doors, Yale) {zwave="27:command=alarm, alarm_type=0"}
Number Door_Status21a "Front door lock Manual Lock [%d]" <lock> (gGF, Doors, Yale) {zwave="27:command=alarm,alarm_type=21"}
Number Door_Status22a "Front door lock Manual UnLock [%d]" <lock> (gGF, Doors, Yale) {zwave="27:command=alarm,alarm_type=22"}
Number Door_Status24a "Front door lock Auto Lock [%d]" <lock> (gGF, Doors, Yale) {zwave="27:command=alarm,alarm_type=24"}
Number Door_Status25a "Front door lock Auto UnLock [%d]" <lock> (gGF, Doors, Yale) {zwave="27:command=alarm,alarm_type=25"}

You can use Contact, Switch or whatever. I did see an alarm type of 0 (General) once, not sure what that was for, and of course there may be other types of alarm I haven’t seen (tamper? lockout?). The alarms are in the form of a trigger - ie it sends a “1” (ON, CLOSED depending on item type), but doesn’t reset it. It’s easy enough to intercept this in a rule though.

If I don’t have the door lock status polling, the lock behaves oddly. when you switch the command=door_lock item, sometimes the lock locks, sometimes it unlocks (irrespective of if you send an ON or OFF). With polling on, it seems to work, but there are reams of network traffic, and it takes a while to update the lock status. Not sure why this is (the lock must know it’s own status right?

Anyway, the rest of my zwave items are in a dismal state, BASIC stuff works, but my Fibaro RGBW LED controller is hit and miss, sometimes it initializes OK, sometimes not (mostly not). My Aeon Multi Sensor 6 motion sensors keep dropping off the network, and one managed to use up all it’s battery (from 100%) overnight! The lock works every time now though…

I was using the latest 1.8 binding, and everything worked flawlessly with that. I may try it without the polling (which seems to do endless retries for some reason), see if it makes a difference.

I do have an Aeon Home Energy Monitor, which does generate quite a lot of traffic (updates every 5 seconds, if the house load changes), so that might be a factor also.

As to logs, I don’t have the ones from the failed inclusion attempts, I just kept at it until I got success (for some odd reason I did get a log of the successful inclusion, I think I just decided to keep a log of the Inclusion attempts for analysis, and then it worked!). The failed ones are probably in my zwave.zip logs (my zwave log is always on debug), but it would take a while to find them. You don’t seem to be able to post logs here anyway (unless you have some tips?).

For the database entry I added:

                <Product>
                        <Reference>
                                <Type>0002</Type>
                                <Id>0000</Id>
                        </Reference>
                        <Model>YRLD220</Model>
                        <Label lang="en">Touch Screen Deadbolt</Label>
                        <ConfigFile>yale/yrld220.xml</ConfigFile>
                </Product>

to products.xml in the Yale section, yrld220.xml is a copy of yrd210.xml as they seem to be the same, but I copied it in case there turn out to be differences.

Anyway, let me know when you have a new binding to try.

111

Some more info,

I managed to extract my logs, node 20 is (one of) the failed one(s) , node 27 is the successful one.

https://www.dropbox.com/sh/o3niantzw3gixvz/AACARFkYuEiKVbeuLk2LubgJa?dl=0

I also found this:

http://www.pepper1.net/zwavedb/uploads/resources/513c90984733a978c86885d00c0a99ef40dd8b72.pdf

Which explains all the alarms and commands. This will help me out testing.

112

I commited some more changes - I think this will help with the other nodes appearing as failed.

Couple other thoughts:

  • Status updates are still a bit slow, taking up to 20 seconds. Have a few ideas on how to make this faster in the future. I’ve also noticed that occasionally, the status doesn’t update at all. This appears to be a bug between the UI and zwave level, as doing a simple refresh of the UI shows the proper status
  • I’d suggest setting ,refresh_interval=43200 for battery and ,refresh_interval=120 for lock status. The battery level won’t change very often and doing so more frequently does nothing but drain the battery
  • As I mentioned before, there are a lot of changes here, but this code has been the most stable of all for me so far

Go ahead and give it try

Thanks
Dave

113

Thanks for the logs and the doc @Nicholas_Waterton, I’ll take a look

114

@dbadia I will try this out by tomorrow night. Thanks for the updates!

115

I have the lock working now (but will download the latest commit to compare).

I ended up adding this to ZwaveAlarmCommandClass.java to catch the alarms the lock sends. If this was 100% reliable, I wouldn’t need to poll the lock so often (as it sends an ALARM for every type of lock/unlock). but it’s only 80% reliable so far. Sometimes the response is instant, even with quick lock/unlock cycles, sometimes it never arrives. I haven’t been polling the battery, as it seems to send that from time to time, when there is activity.

          public enum AlarmType {
		GENERAL(0, "General"), 
		SMOKE(1, "Smoke"),
		CARBON_MONOXIDE(2, "Carbon Monoxide"), 
		CARBON_DIOXIDE(3, "Carbon Dioxide"), 
		HEAT(4, "Heat"),
		FLOOD(5, "Flood"),
		ACCESS_CONTROL(6, "Access Control"),
		BURGLAR(7, "Burglar"),
		POWER_MANAGEMENT(8, "Power Management"),
		SYSTEM(9, "System"),
		EMERGENCY(10, "Emergency"),
		COUNT(11, "Count"),
        ADDED(112, "User Added"),
        TAMPER(161, "Tamper Alarm"),
        MLOCK(21, "Manual Lock"),
        MUNLOCK(22, "Manual UnLock"),
        RFLOCK(24, "RF Lock"),
        RFUNLOCK(25, "RF UnLock"),
        PADLOCK(18, "Keypad Lock"),
        PADUNLOCK(19, "Keypad Unlock"),
        JAMMED(9, "Deadbolt Jammed"),
        BATTFAIL(169, "Battery Empty"),
        BATTCRIT(168, "Battery Critical"),
        BATTLOW(167, "Battery Low"),
        AUTORELOCK(27, "Auto relock"),
        DUPLICATE(113, "Duplicate PIN"),
        POWER(130, "Power Cycle"),
        DELETED(33, "User Deleted");
        
        /**
         * Yale Locks Alarms:
         * 112 (0x70) User added - value is user that had code changed or added. 0 is master code
         * 161 (0xA1) Tamper Alarm - Cable connecting front and rear disconnected (value 2) or keypad attempts exceeded (value 1)
         * 22 (0x16) Manual unlock - key or thumb turn (value 1)
         * 25 (0x19) RF unlock (value 1)
         * 21 (0x15) Manual Lock - key or thumb turn (value 1) by keypad touch - lock and leave (value 2)
         * 24 (0x18) RF lock (value 1)
         * 18 (0x12) Keypad lock - value is user number
         * 19 (0x13) Keypad unlock - value is user number
         * 9 (0x9) Deadbolt Jammed - value 0
         * 169 (0xA9) Low Battery Alarm - too low to operate (value 1)
         * 168 (0xA8) Low Battery Alarm - critical low battery (value 1)
         * 167 (0xA7) Low Battery Alarm - Low battery (value 1)
         * 27 (0x1B) Auto relock cycle completed (value 1)
         * 113 (0x71) Duplicate pin number entered (value is user)
         * 130 (0x82) Power Cycle (value 1) sent on battery power restored
         * 33 (0x21) User Deleted (value is user)
         */

should this not be in the device .xml file? can we add supported alarms to the xml? not sure of the format for the device .xml in the database. This seems to be the same for all Yale locks.

I have some complicated rules to deal with all this - but they work!

The rest of my zwave stuff is hit and miss. I actually have everything working right now, but when I restart…

I have to reinitialize the nodes when they stop responding (after a few hours) - then they pick up again. If we could solve this, then we would be well on the way. As I said everything is solid in the regular 1.8 binding, so it can work. As a minor thing, my Everspring Siren (SE812) does not report it’s battery level. This was a problem in 1.7.1 binding, and was somehow fixed in the later 1.8 bindings (as of a few weeks ago). I don’t know what was done, but there is something different about the battery reporting on this device.

Also, My Aeon Multi sensor 6 devices have been draining their batteries like crazy (also dropping off the network every few hours). I’m thinking that the lock is using them as routers, and thus draining the batteries. I have replaced all the batteries, and have a Zwave repeater arriving today. I’m hoping that will fix the problem.

I’ll download the latest commit right now, and see how it goes.

Thanks!

116

OK, so far no-go.

I tried the new binding (but forgot to add the lock to the database), so added it and tried again. Still no. Tried re-initializing the node. No. Took a deeper look, and see the message:

2015-11-13 11:40:09.010 [ERROR] [CommandClassWithInitialization:379 ]- NODE 27: Invalid state! secure inclusion has not completed and we are not in inclusion mode, aborting

Hmm - not good.

Went back to the old binding, restored my old node27.xml from backup - and good! all works as expected - had lost my association for alarms, so re added it. Alarms working OK.

went back to the new binding. Still no go.

This is the crucial problem I think:

2015-11-13 11:34:35.619 [INFO ] [rialApiGetInitDataMessageClass:57  ]- NODE 27: Node found
2015-11-13 11:34:35.741 [DEBUG] [b.z.i.protocol.ZWaveController:461 ]- NODE 27: Init node thread start
2015-11-13 11:34:35.781 [DEBUG] [.b.z.i.p.i.ZWaveNodeSerializer:138 ]- NODE 27: Serializing from file /var/lib/openhab/zwave/node27.xml
2015-11-13 11:34:35.817 [ERROR] [b.z.i.protocol.ZWaveController:475 ]- NODE 27: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.ConversionException: Cannot construct org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass : Cannot construct org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass

I have added the complete log from this to my dropbox logs folder. I will see if I can fix this in the meantime.

117

OK,

I did a cut and paste between the old node27.xml file and the new one (different order, but otherwise the same), made sure securePairingComplete true /securePairingComplete was correct (goes to false if you reinitialize the node), and Bingo! we are live again.

I’ll continue with testing and let you know the results.

118

I should say in the cut and paste operation, the new node27.xml file was missing the secure command classes - that is what I copied from the old one to the new.

in a quick 5 minutes of testing, everything is working! even the old zwave stuff is all responding (for now). Wait a few hours (or overnight though) and we’ll see. Lock is responding well, and fast. Alarms are instant, and remote lock/unlock are within a second or so.

Still waiting for my repeater, but Aeon MS6 sensors survived last night with the batteries intact.

Will update in a few hours.

119

Assuming you didn’t include the MS with USB power applied, it shouldn’t do this. Battery devices can’t be used as routers.

120

I would have though so too, but after changing the binding, and adding the lock, the battery levels started dropping like crazy. They were all added on battery. Habmin info reports “routing” as true (but then it says that for everything). I’ll check with habmin2 see if that says the same (probably, it’s the same xml file).

Having been at 100% for about 6 weeks (one for over two months), they were dropping 5% per hour. The oldest one hit zero overnight.

I replaced the batteries on the dead one, but it wouldn’t work. Tried several batteries - nothing - no lights or anything. Connected it to mains, and voila! life. Tried batteries again - nothing. So I hooked it up on mains power, removed and re added it to the zwave network, and now it happily reports all the time (also says battery 100%, but whatever).

Two others dropped to 25% so I replaced the batteries on those (didn’t want to leave them overnight again after the last one), The fourth was down to 79%, but then went back up to 89%, so I left that.

Today (after leaving them all night) they are the same as yesterday. So unless this is one of those things where they are at 100% until the last few days, when they drop like mad, we are still OK.

Could this be something to do with zwave beaming? they all claim to support beaming, and I don’t have much else that does. does zwave beaming work differently?

Right now the lock node has just gone dead, but I did change my lock polling to 300 (trying to avoid polling if I can), so maybe I should change my zwave:aliveCheckPeriod (currently at 360000). Lock still responds to commands though. Not sure how the node can be marked dead when it’s responding to polls/commands?

I’ll let you know how it goes later.