Some of the older Kwikset 910 touchpad locks do not update the device’s status when the lock is manually operated. This automation will detect the activity from the lock on the sensor.alarmType and send a command via the zwave_js.refresh_value service to update the lock status’ value.
This new version no longer requires zwavejs2mqtt to function and this is the preferred method. It will work with either zwavejs or zwavejs2mqtt.
Many of the locks do not automatically set up the lifeline association to the controller. If the alarmType sensor does not update it may be necessary to set group 1 association to the controller node.
Blueprint
Click the badge to import this Blueprint: (needs Home Assistant Core 2021.3 or higher)
Or import this Blueprint by using the forum topic URL:
blueprint:
name: Kwikset 910 Updater
description: Updates the manual status of 910 locks.
domain: automation
input:
alarmtype_sensor:
name: alarmType Sensor for lock
description: alarmType sensor must be enabled on lock device.
selector:
entity:
domain: sensor
integration: zwave_js
lock_entity:
name: Lock Entity
description: Lock entity.
selector:
entity:
domain: lock
integration: zwave_js
trigger:
- platform: state
entity_id: !input alarmtype_sensor
action:
- service: zwave_js.refresh_value
target:
entity_id: !input lock_entity
This is an absolute lifesaver for me, I love the new ZWave implementation, but it wasn’t updating my lock and I couldn’t figure out how to do it.
I tried to figure this out myself by reading the API info but I am pretty amateur with MQTT. Is there any way to have this pull the battery status too? I’ve noticed that my battery updates are pretty sporadic. I noticed in the OZW implementation, when the alarm state changed, it did a RefreshClassValue. Maybe there’s something similar with this one?
EDIT: I figured it out. Added an additional automation with
Thanks for this! It got me looking around and I realized with zwavejs we lost the lock alarmtype status translations. Tonight I put this together to make this happen, I also updated my notification automation to include messages that I care about. I have not fully tested this (mainly because its hard to generate some of these errors), I’ll come back and edit this if I find any problems.
sensor:
- platform: template
sensors:
front_door_lock_status:
friendly_name: "Front door lock status"
value_template: >-
{% if is_state('sensor.front_door_lock_alarmtype', '0') %}
No Status Reported
{% elif is_state('sensor.front_door_lock_alarmtype', '9') %}
Lock Jammed
{% elif is_state('sensor.front_door_lock_alarmtype', '16') %}
Keypad Unlock
{% elif is_state('sensor.front_door_lock_alarmtype', '17') %}
Keypad Lock Jammed
{% elif is_state('sensor.front_door_lock_alarmtype', '18') %}
Keypad Lock
{% elif is_state('sensor.front_door_lock_alarmtype', '19') %}
Keypad Unlock
{% elif is_state('sensor.front_door_lock_alarmtype', '21') %}
Manual Lock
{% elif is_state('sensor.front_door_lock_alarmtype', '22') %}
Manual Unlock
{% elif is_state('sensor.front_door_lock_alarmtype', '23') %}
RF Lock Jammed
{% elif is_state('sensor.front_door_lock_alarmtype', '24') %}
RF Lock
{% elif is_state('sensor.front_door_lock_alarmtype', '25') %}
RF Unlock
{% elif is_state('sensor.front_door_lock_alarmtype', '26') %}
Auto Lock Jammed
{% elif is_state('sensor.front_door_lock_alarmtype', '27') %}
Auto Lock
{% elif is_state('sensor.front_door_lock_alarmtype', '32') %}
All Codes Deleted
{% elif is_state('sensor.front_door_lock_alarmtype', '33') %}
Code Deleted
{% elif is_state('sensor.front_door_lock_alarmtype', '112') %}
Code Changed
{% elif is_state('sensor.front_door_lock_alarmtype', '113') %}
Duplicate Code
{% elif is_state('sensor.front_door_lock_alarmtype', '161') %}
Bad Code Entered
{% elif is_state('sensor.front_door_lock_alarmtype', '162') %}
Lock Code Attempt Outside of Schedule
{% elif is_state('sensor.front_door_lock_alarmtype', '167') %}
Battery Low
{% elif is_state('sensor.front_door_lock_alarmtype', '168') %}
Battery Critical
{% elif is_state('sensor.front_door_lock_alarmtype', '169') %}
Battery Too Low To Operate Lock
{% elif is_state('sensor.basement_door_lock_alarmtype', 'unknown') %}
None Reported
{% else %}
Unknown alarm type: {{ states('sensor.front_door_lock_alarmtype') }}
{% endif %}
automation:
- alias: Front Door notification
initial_state: true
trigger:
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '9'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '17'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '23'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '26'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '32'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '33'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '112'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '113'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '161'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '162'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '168'
- platform: state
entity_id: sensor.front_door_lock_alarmtype
to: '169'
action:
- service: notify.chris_sms
data:
title: Front Door Alarm
message: 'Lock status has changed to: {{ states.sensor.front_door_lock_status.state }}'
Edit: Fixed the notification message, I had a bad state.entity defined. I also updated the sensor message for when there is no status, this may happen upon a full restart of HASS. Lastly, I noticed that zwavejs/HASS is a little buggy when it comes to updates, sometimes if you watch the zwavejs logs you will see that the lock is updating the state but HASS will not update, not sure why, I’m sure in time this will get resolved.
FYI, this should now be fixed in version 7.0 of node-zwave-js. Once you’re running that make sure you disable any automation or you’ll be polling unnecessarily.
Do you know which version of the official zwavejs add on this got incorporated into? I’ve recently moved over from my Vera mini and it’s not giving me an alarm type. Saying it’s unavailable. Yes it’s been included in secure mode.
This is in 7.0.0. the official add-on looks to be 6.6.3.
Edit: I guess I should say that the ADDON version (0.1.13) does not yet have this capability. The unofficial ZWavejs2MQTT add-on is also using 6.6.3.
its is not fixed in 7.0 still does not show how the lock was activated like it did in in Zwave Depreciated nor does it update the status of a manual change of the lock either
well even on the zwavejs2mqqt ui it does not show anything that I stated it does not update a manual lock or unlock so as stated 7.0 did not address the issue behaves exactly like 6.6.3
Maybe you’re conflating two different issues? The team stated they were fixing state reporting when the lock is used, which they did, or at least it’s working for me. I do not believe they promised attributes to show how the lock was actuated. So I disagree in my situation, they did fix state reporting as promsied.
I can report that not only did they fix state reporting, that also now when triggered the zwave_js_event has all the information about how it was actuated. I was therefor able to alter my automations to report the manner in which the lock was actuated and the keypad code that was used, when relevant.
At the end of the instructions above I mention that sometimes the lifeline association isn’t automatically created when this lock joins the network. Have you verified that this isn’t the problem for you?
You can verify this in zwavejs2mqtt control panel.
Not sure what you are getting at the locks work flawless when control is done thru zwave so the signal is fine it just doesn’t report manual operation at the lock
If the lock doesn’t seem to be reporting the lock status it may mean that the lifeline association, in which the lock is told where to send alert messages to, has not been established. Under most circumstances this is automatically done at enrollment. It has come up frequently enough (and has happened to myself) that this step is missed on this particular lock. It will have no effect on the regular operation of the lock outside of not reporting statuses back to the controller. This is why I bring it up in the setup instructions for the blueprint.
Since it seems you are experiencing this particular problem I am asking if you have verified that the lifeline (group 1) association has been made to your controller node.
