Z-wave (Schlage) Lock Support on OH1

Setup, Configuration and Use Items & Sitemaps
, ,
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.

121

Did have things working, the other zwave nodes are better (MS6 stays on the network!).

Lock node keeps going dead (have my repeater in now too). Then it “rises from the DEAD” (funny!), then all sorts of messages not being sent because the node is dead (which it really isn’t).

So working - then dies, working then dies.

lots and lots of these messages:

2015-11-13 19:07:56.247 [DEBUG] [urityEncapsulatedSerialMessage:63  ]- NODE 27: securityTransactionComplete=false, payload=(1B 02 62 02 ), transmitted=true, msSinceTransmitted=2487
2015-11-13 19:07:56.248 [DEBUG] [urityEncapsulatedSerialMessage:63  ]- NODE 27: securityTransactionComplete=false, payload=(1B 02 62 02 ), transmitted=true, msSinceTransmitted=2488

Lots and lots of these (which usually can be ignored):

2015-11-13 19:08:01.740 [DEBUG] [ApplicationCommandMessageClass:117 ]- NODE 27: Transaction not completed: node address inconsistent.  lastSent=255, incoming={}

I assume {} is a bug - should be something?

I’ll keep at it.

122

It’s been working for a few hours now, but everything seems really slow. Not just the lock, regular zwave stuff takes a long time to respond (5-10 seconds which is a long time for a light switch), The lock responds, eventually, but it can be 20-30 seconds or more (much more).

lots of these messages in the log:

=REQUESTED  expired=false  getTimeLeft=10997]
2015-11-13 21:16:34.714 [DEBUG] [.i.p.c.ZWaveSecureNonceTracker:103 ]- NODE 27: already waiting for nonce
2015-11-13 21:16:35.714 [DEBUG] [.i.p.c.ZWaveSecureNonceTracker:81  ]- NODE 27: getUseableDeviceNonce() lastDeviceNonce=
2015-11-13 21:16:35.714 [DEBUG] [.i.p.c.ZWaveSecureNonceTracker:92  ]- NODE 27: getUseableDeviceNonce() requestNonceTimer=NonceTimer [type=REQUESTED  expired=false  getTimeLeft=9997]
2015-11-13 21:16:35.714 [DEBUG] [.i.p.c.ZWaveSecureNonceTracker:103 ]- NODE 27: already waiting for nonce
2015-11-13 21:16:36.714 [DEBUG] [.i.p.c.ZWaveSecureNonceTracker:81  ]- NODE 27: getUseableDeviceNonce() lastDeviceNonce=
2015-11-13 21:16:36.714 [DEBUG] [.i.p.c.ZWaveSecureNonceTracker:92  ]- NODE 27: getUseableDeviceNonce() requestNonceTimer=NonceTimer [type=REQUESTED  expired=false  getTimeLeft=8997]

Regards,

123

Update,

After an interesting night configuring zwave devices, this morning all seems to be working well.

Last night odd things were happening. Took forever to add a new MS6 (to replace the one that will not work on batteries anymore). Had to keep waking it up to try to get configuration to complete. The new zwave binding seems to take a long time to get the device configuration - kept failing with “Static configurations not complete” - then it would start all over again on the next wake up.

Fibaro LED controller responded very slowly (i think it was downloading configurations again) - then suddenly started working normally! One of the devices that always previously worked started acting oddly. It’s a MIMO I/O module (mains powered) which switches my extractor fan light on and off. When switched the light switched on and off rapidly 10 times or so, then stopped in a random state. Looking at the log, I can see that the node was “DEAD” (it’s not), and so the switch command was sent several times with no “ACK”. Feedback always worked though, and quickly. Today - back to working normally.

As to the lock, last night, responding very slowly, or sometimes fast. feedback (alarms coming in mostly) working sporadically. Today - working well. usually takes 4 seconds to lock/unlock, feedback instant. The occasional ALARM does not show up (so the state is captured by polling, set to 120 seconds). about 85% on receiving alarms, even when they come quickly (ie unlock - exit relock in the space of 2-5 seconds works).

Here is the “Alarm” log since last night for example:

2015-11-13 23:04:30.133 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-13 23:04:30.133 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 0
2015-11-13 23:04:30.133 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = General (0)
2015-11-13 23:04:30.133 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@2d86fde3
2015-11-13 23:06:31.409 [DEBUG] [.z.internal.ZWaveActiveBinding:193 ]- NODE 27: Polling list: item Door_Status_Alarm is not completed initialisation
2015-11-13 23:06:33.634 [DEBUG] [.z.internal.ZWaveActiveBinding:193 ]- NODE 27: Polling list: item Door_Status_Alarm is not completed initialisation
2015-11-13 23:08:23.851 [DEBUG] [.z.internal.ZWaveActiveBinding:193 ]- NODE 27: Polling list: item Door_Status_Alarm is not completed initialisation
2015-11-13 23:19:00.998 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-13 23:19:00.998 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-13 23:19:00.999 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF UnLock (25)
2015-11-13 23:19:00.999 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@4abad873
2015-11-13 23:35:41.575 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-13 23:35:41.575 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-13 23:35:41.576 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF Lock (24)
2015-11-13 23:35:41.576 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@6447138f
2015-11-13 23:36:21.577 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-13 23:36:21.577 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-13 23:36:21.577 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Manual UnLock (22)
2015-11-13 23:36:21.577 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@5a40c712
2015-11-13 23:41:27.002 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-13 23:41:27.002 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-13 23:41:27.002 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF Lock (24)
2015-11-13 23:41:27.002 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@415552de
2015-11-14 00:54:57.906 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 00:54:57.906 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 00:54:57.906 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF UnLock (25)
2015-11-14 00:54:57.906 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@1d966f95
2015-11-14 01:00:04.397 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 01:00:04.397 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 01:00:04.397 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF Lock (24)
2015-11-14 01:00:04.397 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@5161dd28
2015-11-14 01:03:59.054 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 01:03:59.054 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 01:03:59.054 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF UnLock (25)
2015-11-14 01:03:59.054 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@6a93edf
2015-11-14 01:04:53.857 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 01:04:53.857 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 01:04:53.857 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF Lock (24)
2015-11-14 01:04:53.857 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@6c1f4adc
2015-11-14 07:41:46.780 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 07:41:46.780 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 07:41:46.780 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Manual UnLock (22)
2015-11-14 07:41:46.780 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@1ba24a2f
2015-11-14 07:46:55.992 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 07:46:55.992 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 07:46:55.992 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = RF Lock (24)
2015-11-14 07:46:55.992 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@f8fe4ef
2015-11-14 09:21:12.008 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 09:21:12.008 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 09:21:12.008 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Manual UnLock (22)
2015-11-14 09:21:12.008 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@14b91f9d
2015-11-14 09:22:34.038 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 09:22:34.038 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 09:22:34.038 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Keypad Unlock (19)
2015-11-14 09:22:34.038 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@17e59e18
2015-11-14 09:26:45.744 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 09:26:45.744 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 2
2015-11-14 09:26:45.744 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Manual Lock (21)
2015-11-14 09:26:45.744 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@6a529d2e

If you see, at 2015-11-14 09:21:12.008, the wife left for her morning run. Locked the door, then came back in (for something), then left again.

Detail:

2015-11-14 09:21:12.008 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 09:21:12.008 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 09:21:12.008 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Manual UnLock (22)
2015-11-14 09:21:12.008 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@14b91f9d
2015-11-14 09:22:34.038 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 09:22:34.038 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 1
2015-11-14 09:22:34.038 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Keypad Unlock (19)
2015-11-14 09:22:34.038 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@17e59e18
2015-11-14 09:26:45.744 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 27: Received Alarm Request
2015-11-14 09:26:45.744 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 27: Alarm report - Value = 2
2015-11-14 09:26:45.744 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:112 ]- NODE 27: Alarm Type = Manual Lock (21)
2015-11-14 09:26:45.744 [DEBUG] [b.z.i.protocol.ZWaveController:616 ]- NODE 27: Notifying event listeners: ZWaveAlarmValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent@6a529d2e

There are 3 Alarms, captured, but there were actually 4 events. Between the “Manual unlock” and the “Keypad unlock” there should have been a “Touch Lock” Alarm. This is captured at other times, so the lock sends it, and I capture it. I’m assuming the binding missed it somehow (timing? not long between the unlock and the lock). Maybe the lock didn’t send it (but then we’re in La La land) - have to assume it did and we missed it.

Here is my openhab.log output (filtered to capture “Front Door” events - this captures the output of my rules (hopefully I’ve got all the bugs out of the rules).

09:21:12.010 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm Received: 1
09:21:12.011 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm 22 (Manual Unlock) Received: 1
09:21:12.013 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Front Door Lock Notifications'
09:21:12.014 [INFO ] [o.model.script.Front Door Lock:53   ] - Front Door Lock trigger Value is: true
09:21:12.215 [INFO ] [o.model.script.Front Door Lock:53   ] - Front Door Lock Status updated to CONFIRMED Unlocked by: Manual Unlock
09:21:12.216 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Auto Unlock Cancelled (Door is already unlocked)
09:21:17.209 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Opened - sending Hallway Motion trigger
09:21:38.120 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Autolock Front Door'
09:21:38.135 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Closed: Setting autolock timer
09:22:34.224 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm Received: 1
09:22:34.276 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm 19 (Keypad Unlock) User: 1
09:22:34.383 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm User: 1 is Nick/Jill
09:22:36.084 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Opened - sending Hallway Motion trigger
09:22:39.450 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Autolock Front Door'
09:22:39.450 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Closed: Setting autolock timer
09:26:45.750 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm Received: 2
09:26:45.791 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm 21 (Manual Lock) Received: 2
09:26:45.816 [INFO ] [penhab.model.script.Front Door:53   ] - Door Lock Alarm 21 Touch Lock
09:26:45.950 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Front Door Lock Notifications'
09:26:45.955 [INFO ] [o.model.script.Front Door Lock:53   ] - Front Door Lock trigger Value is: true
09:26:46.250 [INFO ] [o.model.script.Front Door Lock:53   ] - Front Door Lock Status updated to CONFIRMED Locked by: Touch Lock
09:26:46.252 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Auto Relock Cancelled (Door is already locked)
09:29:02.302 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Presence Detection Unlock Front Door Jill'
10:49:33.441 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Presence Detection Unlock Front Door Jill'
10:50:32.930 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Opened - sending Hallway Motion trigger
10:50:33.103 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Front Door Lock Notifications'
10:50:33.180 [INFO ] [o.model.script.Front Door Lock:53   ] - Front Door Lock trigger Value is: false
10:50:34.239 [INFO ] [o.model.script.Front Door Lock:53   ] - Front Door Lock Status updated to CONFIRMED Unlocked
10:50:34.655 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Auto Unlock Cancelled (Door is already unlocked)
10:50:37.002 [DEBUG] [m.r.internal.engine.RuleEngine:305  ] - Executing rule 'Autolock Front Door'
10:50:37.030 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Closed: Setting autolock timer
10:55:37.520 [INFO ] [penhab.model.script.Front Door:53   ] - Front Door Locked by: Auto

You can see the missed “Touch Lock” here (ie there should be two, but there is only one). Other triggers work well though. There is only one missed trigger in the list today (she got back at 10:50). There should have been an unlock at 10:50:32.930, but I had just updated my rules, so that is captured in a “lock initialize” rule, but I did get the notification (just in case you’re wondering how she opened a locked door).

Right now, after leaving it overnight, everything is working normally, and lock is working well. The lock is sometimes fast (4 seconds) sometimes slow (up to 30 seconds or more) - seems to be waiting for the “nonce” security hash I guess.

Once I’m happy that it’s stable (no more fiddling/restarts), I’ll capture some logs of normal operation, then (fingers crossed) I’ll restart openhab, and capture the startup logs - this seems to be the most problematical part of the whole thing. Once everything is going, all is well, getting everything going…

If we can get the ALARM capture to 100% I can reduce polling to a minimum, and that should reduce traffic to/from the lock. The big delay seems to be the “nonce” handshake, and as a the lock mostly sits there and does nothing, but does need to wake up, handshake, and respond quickly, this may be the main problem.

Battery is reporting (not sure how often, I’m not polling), and it’s up to 71% now (from 70%) - maybe just minor fluctuations (these are not new batteries, from the old lock, which initially reported at 75% 2 days ago - but I have been testing a lot).

Aeon sensors are still at 100% - so that may not have been related. The one that was dropping (was 85% is now up to 91% climbed slowly yesterday 1% at a time). Weird.

I now have an Aeon ZSD37-ZW Range Extender a couple of feet from the lock. Not sure if it’s doing anything, but it can’t hurt.

I’ll post some logs later this afternoon.

124

Zwave boot logs posted to my dropbox folder. They are the zwave* files (2 of them). This is from a standing restart of openhab. I left the zwave device alone for a while, then tested various items (after 45 minutes or so). Everything checks out OK. Lock is working perfectly (with the limited tests I did at 8:44). Node 27 is the zwave log filterd for just the lock. the other is the full zwave log for all devices.

Logs cover a period of just over 1 hour.

So far it’s good!

125

I wonder what the trick is to speed up the status. I tested my Schlage lock with Homeseer, and the status reports back almost instantly (1 second?). Do all requests have to use the security command class? I thought that locks could send some commands outside of the security class.

Thanks for working on this btw! I will try to test with my Schlage soon.

126

I’m not sure, my lock says that it respond to a BASIC_GET with the status of the lock (locked/unlocked) - which I presume is not a security class (it does not respond to BASIC_SET at all it states). It also sends ALARM’s with actions taken (manual lock/unlock, keypad lock/unlock, Zwave lock/unlock and others) - these don’t seem to be security classes either, and response is almost instant (< 1 second).

DOOR_LOCK is a security class, so locking/unlocking takes longer, but it varies widely from about 4 seconds to over 30. It seems if the lock is marked as DEAD it takes a while for it to become UNDEAD and then lock/unlock.

The status polling is for the DOOR_LOCK class - which is a security class, so maybe that takes while to respond. I have tried polling for command BASIC, but don’t seem to get any response.

Right now it is working well, but response time varies. I just added an Aeon MS6 (mains powered) by the lock to act as another repeater (but I’m not sure this will make any difference).

The other zwave items I have continue to be a little flaky, sometimes being slow to respond, or dropping off the network and needing to be reinitialized.

If we can get the other zwave devices working reliably, and the DEAD/UNDEAD lock issue resolved, 4 seconds response would be fine.

I think this version of the binding is 90 % there.

127

Hi ,

I have vision zm1701 door lock, not getting how to operate.
Can u help me out.
How to add in openhab zwave network using openzwave control panel.
Actually i added successfully but not getting what to do next like locking, unlocking, setting usercodes.

Please can u help me

Thanks

128

Hi sir,
I am using vision zm1701 doorlock.
Not getting xml file for this product and also not getting this how add into openhab-zwave network .
Not getting any help on google.
Can you please help me out.

Thanks,
shrikant

129

@dbadia hello Dave, apologies for the long hiatus. I have been testing your latest code for a while. There are two things that have been consistent:

  1. Takes a lot of attempts to pair the lock. Most of the attempts seem to pair the lock. I conclude this by what habmin shows (alive status, time stamps etc). However the zwave log has secure inclusion failed. I don’t get the status, batter level nor lock commands working. When finally it pairs, none of the functionalities work.

  2. All my zwave commands take 6 to 12 seconds for response (device turning on) and about 3 to 5 seconds to turn off if they have been turned on through openhab. This behaviour is consistent with every UI. I experienced similar delays when I used the 1.8 code base built in cloudbees after Nov 11th. ( I will get you the version number when I get to my PC) but they were alleviated after a few network heals.

  3. My aeotech power strip gets messed up. I can never control it using your code. Once I revert back to the old code, it takes a few restarts of my PC before I can get it to work.
    My log files are on the same URL (google drive) posted earlier. Let me know if you need more information or if you want me to test it in a specific way.

130

Hi Nicholas,

I was trying to test my Yale YRD240 but it’s not in the database yet so I was hoping to fool it for now by changing NODE.xml file. Would you be able to send me you NODE_27.xml ??? file for your yale lock?

Regards,

Vlad

131

Vlad,

I have given up testing for the moment (the rest of my zwave network was just too flakey to be usable), and I switched to a new Gen 5 z-stick. That is to say I don’t have my NODE_27.xml anymore.

I am currently running my lock via my Vera and the MIOS binding (which works well, but is convoluted).

I don’t think that it would have helped you anyway. Why not add it to the database? the Yale locks are all the same, you just need to add the product number to the products.xml file and recompile. My previous post on the subject shows what to do. You just need the id numbers, there is already a Yale lock defined in the database.

Be aware you need a SECURE pairing - which is hard. mostly when you try to pair, you will get an insecure paring, which looks like it works, but will not lock/unlock etc.

You also really need to add the alarm classes to the binding, they are very useful for finding out the status of the lock (which is important for correct operation). My previous posts show you what to add to the binding to activate the alarm status reporting.

You do need to be able to compile the binding from source. It’s not hard. You can add your own entries to the database then.

132

Hi Nicholas,

Thank you for a quick reply and your suggestions. I was hoping to test this quickly without recompiling but I think I have no choice then. Your last post was stating that it was 90% production ready, what happened? Where is the instability comes from? Is it the lock it self or is it affecting other devices in the zwave network?

Regards,
Vlad

133

@dbadia Your work on the Z-Wave Security Class is great, thanks!!

I’ve been trying to include my Schlage BE468 but I’m experiencing some issues regarding the inclusion of the lock to the z-wave network.

The error I see in the log is

Secure Inclusion FAILED. At step SECURITY_COMMANDS_SUPPORTED_GET: null

I don’t know if this might mean that the inclusion time that habmin has (30 seconds ) is afecting the inclusion?

I am able to add to my controller (Aeon Z-Stick S2) the smart lock using Zensys and I am able to lock/unlock the door.

Thanks in advance for your help.

134

@wificordon
Can you post the full log to a dropbox account or simliar so I can download it? I can take a look at the log to look for clues.

Others have had success pairing this lock so I’d suggest you try a few more times as well. Be sure to exclude the lock before attempting to repair

Dave