Weiser/Kwikset Home Connect 620 Alarms

Setup, Configuration and Use Runtime
, ,
1
  • Platform information:
    • Hardware: _raspberry pi 3B
    • OS: openhabian 1.10.3/Raspbian bookworm 32-bit
    • Java Runtime Environment: 17
    • openHAB version: 3.4.5
  • Issue of the topic: interpreting lock events
  • Please post configurations (if applicable):
    • Aeotec Z-stick Gen5, Z-Wave binding updated with latest ks620_0_0.xml

The lock successfully paired with OpenHAB in secure mode. I am seeing Alarm_raw events where JSON “event” 1 and 5 indicate that the door has been locked, while 2 and 6 indicate that the door has been unlocked. I can distinguish between manual and keypad/button operations. When the keypad is used to unlock the door, I can tell which code was used. These events are followed by Alarm_entry events where ON/OFF are associated with the door entering a locked/unlocked state. I have not been able to find documentation for the access, burglar, or power events.

The Door_Lock channel allows me to remotely lock the door. It appears to toggle the door’s lock, in which case I see Alarm_raw and Alarm_entry events. However, sometimes the physical lock state does not change. I have not done enough testing to figure out the conditions when this happens although I did get a DEBUG log. I have not figured out what the software state of the Door_Lock item means - sometime the change I make to the item state sticks, sometimes it reverts back to its original state. Also, I have seen one Door_Lock event when there were no lock actions, either triggered at the lock or via OpenHAB.

Am I on the right track? Has anyone seen a detailed programming guide for the 620? So far, Weiser Support has not been helpful.

2

I don’t have the device and unfortunately, the reference material included with the ZW DB entry is not helpful (IMO). I did find this on another site.

As to the other alarms, these are frequently not set up correctly for what the device sends (should be found in the debug. Use the debug viewer for clearer analysis. I did put together a table of the alarms related to how the ZW binding processes them, but what the device is sending is usually found in the manual.
alarm-channel-mapping2.pdf (525.3 KB)
For example, note that alarm_access has no events that the ZW binding recognizes, so that will never be triggered.

3

@apella12 Thanks for the fast response! I would expect that information from another site could be entered into the Thing configuration, but even with “Show Advanced”, the options presented by OpenHAB are Polling Period, Command Polling Period, Lock Timeout, and 250 pairs of User Labels/Codes. The alarm-channel-mapping2.pdf PDF looks interesting - I will have a look at the debug logs to see what events are being passed. I will also see if I can escalate with Kwikset to get some official documentation for the Door_Lock operation. Unfortunately, the Kwikset Android/iOS app only supports Halo and Aura locks.

4

The device in the OH ZW DB does not have any parameters but those can be added with write access. (see ZW DB Blog).

One other thought is to look at the manuals for the other B&D locks in the ZW DB for clues.

5

I successfully tested and interpreted status updates initiated by the lock.

  • Alarm_raw reports after locking/unlocking the door manually, via the keypad, or remotely from OpenHAB. Odd event codes indicate the door was locked, even event codes are associate with unlock events. Alarm_raw includes a “level” value which I have not yet deciphered.
  • Alarm_entry reports ON if the door is locked, OFF if the door is unlocked I was initially confused because the UI shows Open when the door is locked. I verified that the Alarm_raw action matches the resulting Alarm_entry state.

I am having less success with Door_lock. The UI shows a switch, but the setting does not match the current lock status. I can both lock and unlock the door using Door_lock, but every other operation does not change the lock state. Sometimes changing the Door_lock state leaves it in the changed state, sometimes the state reverts to the previous state. I captured a debug log of multiple Door_lock operations.

13:37 door unlocked, door_lock=ON, switched OFF, stayed OFF, door still unlocked, debug log shows an initial slow ACK, a DOOR_LOCK_SET command, then OpenHAB sending multiple “Abort” commands and getting NO ACK or a slow ACK after 5-8 seconds.

2025-06-05 13:37:08.529 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command OFF
2025-06-05 13:37:08.531 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become OFF
2025-06-05 13:37:08.544 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from ON to OFF

13:41 door unlocked, door_lock=OFF, switched ON, went back OFF, door locked, debug log shows the same slow ACK, a DOOR_LOCK_SET command, followed by the Weiser lock reporting that the door is locked

2025-06-05 13:41:43.041 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command ON
2025-06-05 13:41:43.043 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become ON
2025-06-05 13:41:43.047 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from OFF to ON
2025-06-05 13:41:45.247 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from ON to OFF
2025-06-05 13:41:47.160 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_raw' changed from {"notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"1","level":"1","type":"ACCESS_CONTROL","event":"6","parameter-1":"1","status":"255"} to {"notification":"ACCESS_CONTROL__REMOTE_LOCK","level":"1","type":"ACCESS_CONTROL","event":"3","status":"255"}
2025-06-05 13:41:47.165 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_entry' changed from OFF to ON

13:45 door locked, door_lock=OFF, switched ON, stayed ON, door still locked, debug log similar to the one at 13:37 except only one Abort sent.

2025-06-05 13:45:20.663 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command ON
2025-06-05 13:45:20.665 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become ON
2025-06-05 13:45:20.669 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from OFF to ON

13:50 door locked, door_lock=ON, switched OFF, went back ON, door unlocked, debug log similar to the one at 13:41

2025-06-05 13:50:14.777 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command OFF
2025-06-05 13:50:14.778 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become OFF
2025-06-05 13:50:14.783 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from ON to OFF
2025-06-05 13:50:16.993 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from OFF to ON
2025-06-05 13:50:18.857 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_raw' changed from {"notification":"ACCESS_CONTROL__REMOTE_LOCK","level":"1","type":"ACCESS_CONTROL","event":"3","status":"255"} to {"notification":"ACCESS_CONTROL__REMOTE_UNLOCK","level":"1","type":"ACCESS_CONTROL","event":"4","status":"255"}
2025-06-05 13:50:18.862 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_entry' changed from ON to OFF

During testing earlier in the week, I issued the above commands about once a minute. The lock appeared to stop responding to any door_lock requests. I was getting a few lock-initiated updates but not consistently. Disabling/enabling the lock Thing did nothing. I restarted OpenHAB and noticed lots of debug traffic. OpenHAB was interrogating all 250 user codes, getting errors, and retrying the same code multiple times. After 30 minutes, it had only done about 70 codes. Even after OpenHAB had finished, I was only seeming intermittent events when I locked/unlocked the door manually or with the keypad. I removed and replaced the battery in the lock which restored normal operation.

I spoke with Weiser/Kwikset support who seemed reluctant to provide details of the Weiser 620 Z-Wave programming. They thought I might be experiencing network delays and are sending out a ‘long range’ version of the lock. The debug logs above suggest some network delays yet they only seem to be an issue when I am sending Door_lock commands - lock-initiated events are received even if triggered in quick succession. I see the odd slow ACK RECEIVED, usually when I start a testing run.

Any idea on what might be happening?
zwave-20250605-13xx.log (407.3 KB)

6

I hunted around for other programming manuals for Kwikset locks without success. All I find are install guides that show how to manually program the locks and troubleshooting guides, again for the lock itself.

7

The logs do appear to show problems with communication. The general flow is command is issued and at 1.5 seconds the device is polled on all linked items. On the first OFF at 37 min, it takes 16 seconds before that is updated. If you have autoupdate on, it probably shows your change right away. The ON at 41 min seems to happen quickly but returns an OFF reading. The second ON at 45 minutes never returns the poll, so with auto update would appear to work. Then the OFF at 50 min returns a quick poll but returns an ON.

I don’t think this is a cure, but to reduce the poll traffic I would unlink alarm_access, alarm_burglar and alarm_battery and probably the alarm_raw (because it is responding to the same as alarm_entry. This would leave the polling of the door_lock, alarm_entry and the battery_level. Also I would lengthen the command poll from 1.5 seconds to 5 seconds so the lock would have a chance to reflect the command

Edit: Pulled some elements out of the java code for reference

Not in OpenHab, but part of the raw
Window/door handle is open	0x18	V8  // 24
Window/door handle is closed	0x19	V8  // 25

Sample of OH options
ACCESS_CONTROL__NONE("ACCESS_CONTROL", 0),
        ACCESS_CONTROL__MANUAL_LOCK("ACCESS_CONTROL", 1),
        ACCESS_CONTROL__MANUAL_UNLOCK("ACCESS_CONTROL", 2),
        ACCESS_CONTROL__REMOTE_LOCK("ACCESS_CONTROL", 3),
        ACCESS_CONTROL__REMOTE_UNLOCK("ACCESS_CONTROL", 4),
        ACCESS_CONTROL__KEYPAD_LOCK("ACCESS_CONTROL", 5),
        ACCESS_CONTROL__KEYPAD_UNLOCK("ACCESS_CONTROL", 6),

// Entry alarms triggered based number
        events = new HashMap<NotificationEvent, State>();
        events.put(NotificationEvent.ACCESS_CONTROL__NONE, OnOffType.ON);
        events.put(NotificationEvent.ACCESS_CONTROL__AUTO_LOCK, OnOffType.ON);
        events.put(NotificationEvent.ACCESS_CONTROL__REMOTE_LOCK, OnOffType.ON);
        events.put(NotificationEvent.ACCESS_CONTROL__KEYPAD_LOCK, OnOffType.ON);
        events.put(NotificationEvent.ACCESS_CONTROL__MANUAL_LOCK, OnOffType.ON);
        events.put(NotificationEvent.ACCESS_CONTROL__REMOTE_UNLOCK, OnOffType.OFF);
        events.put(NotificationEvent.ACCESS_CONTROL__KEYPAD_UNLOCK, OnOffType.OFF);
        events.put(NotificationEvent.ACCESS_CONTROL__MANUAL_UNLOCK, OnOffType.OFF);
        notifications.put("alarm_entry", events);
8

I recall the timeouts happened when OpenHAB appeared to be Abort commands to the Weiser lock. I implemented your recommendations and tested when the Door_lock state did not match the actual lock state (nothing happened) and where they matched (door locked or unlocked as expected). It takes about four seconds from issuing the lock/unlock command before the lock physically completes the operation. Everything worked as expected with no odd reversion of the Door_lock state. Once the Door_lock matched the physical lock, remote actions triggered the expected result.

16:04 door locked, Door_lock=OFF, switched Door_lock ON, stayed ON, door still locked

2025-06-07 16:04:29.424 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command ON
2025-06-07 16:04:29.426 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become ON
2025-06-07 16:04:29.437 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from OFF to ON
your code goes here

16:06 door locked, Door_lock=ON, switched Door_lock OFF, stayed OFF, door unlocked

2025-06-07 16:06:18.938 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command OFF
2025-06-07 16:06:18.940 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become OFF
2025-06-07 16:06:18.945 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from ON to OFF
2025-06-07 16:06:22.768 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_entry' changed from ON to OFF

16:07 door unlocked, Door_lock=OFF, switched Door_lock ON, stayed ON, door locked

2025-06-07 16:07:10.530 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command ON
2025-06-07 16:07:10.532 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' predicted to become ON
2025-06-07 16:07:10.534 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' changed from OFF to ON
2025-06-07 16:07:14.635 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_entry' changed from OFF to ON

Things were working much better than before. There were no ‘abort’ commands until the last test at 16:07. I was watching the lock - in all three tests, the lock either ignored (first test where Door_lock status did not match lock state) the remote command or completed the command in under five seconds. I compared the Z-Wave viewer information for the third test with the second test starting at 16:06:18. At 16:06:22.765, the lock sent alarm_raw and alarm_entry, which I also see at 16:07:14.630 in the third test. In both tests, OpenHAB does a SendData and gets and ACK/ACCEPTED BY CONTROLLER. In the third test, there is no “RX REQ ApplicationCommandHandler SECURITY_NONCE_REPORT NONCE ID 14 0 /128” and OpenHAB sends an ‘abort’ after five seconds. I only noticed this after turning DEBUG off and checking the detailed logs.

I subsequently did several successful remote lock/unlock commends to the door until 16:31 when the lock stopped responding. I thought the lock was hung and was about to remove/replace the battery when the lock started working again. I am not sure if the ‘abort’ commands were related or whether it had something to do with issuing lock/unlock commands too rapidly. I was standing beside the lock and waited for the lock to physically change before issuing another remote command, but possibly OpenHAB had not completed all processing. I am going to let everything settle down and see if I can reproduce the unresponsive lock with DEBUG logging enabled.
zwave-20250607-16xx.log (239.4 KB)

9

It does look a little better to me (7 seconds on the first and 6 on the second). Are you using the ZW log viewer for screening? The event logs are misleading because of auto update. I have been looking at the State Updates in the viewer. That is when the poll was received by the binding.

On the last one I see the state update at 07:42, not 07:14. There is still congestion (28 seconds). Part of the problem is when a command times out (abort) the binding needs to get a new security code again first before sending the command again and it just cascades. The general pattern is the binding aborts after 5 seconds, then cancels after three tries.

kwikset2 -a 2025-06-07 190513
kwikset2 -a 2025-06-07 190513736×848 101 KB

kwikset2 -b 2025-06-07 190513
kwikset2 -b 2025-06-07 190513769×468 59 KB

The new only other suggestion is to wait a long time between commands in order to let the polls clear.

10

Thanks for helping me better understand the debug log. What is odd is that the lock sent alarm_raw and alarm_entry updates starting at 16:07:14.630, more that five seconds before the first abort. The debug log is not filtered so there should not have been other Z-Wave traffic. Weiser/Kwikset is sending me a Long Range 620 lock which suggests this may be a known issue. I have increased the Command Poll Period to 6000ms and will keep testing.

Is there any way to get the Door_lock state to reflect manual changes to the lock? Right now there is a 50% chance that the Door_lock state is not correct, requiring two toggles to get the physical lock into the intended state. This sounds like a different problem - I can open up an new thread.

11

Given time, it should be reflected as alarm_entry includes the manual options (see above). Also the alarm_raw should show events 1 and 2 instead of 3 and 4. You could use a rule to extract from the JSON.

One investigation you might wish to explore is the use of ZUI based on the Zwave-js application. There is too much to explain here, but on the plus side

  1. It has S2 security which I understand is more efficient
  2. It supports long range inclusion. The long-range lock you are getting has a newer chip, so should be better, even with the OH ZW, but won’t be long-range included. I’m assuming you are in North America where the long-range inclusion is permitted. Probably need to google Zwave long range.
    On the minus side
  3. ZUI really should be added as docker (for ease of use), so will also need docker and MQTT. There is a ZUI binding in the pipeline for OH5 to avoid MQTT. However, with OH5 the Rpi3b needs to use a 64-bit O/S, so I don’t think it will all fit. I did have a 32-bit Rpi3b running OH and ZUI in docker containers a year or so ago.
12

I saw one instance yesterday where the Door_lock state changed about an hour after a manual door unlock. However, subsequent manual door lock changes were not picked up. I created a Blockly rule triggered by Alarm_entry to keep Door_link in sync. I was concerned that it could the lock to freeze but so far the rule seems to be working.

I found your ZUI post last week while searching for Weiser/Kwikset developer information. I am reluctant to add more complexity to my OpenHAB environment - I would rather invest in upgrading to OH4.

13

No problem. Just felt I needed to suggest it because of the long range comment and it seems the security is taking up a lot of time.

14

Thanks to Bob Eckhoff’s analysis and suggestion to increase the “Command Poll Period”, the Weiser 620 lock and openHAB have been communicating without any issues. I summarized what I ended up implementing at Weiser/Kwikset Home Connect 620 Setup on OH3.