I have the Kwikset 888 which has the same behavior (HA 0.90.2).
I see that there have been a few patches / workarounds in the source to help track states better but our locks don’t seem to have been fixed. I unfortunately don’t have the time or energy to work on the zwave.py source code, but I was able to come up with a quick and dirty automation to synchronize the lock state into home-assistant so that when the lock is manually opened or closed its status will be updated in HA.
What I’m doing is a hack but it seems to work ok. The basic idea is to capture the alarm type associated with manual lock and unlock and then activate the service that will set the lock state to the same state as was just performed. Luckily I found a website with details of the Alarm Type statuses. Check http://s7d5.scene7.com/is/content/BDHHI/ApplicationNote-UsingASCII-Z-Wave-Locks for details.
The state table is:
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
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)
026 001 Lock Auto Secured – Bolt Jammed (Not 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
So I set up an automation that triggers on Alarm Type 19, 22, and 25 and then sends an unlock command to the already unlocked lock, synchronizing the physical state as well as the lock entity state. Similarly when Alarm Type 18, 21, 24 or 27 is set then the lock is locked. Since in both cases the lock is already in the targeted state, nothing physical happens on the lock, but the state in HA dashboard is correctly updated.
automations.yml
- id: sync_front_door_unlocked
trigger:
- entity_id: sensor.kwikset_front_door_alarm_type
platform: state
to: '19'
- entity_id: sensor.kwikset_front_door_alarm_type
platform: state
to: '22'
condition:
- condition: state
entity_id: lock.kwikset_front_door
state: locked
action:
- data:
entity_id: lock.kwikset_front_door
service: lock.unlock
initial_state: on
- id: sync_front_door_locked
trigger:
- entity_id: sensor.kwikset_front_door_alarm_type
platform: state
to: '18'
- entity_id: sensor.kwikset_front_door_alarm_type
platform: state
to: '21'
- entity_id: sensor.kwikset_front_door_alarm_type
platform: state
to: '27'
condition:
- condition: state
entity_id: lock.kwikset_front_door
state: unlocked
action:
- data:
entity_id: lock.kwikset_front_door
service: lock.lock
initial_state: on
Probably don’t need to trigger on states 24 or 25 since those seem to reflect the status correctly , but I don’t think it hurts anything since I am guarding against loops in the condition state check.
Hope this helps until someone has time to implement a real fix in the base component.
Update: as is perhaps not surprising, my workaround has a problem if you quickly unlock and re-lock the lock inside HA’s event loop time, then the lock can lock/unlock erroneously. Not sure I can completely avoid this problem in general but am thinking of introducing a very short delay and then double-checking that the Alarm Type and Lock status are still “out of sync” before executing the service.
Update2: Removing the stanzas for state # 24 and 25 did help with the looping, so I recommend that – and the lock status seems pretty solid for me at this point.
