Issue with Schlage after ZwaveJS migration

Hello!

I migrated to ZwaveJS last sunday and so far it went well… however, since that time it seems like the lock status of my schlage is not updated. If I manually unlock it, the entity value will stay at “locked”.

It seems like the event is sent by the lock, because I can see the event in the zwave_js_event, for both unlock and lock events…

Any ideas ? It’s not a big annoyance but the dashboard is confusing because it does not show the right value.

{
    "event_type": "zwave_js_event",
    "data": {
        "type": "notification",
        "domain": "zwave_js",
        "node_id": 22,
        "home_id": 3544305580,
        "device_id": "cd90677f739b57ffece233bbc4737b26",
        "label": "Manual lock operation",
        "parameters": {}
    },
    "origin": "LOCAL",
    "time_fired": "2021-02-09T21:57:58.340694+00:00",
    "context": {
        "id": "2ad0d1b5f7e557f76f2b4998b9e194d0",
        "parent_id": null,
        "user_id": null
    }
}

{
    "event_type": "zwave_js_event",
    "data": {
        "type": "notification",
        "domain": "zwave_js",
        "node_id": 22,
        "home_id": 3544305580,
        "device_id": "cd90677f739b57ffece233bbc4737b26",
        "label": "Manual unlock operation",
        "parameters": {}
    },
    "origin": "LOCAL",
    "time_fired": "2021-02-09T21:58:02.787848+00:00",
    "context": {
        "id": "ba605ed752ca3f76ce460d6de55a8975",
        "parent_id": null,
        "user_id": null
    }
}

Also I’m not sure if it’s normal but the lock and unlock events are identical, except for the labels. It’s strange to rely on a label field in order to determine the nature of the event but anyway.

Your lock might rely on polling for state updates. Not yet supported in ZWaveJS

1 Like

Hum, OK, thanks for the info.

I’m trying to workaround this by catching the event, do a pattern matching on the value and then unlock or lock based on the value.

Do you think it should work? I’m trying to figure out what would be the correct syntax:


alias: 'WORKAROUND: fix unlock serrure entrée'
description: ''
trigger:
  - platform: event
    event_type: zwave_js_event
    event_data:
      device_id: cd90677f739b57ffece233bbc4737b26
condition:
  - condition: template
    value_template: '{{ ''ON'' if ''Manual unlock operation'' in value else ''OFF'' }}'
action:
  - device_id: cd90677f739b57ffece233bbc4737b26
    domain: lock
    entity_id: lock.entree_serrure_current_unlock_mode
    type: lock
mode: single

When the lock is unlocked with the keypad, is the user number present in the event that fires? I make use of that in my Home Assistant instance quite a bit, and haven’t done the migration off the old, original Z-Wave integration yet… Just want to include addressing this in my plans, somehow.

Sounds like your issue might have been fix in the release that came out today. Z-Wave JS 0.1.6 is available

I have the same lock. Since upgrading to zwave-js I’ve noticed that my securty key was in the incorrect format so the lock has not been working for me and I had ignored it. I plan to exclude and include it as a secure node when it’s not -30 outside.

1 Like

OK the workaround for the manual unlock is this:


alias: 'WORKAROUND: fix unlock serrure entrée'
description: ''
trigger:
  - platform: event
    event_type: zwave_js_event
    event_data:
      device_id: cd90677f739b57ffece233bbc4737b26
      label: Manual unlock operation
condition: []
action:
  - device_id: cd90677f739b57ffece233bbc4737b26
    domain: lock
    entity_id: lock.entree_serrure_current_lock_mode
    type: unlock
mode: single

So I now have something to fix it.

Yes it’s there:


        "label": "Keypad unlock operation",
        "parameters": {
            "userId": 3
        }

Thanks! That’s good to see. I would agree with your comment that matching the text string seems a little fraught with peril. I wonder if that will remain constant in the face of i8n translations that might occur…

I upgraded to 0.1.6 but I’m still having the issue. I will keep the workaround in place for now.

Your message caught my eye because I’ve been holding back on a zwave deadbolt purchase until I see how ZWaveJS shakes out. Just curious, is this the lock you have? Are you happy with it? How’s the battery life? Other than the issue you’ve spoken to here, any other quirks or problems?

I need 3 locks, so I’m hesitant to drop $750 without some solid feedback first, not seeing much about this lock on the forums. @gravyflex feel free to chime in here too if this is the lock you have!

https://www.lowes.ca/product/electronic-door-locks/schlage-connect-century-z-wave-plus-electronic-smart-lock-deadbolt-in-satin-nickel-876787

This is what I have! I have 2 of them.

With the workaround it now work fine. But yeah, it’s a little bit annoying.

For the battery life it last about 6 months I would say? Maybe more. I’m using rechargeable AA batteries. Overall I’m quite happy with the product!

ZwaveJS was overall positive for me since I had 4 devices that were not working previously and now they work.

1 Like

Thanks for the feedback. I’ve now inched a little closer to pulling the plug!

And the 6 months for the battery is for the main door… I’m not sure if it’s not 1 year.

Also for the other lock… I think I changed the batteries 1-2 times in 4 years.

Now that I’m with HA, I think I will create some reports inside Grafana in order to get a real picture about my battery usage.

I would be thrilled with 6 months. I had a electric keypad deadbold (not smart) that would chew through a 9 volt every couple weeks.

I’m think I’m going to order them today. I can’t switch over to ZWaveJS until they get device configuration command working (I have a buttload of Inovelli dimmers that need set_configuration for the LEDs) so hopefully they work well in the original ZWave integration also.

I assume it reports what code unlocked the door somehow? I’m hoping to use that data to automatically disarm the house alarm if I possible.

One other question. Do fingerprint smudges show up on the panel? That would make it pretty obvious what digits are in the unlock code.

Yes, I pasted an example of that in the post, so you can take a look! However I did not do anything with this info yet.

My friend tried to guess the code based on that, he was almost able to guess my code. You can just clean up the panel + make sure everyone in the house is using its own code.

I have a Schlage Z-Wave lock on my front door, and I get 9-12 months of battery life. I use AA Lithium batteries (non-rechargeable cells). I chose those batteries because of their low-temperature performance since this was mounted on an exterior door. Though in the past, I’ve also used “Amazon Basics” alkaline batteries with probably 8 or 9 months of life.

I think the one critical thing to ensure maximum battery life is make certain that the bolt that engages into the door strike doesn’t bind at all. Take the time to trim and adjust the plate to make sure that’s the case.

I’m really happy having the Z-Wave door lock; it’s probably the single most useful “peripheral” in my home automation system. Being able to tell that the door is unlocked from the inside, vs from the outside with a user code enable entirely different actions for leaving vs. arriving.

2 Likes

All, rather than working around the issue, please come post a bug report at node-zwave-js so that we can look into fixing the actual issue.

2 Likes

I made a bug report: https://github.com/zwave-js/zwavejs2mqtt/issues/576

I got my lock up today and I’m experiencing the issue.

1 Like

Thanks!

I was about to do the same.