I recently configured a Weiser Home Connect 620 Z-Wave smart lock on a fresh openHABian 1.10.3 build running openHAB 3.4.5. I removed the lock from the door and paired it in close proximity to my Aeotec Z-Stick Gen 5. Although a Thing was created, openHAB did not recognise the device. It took a while to find the matching information at https://opensmarthouse.org/zwavedatabase/1513 since the manufacturer is now Black & Decker and the lock is listed under Kwikset. The latest xml update was not included in the openHAB 3.4.5 Z-Wave binding. I followed the instructions at https://community.openhab.org/t/update-zwave-binding-with-new-updated-device-xml/147248 including installed the Java 17 JDK. The lock was recognised as soon as I updated the binding, enabling nine channels.
I have not been able to find a programming or developer’s guide for the lock. I added Door Lock, Alarm (access), Alarm (burglar), Alarm (raw), Alarm (entry), Alarm (battery), and Battery Level. I was able to see the Battery Level in the UI. Locking/unlocking the door manually or through the keypad generated Alarm (raw) and Alarm (entry) events, although Alarm (entry) displayed “Open” when the door was locked. The UI displayed Door Lock as a switch in the ON position that did not change based on the lock state.
Alarm (raw) returns information in JSON format. For a keypad unlock, the format was
{"notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"1","level":"1","type":"ACCESS_CONTROL","event":"6","parameter-1":"1","status":"255"}
while a manual lock resulted in
{"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"1","type":"ACCESS_CONTROL","event":"1","status":"255"}
I am most interested in the event codes - odd numbers are lock events, while even numbers are unlock events. I set up a Blockly rule to extract the event code, which allowed me to verify that Alarm (entry) matched the outcome of Alarm (raw) actions.
It turns out that the Z-Wave binding translates Alarm (entry) states of ON to Open, and OFF to Closed. I installed the Map Transformation binding and created a lock.map file in $OPENHAB_CONF/transform. Some posts recommended “Add Metadata/State Description” and entering MAP(lock.map):%s in the Pattern field, but this did not work. I followed https://community.openhab.org/t/solved-transformation-issues-map/131216/8 and entered the following in the “State Description/Options field”. That changed the Dock Lock display in the UI to Locked/Unlocked. The lock.map file was no longer required. Any openHAB Rules still needed to use ON or OFF.
ON=Locked
OFF=Unlocked
Locking/unlocking the door via openHAB was inconsistent. If the Door Lock state did not match the actual lock state, nothing would happen. Sometimes changing Door Lock from ON to OFF (or vice versa) would appear to take but then the UI reverted back to the original state. The Z-Wave DEBUG log sometimes showed openHAB sending Abort commands which would get no response from the lock. In one case, the lock stopped communicating with openHAB, even though I could unlock/lock the door via the keypad - I had to remove and replace the battery to reset the lock. Bob Eckhoff in Weiser/Kwikset Home Connect 620 Alarms diagnosed the issue - the lock takes about four seconds to lock or unlock the door, but the default Command Poll Period of 1500ms was checking the lock state after 1.5 seconds. He recommended unlinking channels that I was not using and increasing the Command Poll Period to at least 5000ms. I set it to 6000ms and have not seen any more issues. I also wrote a small Blockly rule triggered by Alarm (entry) that keeps Dock Lock synchronised with the door’s lock state, at least after the first manual/keypad door operation.
I am planning to upgrade to OH4 and will post any changes required in the Weiser 620 configuration.