Kwikset SmartCode 916

Devices & Integrations
1

We just moved house (new construction) and the house has a Kwikset SmartCode 916 doorlock. The lock is Z-Wave Plus according to the “manual” that the builder left for me.

After getting my hub out of the box it was packed away in, I waited for the hub to update to the latest version, then started adding the lock to the hub (I’m using the new SmartThings app). There are no other devices connected to the hub at the moment, the hub is about 6 feet away from the lock with only a single hollow-core wood door between the lock and the hub.

I was disappointed to be told by SmartThings that my lock is old and I should buy a newer one for better security. I though Z-Wave Plus was the latest.

The lock got added fairly quickly, but in the new app it has been showing as “Checking status…” for at least 20 minutes.

Looking in the IDE the only data value shown is:

  • networkSecurityLevel: ZWAVE_S0_LEGACY

which looks ominous (legacy?).

Most of the current state fields are empty (except checkInterval is set to 3600s).

Here are some of the other fields from the IDE:
|Name|KwikSet Door Lock|
|Label|Front doorlock|
|Type|Z-Wave Lock|
|Version|Published|
|Device Network Id|3F|
|Status|ONLINE|

About 30 minutes after adding the lock, it finally showed status both in the IDE and in the app. Then I tried to unlock it via the app and it went back into “Checking status…” and then “Unknown”. And the lock never actually unlocked. And about 20 minutes later when I re-checked in the app, it is showing as “Locked” (the unlock never happened but at least it is now showing the correct lock/unlock state).

An additional data field showed up after the initial 30 minute delay:

  • fw: 4.10

I’m guessing that is the firmware version.

During all this I have received three notifications from the new app on my phone, each one saying “Updated code 1 in Front doorlock at House”. It’s true that there is (or was) a single code set in the lock (before it was added to SmartThings). But why would SmartThings be updating it in the lock? And why would it do it three times?

Should I expect this lock to work eventually? Did it default to the wrong DTH? Has it been chugging down terabytes of data for a firmware update? Is this just another thing that doesn’t work in the new app?

Thanks … Mike

2

BTW here are the states the lock goes through (viewed in the app) when I tell the app to unlock it:
Locked
Unlocking…
Updating status…
Not responding
(several minute delay)
Unknown
(several minute delay)
Locked

3

The lock finally unlocked about an hour after my first request. I had submitted a couple more requests that may be queued up, so I guess I will need to take the batteries out overnight in case it decides to unlock.

4

This morning I realized that the Live Logging page was showing several “Device is offline” entries per second. That doesn’t feel like that is enough to swamp the hub and prevent it from talking to the one device that is connected (6’ away from it).

I can’t identify the individual devices from their entries in the list, but the filters at the top of the Live Logging page ends up being populated with each of my Z-Wave repeaters (which are all Iris switches), implying that it is only those repeaters that are populating the Live Logging list.

I thought maybe the hub is trying to use an invalid path (via a currently non-existent repeater) to the new device that is 6’ away from it. On the basis of that I did a Z-Wave repair, which completed with lots of failures (since all other devices are currently off).

I’m not sure what else to try, does anyone have any suggestions?

5

Hi there. There are many reasons why a lock may be unresponsive or slow to respond. The type of lock and module have a role to play but more importantly it’s usually an indication of the underlying mesh or/and ghost devices which may be interfering with you setup.

You may want to read through this blog from @RBoy on how to optimize your mesh and weed out any ghost devices. FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?

As for the device itself, the Kiwkset 916 is a popular model but has a few quirks. You can find out more details on this topic first post, look for the link about lock limitations which explains how different models of locks behave in various environments: [RELEASE] Universal Enhanced Z-Wave Lock Device Handler for Schlage, Yale, Kwikset, IDLock, Popp, Danalock, August Pro, Keywe, Philia, Samsung

It’s good that you have many mains powered device close to your lock, with the new IDE tools you can even look at the z-wave statistics to see how the lock’s zwave module is responding to the mesh.

Device handlers play a key role in access hidden features within a lock, optimizing the lock behavior and in some cases providing workaround for bugs in the lock’s firmware. You can also find more details about these in the Universal Enhanced Z-Wave Lock device handler page.

6

Thanks Maddie. At the moment I have no other devices connected to the hub (I was wondering if the hub was thrashing trying to talk to all its friends who are still in boxes in my garage).

Thanks for the pointer to why it is helpful to move the hub and use a repeater. Currently the only place I have ethernet is in the wiring closet located 6’ from the doorlock, so moving my V2 hub (no Wi-Fi support) isn’t a quick fix. Although I could experiment with a long ethernet cable.

I thought I had seen “route” on some device pages a while ago, but that was before I was hoodwinked into switching to the new app. Currently on the device page for the doorlock in the IDE there is nothing to indicate how the lock is connected to the hub. I’m not sure if that is because of changes in the IDE related to me using the new app, or something else.

7

Hey. If you don’t see any “statistics” or route information that could probably mean a communication problem with the mesh or packet loss. A buffering device will probably help in such a scenario.

8

I think that’s what I have put in place (I plugged in one of my Iris plugs which are Z-Wave & Zigbee repeater).

Frustratingly, the SmartThings hub seems to ignore the fact that it’s got a perfectly good repeater 5’ away from it to handle the traffic to the lock and is apparently still attempting to connect directly to the doorlock which is slightly further away (this is after a Z-Wave repair). I have verified that both (Zibgee & Z-Wave) repeaters in my Iris plug are shown as connected directly to the hub (from the “route” field in the device details page for each repeater).

I wonder - will a Z-Wave repeater not repeat for a Z-Wave Plus device? Maybe that’s the problem. Would I be better off replacing the Z-Wave Plus doorlock with the Zigbee equivalent?

9

Hi. In theory yes it’s possible for a Z-Wave repeater to repeat for a Z-Wave plug devices, not all Z-Wave Plus commands are supported by Z-Wave repeaters. It’s best to use a mains powered Z-Wave Plus device as a repeater for best performance. There are some good examples of Z-Wave Plus repeaters here.

I noticed that you’re using the Iris plugs as repeaters. If it’s the Iris 3210-L, do note that while is an excellent ZigBee repeater, in our experience it is not a good Z-Wave repeater. There are many reports from users where the IRIS plug does not function adequately as a Z-Wave repeater and infact in some cases it even hinders the mesh. It’s best not to use the Z-Wave functionality for the IRIS 3210-L. Keep in mind that the IRIS 3201-L only works as a Z-Wave repeater if its “paired” with the hub as a Z-Wave device. So you can safely pair it using the ZigBee interface but not pair it using Z-Wave to use it as a ZigBee repeater without the Z-Wave functionality. Hope this helps.

10

Thanks again Maddie. Yes, I’m using the Iris 3210-L as a Z-Wave (& Zigbee) repeater.

I have moved the hub further away from the lock (not 70’ though, that would be out in the back yard), and also moved the only Iris repeater so it is between the lock and the hub (in the lock’s new location). I then did a Z-Wave repair.

The lock continues to remain offline until I manually lock or unlock it, at which point it comes online, but still does not show “route” anywhere on the device details page. I confirmed that both of the (Zigbee & Z-Wave) repeaters do show a route direct to the hub.

I have a mix of Z-Wave and Zigbee devices (all battery powered), so using the Iris as a dual repeater worked well at the last house (I had about 7 of the Iris plugs and will eventually use them at the new house if I keep using SmartThings).

What do you think about replacing the lock with the Zigbee variant? Does Zigbee have the same brain-dead behavior when a device such as a lock is too close to the hub and the hub won’t route through a repeater that is also close to the hub and the lock?

Thanks … Mike

11

Update:
After I plugged in all of the Iris plugs that came from the old house (but still no other devices except for this recalcitrant doorlock, did a few Z-Wave repairs and at least one hub power cycle (to force the Zigbee mesh to repair itself), let things settle for a few days, the lock is now working reliably.

The IDE is finally showing a route to the doorlock, although it is still directly connected to the hub.

So my guess is that the cause was a combination of:

  • Doorlocks really wanting to connect through a repeater which MUST be closer than the hub - this is not easily done with my layout, and
  • The hub going crazy trying to talk to 15-20 other devices that are still OFF

I have a Zigbee version of this lock on order. Now I’m not sure whether to cancel it, or if I should still use it in place of the Z-Wave Plus lock (in the hopes that Zigbee doorlocks are more tolerant of being connected directly to the hub, or they have the brains to seek out a good repeater). Does anyone know if that is the case for Zigbee doorlocks?

12

I have a 911 zigbee lock and never had an issue with it… As a matter of fact, all my devices are zigbee and work flawlessly…non of the issues folks seem to have with zwave.

13

Good to know, thanks @troy_owens

1 Like