Problems with secure inclusion of Zwave Kwikset 914 lock

I have openhab (2.5.0~S1575-1) installed with a HUSBZB-1 stick. I have a number of other zwave devices discovered and added, so the setup is basically working. I’m trying to do a secure inclusion of a Kwikset 914 lock. I can add it without security just fine. I know it probably doesn’t matter, but I’ve tried with the lock right next to the zwave stick, and the lock has fresh batteries.

As an example, I went through this process:

  1. In paperui, go to the insecurely included lock Thing’s advanced settings and select “Remove Device From Controller”.
  2. Remove the Thing from openhab.
  3. Pull battery pack on lock, and do a factory reset.
  4. Go to “Scan For Things” and click the zwave item.
  5. At the same time, press the “A” button once on the lock (per Kwikset instructions).
  6. The lock almost immediately appears in the Inbox. I add it.

Every time, the “zwave_secure” property is “false”.

Can any kind soul assist? I know others have gotten this lock to work. Thanks!

This could work, if you first hard reset the lock, but what you should be doing is an exclusion. You’ll find this in the settings of the controller Thing…

image

Then follow the manufacturer instructions for exclusion (usually the same as inclusion). This can all be done in Paper UI, but for everything Zwave, you should use Habmin.

Ah! Ok, so should I remove the improperly included thing, put the controller in exclusion mode, and then hit the button on the lock? Just not sure of the proper sequence. Thanks!

Yes, put the controller into exclusion mode first and then hit the button or do the action on the device.

NOTE, for future users who come across this thread, you can perform an exclude for a device that is included on a different controller. This can be handy if you have a controller go bad or the like.

Hello, again. I’m still struggling with this. Here’s the log viewer output when I try to exclude the lock after a failed attempt to add it securely. The node being removed was node 13. Not sure if this is showing proper behavior or not. Can anyone comment? Thanks.

It looks like it removed something. There is usually a visual resonse from the device after an exclusion too. At least, there are with my locks (BE469). Are you still having trouble securely including it after the exclude?

Well, I think the exclusion is working. I’ve been able to add the lock with security enabled, although it took several tries.

However, I only see two channels: “Door Lock”, and “Battery Level”. I’ve seen screen shots of others’ lock Thing, and they have other channels such as “Alarm”. I do not have those channels. The Kwikset part number is 99140-102, made in August 2018. Any ideas on what is wrong or what I can try next? Thanks!

The device information is:

dbReference 992
defaultAssociations 1,2
manufacturerId 0090
manufacturerRef 0003:0446,0003:0642
modelId Kwikset 914C Convert Smart Lock
vendor Black & Decker
zwave_beaming true
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_ENTRY_CONTROL
zwave_class_specific SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK
zwave_deviceid 1094
zwave_devicetype 3
zwave_frequent true
zwave_listening false
zwave_manufacturer 144
zwave_neighbours
zwave_nodeid 18
zwave_plus_devicetype NODE_TYPE_ZWAVEPLUS_NODE
zwave_plus_roletype ROLE_TYPE_SLAVE_SLEEPING_LISTENING
zwave_routing true
zwave_secure true
zwave_version 4.45

That is correct - this device only has these channels configured.

lock_door is the only Channel configured for this device… https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/992. batery-level magically shows up if it is battery powered. Since it has the ALARMv4 CC, I’ve added the alarm_raw Channel to the device db. You can either wait for the 2.5M2 build, or you can manually install the snapshot version of the zwave binding. This change should show up within the week. Here’s a script you can use for that (there are manual steps in the readme, if you want to go that route)…

Hmm. I’d posted and asked about the lock sending state when it is locked/unlocked manually and Rich K indicated it was supported. Apparently not.

Ok, thanks very much Scott. I’ll grab the updated binding when it comes out. Is this the build job to watch? https://ci.openhab.org/job/openHAB2-Bundles/

Well, it might just be that whoever created the database did it manually, and didn’t add all channels. I would also expect that it sends state alarms… Can you post the XML file that OH creates?

Yes. Even if the lock reports its own state, alarm_raw can be used in a rule to detect when codes have been used. Depending on your lock, YMMV.

Here is a screen shot of what Channels I have, and have always had for my 914TRL Touchpad Electronic Deadbolt (as reported by PaperUI).

Door Lock lets me open/close the lock (or at least it used to, doesn’t seem to work at the moment) and changes when the door is locked/unlocked.

The Alarm channel triggers when the lock is locked/unlocked and the value indicates how according to this table:

The following table provides a reference of the Alarm_Number related messages.

Alarm Type    Alarm Level            Notification Event  

021              001                      Lock Secured using Keyed cylinder or inside thumb-turn  

022              001                      Lock Un-Secured using Keyed cylinder or inside thumb-turn  

026              001                      Lock Auto Secured – Bolt Jammed (Not fully extended)

027              001                      Lock Auto Secured – Successful (Fully extended)  

017              001                      Lock Secured at Keypad – Bolt Jammed (Not fully extended)   

018              000 or User-ID#*   Lock Secured at Keypad – Successful (Fully extended)   

019              User-ID#*              Lock Un-Secured by User (User-ID) at Keypad  

023              001                      Lock Secured by Controller – Bolt Jammed (Not fully extended)   

024              001                      Lock Secured by Controller – Successful (Fully extended)   

025              001                      Lock Un-Secured by Controller – Successful (Fully retracted)  

112              User-ID#*              New User Code (User-ID#) added to the lock  

032              001                      All User Codes deleted from lock   

161              001                      Failed User Code attempt at Keypad  

162              User-ID#*             Attempted access by user (User-ID#) outside of scheduled   

167              001                      Low battery level   

168              001                      Critical battery level   

169              001                      Battery level too low to operate lock  

* User-ID# values: 001 to 030

Alarm Raw has a bit more information in it in JSON format but basically mirrors the Alarm Channel.

Battery Level is the amount of battery left and refreshingly it sees to be pretty accurate as opposed to some devices that happily report 100% until 30 seconds before it goes to 0%.

I’ve had this installed and configured since security was added to the binding (2.3 release?) and am currently running 2.5 M1.

So either there are two different 914s or something is weird going on.

Here are my Items:

Switch aBackDoor_Lock "Back Door"
    { channel="zwave:device:dongle:node13:lock_door"}

Number vBackDoor_Alarm "Back Door Alarm [MAP(locks.map):%s]"
    { channel="zwave:device:dongle:node13:alarm_number"}

String vBackDoor_User "Back Door User [JSONPATH($.value):%s]"
    <parents_2_3>
    { channel="zwave:device:dongle:node13:alarm_raw"}

The map file is

0=None
21=Locked Manually
22=Unlocked Manually
26=Lock Jammed
27=Lock Auto Secured
17=Lock Jammed
18=Locked By Code
19=Unlocked By Code
23=Lock Jammed
24=Locked Remotely
25=Unlocked Remotely
112=New User Code
32=All User Codes Removed
161=Failed User Code Attempt
162=Attempted Access Outside Schedule
167=Low Battery
168=Critical Battery Level
169=Battery Too Low to Operate
-=Unknown
NULL=Unknown
1 Like

There is a 914TRL (yours) and 914C (OP’s) in the database, and they are configured differently.

Ah, yeah that would apparently do it. I wonder if the 914TRL actually supports different things than the 914C? Seems nuts to use different radio/mcu hardware and firmware for the same lock (aside from the keypad), but crazier things have happened.

XMl file attached. Thanks.

network_db5567aa__node_18.xml (12.8 KB)

@5iver I’m having some confusion around understanding how to see what your script is going to pull vs what is already in place. All I can see is “2.5.0-snapshot”. How can I look to see the zwave snapshot builds vs what I already have? Thanks.

I’m not clear on what you are asking. The script will pull down th latest snapshot version of the binding. If you want to confirm before running the script that there is a newer version available, you would need to download the jar, open it (it’s just a compressed file), open /META-INF/MANIFEST.MF, and check the version number. Then run list -s |grep zwave in the Karaf console to see the version you are currently running.

Since the change you are looking for was a change in the Thing definition (added a Channel), you’ll need to delete the Thing for the lock and rediscover. The script instructs you to do this a couple times :slightly_smiling_face:. This does not mean exclude and reinclude, it’s just deleting the Thing so that the updated Thing definition in the binding is used. I don’t remember if this is needed though for newly added channels, or if it’s only needed for updated Channels.

Ok, thanks. That answered my questions. I did an update of the zwave binding last night and deleted/rediscovered the lock, but the new alarm channel did not appear. I will try to dig into things and see if the snapshot I have now should have the new channel.