Kwikset Z-wave Lock Problem

First off, thanks for the new 7.0.2 software. Overall things are stable, except for my locks.

-- Mac OS 10.12.1, Indigo 7.0.2, Cheese grater Mac Pro (2010)

I have 6 Kwikset locks in my home that were successfully controlled via the Vera Bridge plugin before Indigo 7. It took a while, but I moved all of the locks to my Z-wave controller and included them in Indigo. Each device synced properly and each lock has the new fancy locked/unlocked icons in the Device section.

Here are some specifics:
Model: SmartCode Lock, firmware 2.0.6
Manufacturer: Kwikset
Neighbors: 1, 8, 9, 17, 19, 20, 25, 26, 32, 40, 42, 46, 49, 52, 53, 54, 55, 57, 58, 62, 63, 65, 67, 68, 78, 80, 81, 82, 83, 84, 86, 87, 88, 97, 99, 100, 101, 105,
Associations: 1:[1]
Encryption: Enabled for Commands 80 85 86 8B 4C 4E 98 20 62 63 70 71 72 75

Here's the problem-- More often than not, and inconsistently, with each lock, the reported state is incorrect, with a Last Update time appropriate for the situation.

Example-- I'll command the locks to lock. Some will actuate, some will not, but all will report "locked" with a Last Update correct. When I moved them over to Indigo, they were all actuating properly for the first couple weeks. Now the lock behavior is very intermittent. I replaced all the batteries when I moved them over to Indigo.

Here is an example entry from the Event Log:

Z-Wave sent "Office Door Lock" lock

It showed no errors, and the State turned Green (locked) the "last update" is correct, but the lock did not actuate.

It looks like Indigo is not telling me the truth-- or maybe the locks are not telling Indigo the truth. Any suggestions?

[matt (support)]

Can you turn on debug logging via the Interfaces->Z-Wave->Configure... menu item, then capture in the log what happens in the failure case where Indigo reports it locked but it didn't?

Here's a portion of the Event Log that shows a successful and an unsuccessful command. And I didn't see a change in my log after I toggled the debug logging. Maybe I had it on all the time?

The Entry Door Lock(134) was successful this time, but hasn't worked at all for the last couple days. And the Office Door Lock (135) was unsuccessful and also hasn't worked for several days. After the Office Door Lock command was sent, the "Waiting for Z-wave ACK" message is displayed and other green commands are backing up in the queue and the blue light in the usb Z-stick is not illuminated. Then eventually the lock command times out and all the queued commands are executed. The Office lock is literally 11 feet within line of sight from the USB Z-stick.

Some locks have the dreaded "no ack" in the State.

And here's something that has been quite a surprise-- I replaced the lock batteries (Energizer Ultimate Lithium) on November 24. Now, just 2 weeks later, the Battery Level reported on most locks are 100%, but the locks themselves are blinking a red led which means the lock batteries are nearly dead. I have a fair amount of Z-wave network activity-- Might the activity prevent the locks from going to sleep? I've had the locks on the Vera for about 3 and a half years. Normally the Ultimate Lithium batteries last between 4 and 5 months.

Sadly, I am going to put the locks back on the Vera without further troubleshooting. These are locks, not lights, and I really need them to act and report properly.



Z-Wave sent "Entry Door Lock" unlock
Z-Wave Debug RCVD requestMeterLevel: 01 14 00 04 08 79 0E 32 02 21 74 00 00 00 00 00 14 00 00 05 13 F7
Z-Wave Debug . . requestMeterLevel: node 121, endpoint None, meterType 01, raw value 7400...
Z-Wave Debug . . requestMeterLevel: 0.000 W (float: 0.000000)
Z-Wave Debug RCVD requestMeterLevel: 01 14 00 04 00 79 0E 32 02 21 74 00 00 00 00 00 14 00 00 05 13 FF
Z-Wave Debug . . requestMeterLevel: node 121, endpoint None, meterType 01, raw value 7400...
Z-Wave Debug . . requestMeterLevel: 0.000 W (float: 0.000000)
Z-Wave Debug RCVD nonceFetch: node 134
Z-Wave Debug SENT nonceReport: 01 11 00 13 86 0A 98 80 2D 0F 55 A1 6D C7 B4 E0 25 D7 B3
Z-Wave Debug RCVD encryptedPacket: 00 71 05 19 01 (decrypted)
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 0A 00 04 00 86 04 71 05 19 01 FF
Z-Wave Debug . . requestAlarmSensorStatus: node 134, endpoint None, cmdClass 71, type 25, value 1, classSubKey 711901
Z-Wave received "Entry Door Lock" status update unlocked (via controller)
Z-Wave Debug RCVD requestMeterLevel: 01 14 00 04 08 79 0E 32 02 21 64 00 00 05 13 00 14 00 00 05 13 F1
Z-Wave Debug . . requestMeterLevel: node 121, endpoint None, meterType 01, raw value 6400...
Z-Wave Debug . . requestMeterLevel: 1.299 kWh (float: 1.299000)
Z-Wave Debug RCVD requestMeterLevel: 01 14 00 04 00 79 0E 32 02 21 64 00 00 05 13 00 14 00 00 05 13 F9
Z-Wave Debug . . requestMeterLevel: node 121, endpoint None, meterType 01, raw value 6400...
Z-Wave Debug . . requestMeterLevel: 1.299 kWh (float: 1.299000)
Z-Wave Debug RCVD requestMeterLevel: 01 14 00 04 08 79 0E 32 02 21 74 00 00 00 00 00 14 00 00 05 13 F7
Z-Wave Debug . . requestMeterLevel: node 121, endpoint None, meterType 01, raw value 7400...
Z-Wave Debug . . requestMeterLevel: 0.000 W (float: 0.000000)
Z-Wave Debug RCVD requestMeterLevel: 01 14 00 04 00 79 0E 32 02 21 74 00 00 00 00 00 14 00 00 05 13 FF
Z-Wave Debug . . requestMeterLevel: node 121, endpoint None, meterType 01, raw value 7400...
Z-Wave Debug . . requestMeterLevel: 0.000 W (float: 0.000000)
Z-Wave Debug SENT nonceRequest: 01 09 00 13 87 02 98 40 25 D8 45

Dec 9, 2016, 13:55:18
Schedule Garage Man Door to House - Main Garage Lights ON (delayed action)

Dec 9, 2016, 13:55:56
Z-Wave Error no ack/nak/busy reply (135) for nonceRequest (re-sending)
Z-Wave Debug SENT nonceRequest: 01 09 00 13 87 02 98 40 25 D8 45

Dec 9, 2016, 13:56:29
Trigger FING EVENT 1 Curt iPhone is home

Dec 9, 2016, 13:56:56
Z-Wave Error no ack/nak/busy reply (135) for nonceRequest (re-sending)
Z-Wave Debug SENT nonceRequest: 01 09 00 13 87 02 98 40 25 D8 45

Dec 9, 2016, 13:55:56
Z-Wave Error no ack/nak/busy reply (135) for nonceRequest (re-sending)
Z-Wave Debug SENT nonceRequest: 01 09 00 13 87 02 98 40 25 D8 45

Dec 9, 2016, 13:57:28
Trigger FING EVENT 1 Curt iPhone is home

Dec 9, 2016, 13:57:56
Z-Wave Error no ack/nak/busy reply (135) for nonceRequest (re-sending)
Z-Wave Debug SENT nonceRequest: 01 09 00 13 87 02 98 40 25 D8 45

Dec 9, 2016, 13:58:57
Z-Wave Debug . . nonceRequest: requeuing 16 unsolicited packets
Z-Wave Error send "Office Door Lock" lock failed

... and in the limited time I had, I didn't get you exactly what you asked for--- a lock that was not reporting its position truthfully. I'm sorry abut that.

I moved the locks back to the Vera -- again, it took a while, but they seem stable.

Hi,

I'm the author of the ZWave lock manager plugin.

It would help both Matt and me if you could keep one of the not-very-stable locks on Indigo whilst we help you debug the problem - most other users are having no problem with Kwikset so I for one would like to see if we can get to the bottom of this issue.

Are you able to move a lesser-used lock back onto Indigo and copy/paste the define/sync process so we can see which module definitions are in play here.

Then perform a single lock and unlock of the device, both on the lock then via Indigo, then we can see the commands arriving - both me and Matt can interpret the raw data.

(Make sure you've still got ZWave debug on - it's on in the log above because you get "ZWave debug: ...." lines)

Peter


Sent from my iPhone using Tapatalk

I'd be glad to move one lock back to Indigo to see what happens. It will be a few days-- I'm on a trip. They seemed to mostly cooperate one at a time, but not during the flurry of unlocking doors and turning on lights when I arrive home. (Or similarly when I leave)

Regardless of any outcome or resolution, I will likely keep my locks on Vera-- even when they were cooperating, they took longer to respond than lights-- likely all the encryption. For homes with one or two locks, it might not be a problem, but with 6, it is actually a benefit having them outsourced so subsequent light commands aren't held up by a temperamental lock. I've been begging for locks inside Indigo for years-- now, at least in my 6 lock example, it is probably best to keep them on the Vera.

Sorry for the long silence on this thread-- Things got busy during the holidays, etc. My locks have been back on the Vera since my posting in December and have been working fine. Although I don't officially know what the problem was with the door locks when they were attached to the Z-Stick, my entire Indigo Z-wave system just got more stable--- I replaced my 4 year old Z-stick with the newer Gen 5 Z-stick and during the Remove/Include process I found 4 switches on my network that weren't quite right. A couple would not let me Remove them from the old Z-stick (I tried releasing using the old Z-stick, new one, and a Vera). In addition to those, two others wouldn't Include with the new Z-stick. So, I replaced 4 sketchy devices. Those devices were all 4 years old (when I started with home automation) and two were indoor/outdoor switches that were outside for most of the 4 years.

It has only been 48 hours with the new Z-stick and the whole network seems more stable and a bit snappier. I used to, on occasion, get a red item in the Indigo Device list. Not anymore. When I get a chance I might move a couple locks at a time to the new Z-stick and report back.

Again, I'm sorry for the long silence on this thread-- and honestly, the fix for my unstable lock response might turn out to be a combination of replacing 4 devices and getting a new Z-stick.

[matt (support)]

Thanks for the update. For clarification, am I correct that you moved the locks back to Indigo (from Vera) once you got the Gen5 Z-Stick?

No, I'm sorry I wasn't clear. I'm still running the locks on the Vera (using the Vera Bridge plugin) for now. After a while I might move them over to the Z-Stick one at a time and see how it goes. (My house is a Rambler with 6 locks). Overall network stability has gotten better with the new Z-Stick and replacing a few switches. Thanks again for everything and I'll let you know when I start moving the locks over to the new Z-stick. I'm cautiously optimistic that a more stable network will produce better locking/unlocking behavior.

Is there anything new on this issue? I like the idea of moving off the Vera since it is only used for my Kwikset locks.

[jay (support)]

We were never given enough information to reproduce the issue. Lots of others are using Kwikset locks (including me but I'm using the Series 2 stick still) though so I'd just move one over and give it a try.

I have three Kwikset Home Connect 912s. All three are connected via Gen 5 z-stick. I moved them over from the Vera. Two of them work fine, but the other does not. For the one which does not work, the battery level does not appear. If I go to Interfaces, Z-wave, Modify Configuration Parameter, the lock does not appear in the list. What does that mean?

It’s failed to fully sync.

(Official answer: if it’s not in that list, it hasn’t reported that it supports the parameter configuration class... but I reckon given no battery status either that it hasn’t synced successfully and thus hasn’t told Indigo it supports parameters etc)


Sent from my iPhone using Tapatalk Pro

[matt (support)]

It’s failed to fully sync.

Yes, and if it won't resync then fully exclude it from the Z-Stick, then re-include it (with encryption enabled) and finally resync.