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:
In paperui, go to the insecurely included lock Thing’s advanced settings and select “Remove Device From Controller”.
Remove the Thing from openhab.
Pull battery pack on lock, and do a factory reset.
Go to “Scan For Things” and click the zwave item.
At the same time, press the “A” button once on the lock (per Kwikset instructions).
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…
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!
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)…
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?
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
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.
@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 . 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.