Z-wave (Schlage) Lock Support on OH1

[Nicholas_Waterton]

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.

[Nicholas_Waterton]

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,

[Nicholas_Waterton]

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.

[Nicholas_Waterton]

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!

[JustinHoMi (Justin Mitchell)]

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.

[Nicholas_Waterton]

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.

[Shrikant_Lahase]

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

[Shrikant_Lahase]

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

[mganapa (Mahesh Ganapathy)]

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

[walterua (Vlad L)]

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

[Nicholas_Waterton]

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.

[walterua (Vlad L)]

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

[wificordon]

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

[dbadia]

@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

[wificordon]

Hi Dave (@dbadia ),

Thanks for the response. Here is the link for the logs http://pastebin.com/34pbrawk.

The steps I took right now are as follow:

1. Excluded the lock from the network.
2. Factory reset the lock
3. Included the lock to the network.

I have tried 15+ time to add the lock, with the security features, to the network without any luck.

I have been able to lock/unlock the lock using Zensys-tool, that way I know that the stick and lock work well.

Also I’m using openhab 1.8.

Cheers,
W.

Thanks in advance for your help.

[wificordon]

Hi @dbadia,

Where the logs I sent useful?

Cheers,
W.

[dbadia]

@wificordon
Looks like debug was not enabled during these tests.
Can you follow the instructions here:

openhab/openhab1-addons

Make sure you start openhab with start_debug.sh or start_debug.bat

You should see a LOT of data in the log file

Dave

[wificordon]

Hi @dbadia,

Here are the logs with the debug log ON http://pastebin.com/ByEeGEJq

Thanks in advance!
Cheers,
W.

[dbadia]

@wificordon

Looking through the log, most of the secure pair steps completed. I’ll make a note to show the success message accordingly.

Can you continue with step "5 Stop the openhab server. You will now… " from here

openhab/openhab1-addons

and see if you can control it

Thanks
Dave

[dbadia]

@Nicholas_Waterton

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.

@Nicholas_Waterton
Glad you figured this part out, the changes to the node xml file were a side effect of my refactoring. I always test my code by repairing so I didn’t realize the impact it would have on people who already had their locks paired.

Dave