Z-Wave Yale Lock issue, missing AlarmLevel and AlarmType


With the release of 2021.4, I decided to bite the bullet and migrated from the depreciated Z-Wave addon to Z-Wave JS. The new Z-Wave appears to be a lot faster! Great work in modernizing the platform!

However, I have an issue with my Yale lock:
NexTouch Wireless Push Button with Z-Wave

At first the AlarmLevel and AlarmType sensor entities were missing. I eventually figured out they were simply “disabled”. I was able to enable them from the Integration setup, however their state is always “unknown”. It never gets updated, even after multiple reboots.


I also tried with zwavejs2mqtt (7.1.1), same result.

From the zwavejs2mqtt dashboard:

[8-113-0-alarmType] Alarm Type

[8-113-0-alarmLevel] Alarm Level

[8-114-0-manufacturerId] Manufacturer ID

[8-114-0-productType] Product type

[8-114-0-productId] Product ID

Is it possible to add the alarmlevel and alarmtype again since many nodered automations rely on them?

Or should I rework them to use the zwave_js_notification events (Is that where the future is headed?)

At this point, the zwave_js_notification appear to be incomplete: I get events for User Lock, User Code Added, User Code Deleted, but I don’t get them for other events like Keypad lockout.


Did you ever find a solution to this? I’m running into the same problem

I have this same problem but found this blueprint below which does everything I wanted by using zwave_js_notification in an automation.

I just ran into this problem. My zwave (deprecated) lock was working fine until today, including the alarmlevel and alarmtype entities. I migrated to zwave JS and lost them both. The lock could be locked and unlocked, but I no longer had jam warnings or notifications about who unlocked it. So I removed zwave JS and went back to zwave depreacted, and both those entities are still missing!

Has there been any update on getting AlarmLevel and AlarmType entites working for the Yale locks? Mine both show “null” no matter what the status is?

I just tried to swap over to zwave js today and I’m finding this (among a painful number of other things) as a problem myself. Enabled the “sensor” but it stays “unknown”.

To me these are absolutely critical as I had things set up to message everyone if a lock jams (so it doesn’t get left unlocked just forever trying to re-lock) as well as other things like triggering “coming home” events when an authorized code unlocks the door from outside.

Kind of defeats the point of a smart lock if you ask me.

1 Like

Yep…I feel your pain, I’m in the same boat…I’m a little shocked that this hasn’t been addressed by now. Surely there are others that have the same issues?

Looking at this template it seems to still miss a lot of possible states…

For example, some “alarming” things that I would want to have trigger alerts for something suspicious going on or malfunction:
-Motor jammed
-Deleted code
-Factory reset
-Unlocked by master-PIN (nobody should be using the master PIN)
-Master PIN changed
-Added new code
-RF module power loss-restored
-Keypad Escutcheon Removed
-Too many failed attempts
-Other unknown tamper alarm
-Low battery (reported by the lock, not by %)
-Critical battery (reported by the lock, not by %)
-Not enough power to operate

All of these have published alarm type/level combinations documented by Yale, but who knows how or if there’s a way to access that data now…and the values aren’t passed up to be sure we are getting it directly.

When I briefly thought I had the zwavejs working, I couldn’t get it to trigger events on several of these - it did show for lock/unlock but yanking/reinstalling the RF module, removing the front keypad, jamming the motor did not generate events to try and capture.

I had to revert from backups to get my stuff working again, ran out of time messing with it.

1 Like

Just wondering if there is any update? What I find strange is that these disabled sensors at least showed up for me yesterday but somehow my zwavejs/keymaster configuration got corrupted so I decided to start fresh with a new HA install and to factory reset the lock. Ever since I brought the lock back into zwavejs those sensors don’t even show up anymore.



Hopefully this will help someone, but I was enable the alarm_type sensor by going into the Z-WaveJS integration settings, just like lysdexik was alluding to.

See highlighted in green:

I just went into the settings and enabled it. I was prompted that the entity would be enabled in 30 seconds. Afterwards, I went back to the list of entities, and sure enough, it was there.

For reference, I am using the list of alarm_type codes listed here:

NOTE: If you’re trying to set up an automation where you get notified if a bad code has been entered ‘x’ number of times (for me, it’s 4 times on the Schlage Connect Camelot, model #: BE469ZP) then refer to code 161, BUT keep in mind alarm_type will only change to 161 if the code is entered 4 times in a row, incorrectly.

Possibly also useful, here’s a sensor I made to convert the alarm type/level into useful status on a Yale YRD256:

  - platform: template
        friendly_name: "Inside Garage Door Lock"
        value_template: >-
          {% set lock_entity_id = 'sensor.deadbolt_inside_garage_door' %}
          {% set alarm_type = states(lock_entity_id + '_alarmtype') | int(0) %}
          {% set alarm_level = states(lock_entity_id + '_alarmlevel') | int(0) %}

          {% if alarm_type == 0 %}
              No Report
          {% elif alarm_type == 9 %}
              Motor Jammed
          {% elif alarm_type == 10 %}
              Handing Completed
          {% elif alarm_type == 18 %}
              {% if alarm_level == 251 %}
                  Locked by Keypad Master PIN
              {% else %}
                  Locked by Keypad Slot {{ alarm_level }} PIN
              {% endif %}
          {% elif alarm_type == 19 %}
              {% if alarm_level == 251 %}
                  Unlocked by Keypad Master PIN
              {% else %}
                  Unlocked by Keypad Slot {{ alarm_level }} PIN
              {% endif %}
          {% elif alarm_type == 21 %}
              {% if alarm_level == 1 %}
                  Locked by Manual Mechanical
              {% elif alarm_level == 2 %}
                  Locked by Keypad Touch
              {% else %}
                  Locked by Manual
              {% endif %}
          {% elif alarm_type == 22 %}
              Unlock by Manual Mechanical
          {% elif alarm_type == 24 %}
              Locked by RF Remote
          {% elif alarm_type == 25 %}
              Unlocked by RF Remote
          {% elif alarm_type == 27 %}
              Locked by Auto-Lock
          {% elif alarm_type == 33 %}
              Deleted Slot {{ alarm_level }} PIN
          {% elif alarm_type == 48 %}
              Factory Reset Defaults
          {% elif alarm_type == 112 %}
              {% if alarm_level == 0 %}
                  Master PIN Changed at Keypad
              {% else %}
                  Added Slot {{ alarm_level }} PIN
              {% endif %}
          {% elif alarm_type == 113 %}
              New PIN already exists slot {{ alarm_level }}
          {% elif alarm_type == 130 %}
              Power to RF Module Restored
          {% elif alarm_type == 161 %}
              {% if alarm_level == 1 %}
                  Too many failed PIN attempts
              {% elif alarm_level == 2 %}
                  Keypad Front Escutcheon Removed
              {% else %}
                  Unknown Tamper Alarm
              {% endif %}
          {% elif alarm_type == 167 %}
              Low Battery
          {% elif alarm_type == 168 %}
              Low Battery Critical
          {% elif alarm_type == 169 %}
              Low Battery Cannot Operate
          {% else %}
              Unknown: alarm_type={{ alarm_type }}, level={{ alarm_level }}
          {% endif %}

1 Like

Now that it appears AlarmType and AlarmLevel are correctly reporting with ZWave JS and the YRD256, is there anyway with those parameters to see WHICH user-code/pin unlocked the door with the keypad? I see that AlarmType sends a 19 when a correct pin is entered, but is there any additional trailing info?

Yes, if you look at the sensor I posted above, when alarm_type is 19 (unlocked by keypad) the alarm_level contains the slot number.

          {% elif alarm_type == 19 %}
              {% if alarm_level == 251 %}
                  Unlocked by Keypad Master PIN
              {% else %}
                  Unlocked by Keypad Slot {{ alarm_level }} PIN
              {% endif %}

I derived my sensor from the hexidecimal value chart starting on page 4 of the manual

It only sends slot numbers, not actual PINs so you would need to track who’s PIN you programmed into each slot number some other way.

1 Like

Looking to alert on very similar items - did you ever figure this out?

Wouldn’t unlocked by keypad be 13

No, not 13 - that’s 0x13.
0x13 (hexidecimal, base 16) is 19 (decimal, base 10).

And yes, it does work, after you enable the alarm_type and alarm_level sensors

See Z-Wave Yale Lock issue, missing AlarmLevel and AlarmType - #11 by mmiller7

1 Like