Schlage Connect Century Touchscreen Deadbolts (BE468 and BE469) do not report manual lock/unlock state changes.

[DonGar]

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?

NO, my problem is NOT within Home Assistant or the ZWave JS integration

Is your problem within ZWaveJS2MQTT?

NO, my problem is NOT within ZWaveJS2MQTT

Checklist

• [X] I have checked the troubleshooting section and my problem is not described there.

• [X] I have read the changelog and my problem was not mentioned there.

Describe the bug

What causes the bug?

I have two Schlage deadbolts (BE468 and BE 469). If I lock or unlock them via Z Wave, the lock status in HA updates correctly (if slowly). If I lock or unlock these deadbolts using the internal knobs, or the keypads, the HA state is never updated. Previously, these devices were connected to a Casa Vera hub, which DID update their state, though it did so very, very slowly (perhaps a minute or so).

Node: 59 BE468 by Allegion Firmware: 128.22

Node: 60 BE469 by Allegion Firmware: 128.22

What do you observe?

If I unlock a door via the internal knob on one of the locks, the HA state remains locked.

What did you expect to happen?

I expected the HA state to change to unlocked.

Device information

Manufacturer: Model name: Node ID in your network:

How are you using node-zwave-js?

• [ ] zwavejs2mqtt Docker image (latest)
• [ ] zwavejs2mqtt Docker image (dev)
• [ ] zwavejs2mqtt Docker manually built (please specify branches)
• [ ] ioBroker.zwave2 adapter (please specify version)
• [X] HomeAssistant zwave_js integration (please specify version)
• [ ] pkg
• [ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
• [ ] Manually built from GitHub (please specify branch)
• [ ] Other (please describe)

Which branches or versions?

version: 10.0.4

Did you change anything?

no

If yes, what did you change?

No response

Did this work before?

No, it never worked anywhere

If yes, where did it work?

It did work with a Casa Vera hub, but has not worked since switching to ZWave JS.

Attach Driver Logfile

S0 Legacy Key: 03F4CAD8FFD70F33A49CDA008C98AAC8

The two locks are Nodes 59 and 60 on my network. I am attaching 3 silly level log files that show the locks being locked / unlocked via zwave, manually, and keypad.

zwave_unlock_lock.log manual_unlock_lock.log keypad_unlock_lock_60.log

[zwave-js-bot]

👋 Hey @DonGar!

It looks like you attached a logfile, but its filename doesn't look like it a driver log that came from Z-Wave JS. Please make sure you upload the correct one.

[dshokouhi]

I have a BE469 and its status is correctly shown in HA via manual lock/unlock, keypad lock/unlock and electronic lock/unlock...Maybe check there is no interference going on?

[DonGar]

I'm confident that the mesh is stable. Partly because lock/unlock requests sent via zwave work well, and partly because my other nodes nearby are stable.

Perhaps there are firmware updates, a device specific setting, or problem with exactly how these devices are paired?

I'm using an Aeotec [Z-Stick Gen5+ (ZW090), with firmware 1.1. I just noticed there is a firmware update available for the stick. I'll try that when I have time.

[AlCalzone]

@DonGar in the logs where you locked manually and via keypad, not a single message is being received from the locks. The difference here is that these need to be sent by the lock itself, while the status update is actively requested when controlled via Z-Wave.

It seems like the former does not happen for you and the (delayed) update in Vera is a result of regular polling (refreshing the status). If you actually have the non-ZP variants, the locks might simply not report on their own and you'll have to set up an automation that refreshes the lock status every minute or so. Z-Wave JS doesn't do any regular polling on its own.

[DonGar]

That makes sense. I appreciate your looking into it, and suggesting an automation to trigger a poll. that hadn't occurred to me.

On Mon, Sep 19, 2022 at 3:53 AM AlCalzone @.***> wrote:

@DonGar https://github.com/DonGar in the logs where you locked manually and via keypad, not a single message is being received from the locks. The difference here is that these need to be sent by the lock itself, while the status update is actively requested when controlled via Z-Wave.

It seems like the former does not happen for you and the (delayed) update in Vera is a result of regular polling (refreshing the status). If you actually have the non-ZP variants, the locks might simply not report on their own and you'll have to set up an automation that refreshes the lock status every minute or so. Z-Wave JS doesn't do any regular polling on its own.

— Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/5079#issuecomment-1250743575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABDGGKKALCY7BHHGMP5FODV7ASX5ANCNFSM6AAAAAAQPCWUYQ . You are receiving this because you were mentioned.Message ID: @.***>

-- Don

[ahutchings]

Just wanted to add a data point here - I have some BE469 (non-Z-Wave Plus) locks (various firmware versions) and they report instant status updates on manual lock/unlock via the knob. I'm using Z-Wave JS to MQTT 0.47.0 and have reinterviewed the locks fairly recently, but things were also working fine when I was using them with the official HA ZWaveJS addon that was on ZwaveJS v9.

Lock 1 (BE469, FW: v128.22)

Lock

2022-09-21 20:05:50.799 INFO ZWAVE: Node 25: value updated: 113-0-alarmType 22 => 21
2022-09-21 20:05:50.800 INFO ZWAVE: Node 25: value updated: 113-0-alarmLevel 1 => 1
2022-09-21 20:05:50.801 INFO ZWAVE: Node 25: value updated: 98-0-currentMode 0 => 255
2022-09-21 20:05:50.802 INFO ZWAVE: Node 25 CC Notification {
  type: 6,
  event: 1,
  label: 'Access Control',
  eventLabel: 'Manual lock operation',
  parameters: undefined
}
2022-09-22T00:05:50.803Z CNTRLR   [Node 025] [Notification]
                                    type:  Access Control
                                    event: Manual lock operation

Unlock

2022-09-21 20:06:33.181 INFO ZWAVE: Node 25: value updated: 113-0-alarmType 21 => 22
2022-09-21 20:06:33.182 INFO ZWAVE: Node 25: value updated: 113-0-alarmLevel 1 => 1
2022-09-21 20:06:33.183 INFO ZWAVE: Node 25: value updated: 98-0-currentMode 255 => 0
2022-09-21 20:06:33.184 INFO ZWAVE: Node 25 CC Notification {
  type: 6,
  event: 2,
  label: 'Access Control',
  eventLabel: 'Manual unlock operation',
  parameters: undefined
}
2022-09-22T00:06:33.185Z CNTRLR   [Node 025] [Notification]
                                    type:  Access Control
                                    event: Manual unlock operation

Lock 2 (BE469, FW: v104.21)

Lock

2022-09-21 20:08:11.423 INFO ZWAVE: Node 26: value updated: 113-0-alarmType 22 => 21
2022-09-21 20:08:11.424 INFO ZWAVE: Node 26: value updated: 113-0-alarmLevel 1 => 1
2022-09-21 20:08:11.425 INFO ZWAVE: Node 26: value updated: 98-0-currentMode 0 => 255
2022-09-21 20:08:11.425 INFO ZWAVE: Node 26 CC Notification {
  type: 6,
  event: 1,
  label: 'Access Control',
  eventLabel: 'Manual lock operation',
  parameters: undefined
}
2022-09-22T00:08:11.425Z CNTRLR   [Node 026] [Notification]
                                    type:  Access Control
                                    event: Manual lock operation

Unlock

2022-09-21 20:07:22.661 INFO ZWAVE: Node 26: value updated: 113-0-alarmType 0 => 22
2022-09-21 20:07:22.661 INFO ZWAVE: Node 26: value updated: 113-0-alarmLevel 0 => 1
2022-09-21 20:07:22.664 INFO ZWAVE: Node 26: value updated: 98-0-currentMode 255 => 0
2022-09-21 20:07:22.664 INFO ZWAVE: Node 26 CC Notification {
  type: 6,
  event: 2,
  label: 'Access Control',
  eventLabel: 'Manual unlock operation',
  parameters: undefined
}
2022-09-22T00:07:22.664Z CNTRLR   [Node 026] [Notification]
                                    type:  Access Control
                                    event: Manual unlock operation

[AlCalzone]

Do you have the Z-Wave Plus variants? BE468ZP/BE469ZP or the older ones?

[ahutchings]

My logs are for the older Z-Wave (non-Plus) version: https://devices.zwave-js.io/?jumpTo=0x003b:0x6341:0x5044:0.0

[AlCalzone]

I guess @DonGar may be missing the lifeline association then (group 1, target node 1). It should get automatically set up, but maybe that didn't work. @DonGar try re-interviewing the locks, or add the association manually (in Z-Wave JS UI / zwavejs2mqtt)

[DonGar]

I have the non-Plus devices. I've re-interviewed and it hasn't helped. However, I remember having a lot of trouble getting them to pair in the first place. I'll try unpairing and repairing to see if that fixes it.

[DonGar]

One weird thing that happened during the re-interview is that the manufactorer/model switched to unknown/unknown.

[ahutchings]

I have seen unknown manufacturer/model with my BE469 locks as well. Logs showed timeouts during the interview. Healing the network and re-interviewing the locks would bring them back (IIRC it took a few re-interviews).

[DonGar]

I excluded and re-paired the E468, and now I'm unable to control it's behavior at all. It displays as healthy in the HA interface, but does not response to lock/unlock commands at all. I've re-interviewed repeatedly with no effect. The limited logs I've gathered show that most of the interview steps are timing out.

If it were possible to buy updated zwave modules for these locks, I would, since that seems to be the easiest path forward.

[AlCalzone]

Try factory-resetting them after excluding. The key exchange may not have worked.

[DonGar]

Because of looking at logs during this, I found that one of my light switches was being super chatty. After unpairing / repairing it, that stopped and the network as a whole is much faster.

Further, I moved the hub closer to the doors. Previously, I thought it was close enough, since it saw the devices quickly, but.... I unpaired, and repaired. Now everything is working perfectly. Notifications for lock/unlock appear to be nearly instant, much faster than they were before.

This is resolved, thank you!