- 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: best way to remotely lock/unlock Weiser 620
- Please post configurations (if applicable):
- Aeotec Z-stick Gen5, Z-Wave binding updated with latest ks620_0_0.xml
This is a follow-on to https://community.openhab.org/t/weiser-kwikset-home-connect-620-alarms/164275.
The Door_lock item is a toggle and only has the desired effect if it matches the status of the lock. Although a remote lock/unlock operation eventually updates Door_lock, the Dook_lock status does not reflect the result of manual lock operations. I created a rule triggered by Alarm_entry which updates Door_lock if the status after a manual operation is different from Door_lock.
This works, although I noticed Door_lock only changes after about six seconds, consistent with Command Poll Period set to 6000ms to avoid issues described in my previous post. I noticed recently that the door was physically locked, Door_lock showed ON (locked), but Alarm_entry showed OFF (unlocked). My best guess based on the log is that the door was unlocked and then quickly locked. In this case, I never saw an Alarm_entry for the manual lock. Alarm_raw reflects my rule triggered after the manual unlock but again, there was no Alarm_entry for the lock operation. It is as though my rule toggling Door_lock caused the lock to not send any updates when the manual lock operation happened within the Command Poll Period.
2025-07-09 15:33:43.159 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_raw' changed from {"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"1","type":"ACCESS_CONTROL","event":"1","status":"255"} to {"notification":"ACCESS_CONTROL__MANUAL_UNLOCK","level":"1","type":"ACCESS_CONTROL","event":"2","status":"255"}
2025-07-09 15:33:43.161 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_entry' changed from ON to OFF
2025-07-09 15:33:43.180 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Door_Lock' received command OFF
2025-07-09 15:33:45.041 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ZWave_Node_018_Weiser_Walkout_Alarm_raw' changed from {"notification":"ACCESS_CONTROL__MANUAL_UNLOCK","level":"1","type":"ACCESS_CONTROL","event":"2","status":"255"} to {"notification":"ACCESS_CONTROL__REMOTE_UNLOCK","level":"1","type":"ACCESS_CONTROL","event":"4","status":"255"}
Since I am using Alarm_entry to determine the lock state, I tried setting Command Poll Period to 0ms. This resulted in Alarm_entry reflecting the actual lock state, including any delays introduced by the lock mechanism itself. I had previously disabled Auto_Update via the Door_lock metadata, which meant the Door_lock display did not reflect remote lock activity. I resolved this by re-enabling Auto_Update.
Alarm_entry now correctly reflects the lock status after manual and remote lock/unlock operations, and my rule triggered by Alarm_entry is keeping Door_lock in sync with the actual lock status. However, the rule is sending unnecessary Door_lock commands to the lock. Also, I can still create an out-of-sync condition by a very fast manual unlock/lock. Should the Z-Wave binding be keeping the Door_lock value in sync with the actual lock status? If I get a chance to spin up another openHABian instance, I will take the suggestion of @apella12 to install Zwave-JS-UI and see how it handles the equivalent of Door_lock.