Yale deadbolt wrong status on ZwaveJS?

Configuration Z-Wave
61

Ah, ok…interesting. Well at least I found a way to get it working without having to take the thing apart and trip the tamper alarm.

Odd thing is it LOOKED like it was listed in the “debug” field on the ZwaveJS and simply running it once didn’t seem to make a difference until I jumped thru more hoops.

62

Alright…It looks like I finally have some time to mess with this, however…I know this is going to sound dumb, and I’m sure the answer is obvious, but where do I find the Z-Wave device ID for the lock? I noticed in your code that your ID is: “c5b2bbe667f11062ecea27ead06b8705”, yet the only device ID I see in my config for each device is the two digit node ID (ie “14”) …I assume this isn’t the same thing?

63

Easiest way to get the device_id field value is get it off an event from your lock under Home Assistant Developer Tools page:
Developer Tools > Events
Listen for: “zwave_js_notification”
Then trigger door unlock/lock and observe fields

I think you could also go thru the Automations GUI and build a new “event” automation with your lock then switch to YAML view and copy what it populates.

1 Like
64

I took this and made an automation, because all I care about is the notifications. However, with my Yale YRD256 locks, I’m not getting a peep through zwave_js_notifcation when the lock is jammed. Any suggestions as to what event to find these in, and/or how to enable them?

- alias: Doors Lock Status
  id: doors_lock_status
  mode: parallel
  variables:
    doors:
      edeadbeef0123456789abcdef7:
        id: front_door
        friendly_name: Front Door
      8deadbeef0123456789abcdef4:
        id: kitchen_south_door
        friendly_name: Kitchen South Door
      7deadbeef0123456789abcdef3:
        id: laundry_door
        friendly_name: Laundry Door
      6deadbeef0123456789abcdef2:
        id: mud_room_door
        friendly_name: Mud Room Door
      4deadbeef0123456789abcdefb:
        id: garage_human_door
        friendly_name: Garage Human Door
    events:
      1:
        friendly_name: locked manually
      2:
        friendly_name: unlocked manually
      3:
        friendly_name: locked via wireless
      4:
        friendly_name: unlocked via wireless
      9:
        friendly_name: auto-lock
      12:
        friendly_name: all user codes erased
      13:
        friendly_name: deleted user code
      14:
        friendly_name: added user code
      18:
        friendly_name: master code changed at keypad
    people:
      251:
        friendly_name: Master Code
      1:
        friendly_name: Larry
      2:
        friendly_name: Curly
      3:
        friendly_name: Moe
      4:
        friendly_name: Harpo
      5:
        friendly_name: Groucho
      6:
        friendly_name: Zeppo
  trigger:
    platform: event
    event_type: zwave_js_notification
  condition:
    - "{{ trigger.event.data.label == 'Access Control' }}"
    - "{{ trigger.event.data.device_id in doors }}"
  action:
    - choose:
        - conditions:
            - "{{ trigger.event.data.event in events }}"
          sequence:
            - service: notify.pushover
              data_template:
                message: >
                  {{ doors[trigger.event.data.device_id].friendly_name }}
                  {{ events[trigger.event.data.event].friendly_name }}
        - conditions:
            - "{{ trigger.event.data.event == 6 }}"
          sequence:
            - service: notify.pushover
              data_template:
                message: >
                  {{ doors[trigger.event.data.device_id].friendly_name }} unlocked by
                  {{ people[trigger.event.data.parameters.userId].friendly_name }}
1 Like
65

Isn’t there a “Lock Jammed” sensor exposed?

66

There is, but it isn’t consistent. It doesn’t update to “off” after the lock isn’t jammed anymore.

1 Like
67

The sensor I built in the earlier post I found they are not all events, some like jammed, lockout, power-restored, and “unknown legacy alarm-code/level” come thru as zwave_js.value_updated type instead.

I had to use the convoluted way of intercepting the value updated trigger because the built in sensors are broken and forever show jammed and lockout without resetting when the bolt cycles like they should. Seems to be some kind of out-standing bug with how the new zwave stuff doesn’t handle it properly.

68

If the lock never reports that the jam has cleared, there’s no way for zwavejs to know this.

69

This was never a problem with the old z-wave though? The lock documentation says that its cleared by operating…and by definition if it sends the update that it was cycled it can’t be both operating and jammed at the same time.

There was no way for the lock to report that the jam has cleared separately. The ZwaveJS identifies it as a v4 notification class which has no clear/idle message and should handle it accordingly by clearing the status when the lock reports a new successful status of locked or unlocked. Its a bug, and there has been a bug report for quite some time. The lock is working properly, the Zwave hub/software is not.

See also: Make handle idling of "Lock Jammed" variable smarter · Issue #1543 · zwave-js/node-zwave-js · GitHub

Until that’s fixed, the best thing I know of is something that monitors the events like the template trigger sensor I built earlier in this thread which tracks the status more like the old z-wave system used to in a single status and thus avoids the bug by overwriting the status of “jammed” as soon as the next status comes in.

2 Likes
70

The old zwave didn’t stick to the spec like zwavejs does.

Right and as far as I am aware Al’s working on that, per your link to the github issue.

I think you can issue a ‘Refresh Value’ on the jammed entity when the lock cycles from locked to unlocked or vice-versa and see if that “resets” the jammed status.

71

Is there documentation on how to do that? I’ve not seen anything on that before, and it also shows incorrect in the ZwaveJS to MQTT web-UI control panel, its not just Home Assistant not refreshing.

72

You’d use service: zwave_js.refresh_value and whatever it needs.

Check Dev-tools → Services for more info

73

Just tried the suggested service with my Yale locks and unfortunately it did not clear the jam state. I’m under the impression this is a bug with Z-wave JS as well.

74

Matt - I FINALLY got around to installing this on one of my locks last night and after a restart or two I got it working flawlessly! I just wanted to thank you again for the time and effort you put into creating and sharing this project, my Yale lock works like it did under the OG HA Z-wave integration again! One question before I add the other two locks, do you see any issues adding them to the same .yaml file, or do I need to create a separate YAML file for each one? I would prefer to keep it all housed in the same one, but it’s also not a deal-breaker.

Thanks again! This is brilliant!

1 Like
75

As long as you can keep your variable names straight I don’t see why it wouldn’t work in one file.

I personally like to have one lock per file (and name like back_door_lock_status.yaml), and then I can copy the YAML file and do a find/replace on the variable names/values to get it quickly deployed the same way…but that’s just my personal preference to keep myself organized. I find it also makes it easier to share when I have one copy of just what’s needed in a single file vs having to sanitize multiple instances of stuff.

Also no reason it has to be under packages, can certainly put it in the appropriate sensor/integration/main file or find a way to input it thru the GUI however you like. I’m just a fan of packages for my own organization.

I’ve still not tested the low battery indication completely…because mine haven’t run low yet. If I eventually find it doesn’t work as I expect I’ll update that too when I finally get to see what happens when we run one of ours low.

1 Like
76

Just wanted to post an update so hopefully people will see, I’ve made a modification to this to account for low-battery alert (now that I finally ran one down enough to be low).

It will work like the “old way” so you’ll see the status briefly show “Unlocked by slot X” or whatever, and then when it gets the low-battery event a moment later it’ll overwrite the status with “Low Battery”.

I prefer this behavior personally as it draws extra attention to it on my dashboard (and still passes-thru the other status in history and to trigger other stuff), but if others prefer a separate battery-only sensor from the last-lock-unlock status, a new sensor (or binary-sensor) could be constructed for “low battery” by duplicating the code I wrote and eliminate everything except for “power applied” and “battery low” conditions. This way the “low” would stick until the batteries are removed and reinstalled, and installing new batteries would reset the low-battery status reliably.

Same post with new YAML… Yale deadbolt wrong status on ZwaveJS? - #54 by mmiller7

I may let it go longer and see if I can trip the “too low to operate” status and add that in coming weeks, but no guarantee.

77

FYI, alarmLevel/Type should be supported again as of Z-Wave JS 9.6.0, if you wanted to revive the old approach.

1 Like
78

I wonder if ZwaveJS2MQTT will pick that up (that’s what I use, better UI for debugging)

79

I installed the latest Docker image of zwavejs2mqtt last night and mine is now showing both values.

1 Like
80

Just thought I’d update that since the alarmtype and alarmlevel now seen to be working properly I rolled back to my original templates which seemed to more reliably handle status of “low battery” overriding all other status messages…after getting locked out because I was unaware it was THAT low since the event only triggered once but the alarmlevel/alarmtype would trigger EVERY time the lock operated nagging me to replace batteries.