ZWave-JS Kwikset 910 Manual status updater

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.


Click the badge to import this Blueprint: (needs Home Assistant Core 2021.3 or higher)

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Or import this Blueprint by using the forum topic URL:

  name: Kwikset 910 Updater
  description: Updates the manual status of 910 locks.
  domain: automation
      name: alarmType Sensor for lock
      description: alarmType sensor must be enabled on lock device.
          domain: sensor
          integration: zwave_js
      name: Lock Entity
      description: Lock entity.
          domain: lock
          integration: zwave_js
  - platform: state
    entity_id: !input alarmtype_sensor
  - service: zwave_js.refresh_value
      entity_id: !input lock_entity

Hi raz0rf0x,

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

payload_template: '{"args": [{"nodeId":{{ node_id }},"commandClass": 128,"endpoint":0,"property":"level"}]}'


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.


  - platform: template
        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 %}


- alias: Front Door notification
  initial_state: true
  - 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'
  - service: notify.chris_sms
      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.


Thank you! I can’t wait to test this. This has been driving me nuts since switching over to zwaveJS.

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.

Yes. 7.0 will be out in a few days. There is usually some delay (days or a week) until the integration will support it.

Unavailable likely won’t be fixed by this. You may have something else going on.

Yeah I figured. Wanted to see if it would help.

The doorknob is like six years old so it may be time to move on.

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

That information is actually in the zwave_js event.
Looks a bit like the following if you subscribe the zwave_js event

zwave_js_event {'type': 'notification', 'domain': 'zwave_js', 'node_id': REDACTED, 'home_id': REDACTED, 'device_id': 'REDACTED', 'label': 'Keypad lock operation', 'parameters': {'userId': 0}, 'metadata': {'origin': 'LOCAL', 'time_fired': '2021-03-30T13:41:04.670075+00:00', 'context': {'id': 'REDACTED', 'parent_id': None, 'user_id': None}}} 

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.

Also confirming that this is working for me in 7.0.1

No the state does not update when manual operation manual turn by key or knob does not report

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.

the lifeline is established with my Zwave hub node if that is what you are asking that had no effect on it not reporting on a manual operation