I just went through adding my non-Zwave Plus lock again yesterday. I also have a newer one with Plus and I feel like it’s easier to add. I did not factory reset it, I just put in the programming code and hit 0 to put it into pairing mode. Once I got the lock fairly close to the Zwave stick it was easy to get it to pair and give me the green check. The issue was that it would start interviewing the lock, and right around the battery info stage would time out. I excluded and repaired it for around half an hour before I finally happened on the trick of hitting the Schlage button once in a while after the green check to keep it awake. After doing that until everything was interviewed it was fine.
I have the schlage (allegeion) z-wave lock and just integrated for the first time. I’m using aeotec 7 usb into zwave-js and the interview went fine. I see a ton of entities in HA; The “lock” and “unlock” buttons are working fine and batt status shows up, etc. The binary sensor for “door” always stays “open” regardless of the physical state.
In zwave-js, when I trigger a lock or unlock event, I see that there are 3 things that can get updated… door status, bolt status, and latch status. Only bolt status seems to be showing the correct open or close entities. Door status and latch status ALWAYS say open. I’m not sure if this is something I can fix on my own or if this is a coding issue. Below is an event log for zwave-js. This was after I triggered a door lock via home assistant UI. I’m using the integrated HA version not mqtt if that makes a difference.
2022-11-11T17:55:17.289Z - VALUE UPDATED Arg 0: └─commandClassName: Door Lock └─commandClass: 98 └─property: doorStatus └─endpoint: 0 └─newValue: open └─prevValue: open └─propertyName: doorStatus
2022-11-11T17:55:17.289Z - VALUE UPDATED Arg 0: └─commandClassName: Door Lock └─commandClass: 98 └─property: boltStatus └─endpoint: 0 └─newValue: locked └─prevValue: locked └─propertyName: boltStatus
2022-11-11T17:55:17.290Z - VALUE UPDATED Arg 0: └─commandClassName: Door Lock └─commandClass: 98 └─property: latchStatus └─endpoint: 0 └─newValue: open └─prevValue: open └─propertyName: latchStatus
I have three Schlage Connect BE469 (non zwave plus) locks running Firmware 128.22 . All have been Factory reset, excluded and securely added using S0 security recently after migrating from a Zooz 500 to Zooz 700 controller sticks.
The lock that is about 15 feet from the controller works fine. Status and control both work as expected.
The two locks on a detached building will get status updates just fine but seem to go to sleep and become unavailable after a few minutes. Also, any attempt send a command to lock/unlock using HA immediately makes the locks unavailable and the logs state " Failed to send the command after 3 attempts (Status NoAck)".
These problems existed on the 500 series controller as well. There are several powered 500 and 700 series devices in between the controller and the locks.
Anyone have any ideas on how to get them to be more responsive like the close lock?
Home Assistant 2022.11.4
Supervisor 2022.11.2
Operating System 9.3
Frontend 20221108.0 - latest
zwave-js-ui: 8.4.1
zwave-js: 10.3.0
Zooz ZST-10-700 Controller FW 7.18.1
On the locks that are not very responsive, do they have association groups configured?
All 3 locks report one association group - which is Alarm Reports to the ZWave Controller
Posting here for Googler’s in the future (2023+).
Here’s a comment reply of mine that sums up the modern changes to this procedure.
I had similar issues… ended up migrating over to ZWAVE JS UI
1). Migrate to ZWAVE JS UI
2). Factory RESET SCHLAGE BE469
3). Go onto ZWAVE JS UI and reset S0 Legacy key (It’s under Control Panel, Settings, Zwave)
4). Repairing Schlage BE469
Once I did all this, I had full control over schlage lock settings (only took 3 years to figure it out)
1 Like
I decided to give this another try tonight after over a year.
I did the following:
- excluded lock from Zwave JS
- factory reset lock
- configured lock with factory code
- created a new S0 security key, replacing old one
- attempted to include with S0 security
It looks like it included correctly, and it displays the correct name, model, FW version, etc, but it will not lock or unlock and does not show the correct status.
The Zwave log shows that the lock supports S0 security and that it tries to include that way, but later on it says supports security: false.
2023-02-04T03:19:01.661Z CNTRLR finished adding node 86:
basic device class: Routing Slave
generic device class: Entry Control
specific device class: Secure Keypad Door Lock
supported CCs:
· Basic (0x20)
· Door Lock (0x62)
· User Code (0x63)
· Manufacturer Specific (0x72)
· Version (0x86)
· Application Status (0x22)
· Firmware Update Meta Data (0x7a)
· Security (0x98)
then later…
2023-02-04T03:19:03.121Z CNTRLR [Node 086] Beginning interview - last completed stage: None
2023-02-04T03:19:03.123Z CNTRLR [Node 086] new node, doing a full interview...
2023-02-04T03:19:03.125Z CNTRLR » [Node 086] querying protocol info...
2023-02-04T03:19:03.139Z DRIVER the message was handled
2023-02-04T03:19:03.146Z DRIVER » [REQ] [GetNodeProtocolInfo]
payload: 0x56
2023-02-04T03:19:03.161Z DRIVER « [RES] [GetNodeProtocolInfo]
payload: 0x53dc00044003
2023-02-04T03:19:03.172Z CNTRLR « [Node 086] received response for protocol info:
basic device class: Routing Slave
generic device class: Entry Control
specific device class: Secure Keypad Door Lock
node type: End Node
is always listening: false
is frequent listening: 1000ms
can route messages: true
supports security: false
supports beaming: true
maximum data rate: 40000 kbps
protocol version: 3
2023-02-04T03:19:03.175Z CNTRLR [Node 086] Interview stage completed: ProtocolInfo
2023-02-04T03:19:03.177Z CNTRLR » [Node 086] querying node info...
2023-02-04T03:19:03.197Z DRIVER » [Node 086] [REQ] [RequestNodeInfo]
node id: 86
2023-02-04T03:19:03.205Z CNTRLR Failed to execute controller command after 1/3 attempts. Scheduling next try i
n 100 ms.
2023-02-04T03:19:03.208Z DRIVER Dropping message with invalid payload
2023-02-04T03:19:03.210Z DRIVER « [Node 086] [REQ] [ApplicationCommand]
└─[SecurityCCCommandEncapsulation] [INVALID]
error: Nonce 0xda expired, cannot decode security encapsulated command.
I’m just out of ideas at this point.
This may seem silly but after all of this…
- excluded lock from Zwave JS
- factory reset lock
- configured lock with factory code
- created a new S0 security key, replacing old one
- attempted to include with S0 security
…and before you do anything else after a successful inclusion, physically lock and unlock the device by hand and watch for status changes on the device interface within HA.
I had to do that prior to successfully controlling the lock via HA.
Good luck!
1 Like
I have the BE469, and in the HA zWavejs settings it’s branded as “by Allegion”, running Firmware 128.22.
For several years it was working just fine in HA, reliably involved in several automations such as auto-locking when the alarm is armed.
But recently the lock became basically unusable as a z-wave device. Nothing changed in my z-wave network’s physical layout (the others nodes and their locations). Brand new alkaline batteries were not the answer; I think the z-wave radio in the lock simply started to degrade and the signal distance got to be too far, coming and/or going.
I may try to get more nodes in the path between my HA device and the lock, but for now I’ve solved the problem by moving my HA device from its customary (mostly hidden) location and closer to the lock. Once I did that the lock magically started working like it used to in “good ol’ days”.
Lesson learned: before investing a ton of time diagnosing a lock that stopped working normally, healing your network, removing & re-adding devices, just try temporarily moving your HA device closer to it and see what happens.
z-wave devices are definitely the most unreliably reliable in my setup 
I had two original BE469s (not plus) and after some troubleshooting with Schlage they eventually replaced them both (a few months apart mind you) with ZP models and the conclusion was the radios died, it started with having dead nodes for the locks repeatedly, sometimes multiple times a day. But at the time I did this those locks were less than a year old, so you may have trouble getting them to replace them at this point. Overall Schlage support was extremely helpful, but again those locks were still under warranty at that time.
All, pulling out my hair on adding this lock, process so far has been…
- Exclude lock (this works)
- Factory Reset (I assume this work as my manaul user codes are not there)
- Add lock (i do this as fast as I can after step #2)
It seems to add fine, I get a bunch of green check marks when pairing however under controls I cannot open or close and under sensors it says unavailable even if I manually open/close the lock. Log below shows that something times out and after a longer period my lock beeps, please help 
2023-05-09T22:11:57.278Z DRIVER « [REQ] [SendDataBridge]
callback id: 94
transmit status: OK, took 3440 ms
routing attempts: 3
protocol & route speed: Z-Wave, 40 kbit/s
ACK RSSI: -87 dBm
ACK channel no.: 1
TX channel no.: 1
beam: 1000 ms
2023-05-09T22:12:01.812Z CNTRLR [Node 011] Timed out while waiting for a response from the node (ZW0201)
2023-05-09T22:12:01.814Z CNTRLR [Node 011] Querying number of user codes timed out, skipping interview...
2023-05-09T22:12:01.817Z CNTRLR [Node 011] Interview stage completed: CommandClasses
2023-05-09T22:12:01.820Z CNTRLR [Node 011] Interview stage completed: OverwriteConfig
2023-05-09T22:12:01.822Z CNTRLR [Node 011] Interview completed
2023-05-09T22:12:01.824Z CNTRLR [Node 011] The node is ready to be used
2023-05-09T22:12:06.824Z SERIAL » 0x0103003bc7 (5 bytes)
2023-05-09T22:12:06.827Z DRIVER » [REQ] [GetBackgroundRSSI]
2023-05-09T22:12:06.833Z SERIAL « [ACK] (0x06)
2023-05-09T22:12:06.835Z SERIAL « 0x0107013bb2b4b47f0f (9 bytes)
2023-05-09T22:12:06.837Z SERIAL » [ACK] (0x06)
2023-05-09T22:12:06.839Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -78 dBm
channel 1: -76 dBm
channel 2: -76 dBm
2023-05-09T22:12:20.125Z SERIAL « 0x012900a8080004033003001d01000000000000000000000000000000000000000 (43 bytes)
00000000000000000cb95
2023-05-09T22:12:20.129Z SERIAL » [ACK] (0x06)
2023-05-09T22:12:20.132Z CNTRLR [Node 004] [Binary Sensor] Any: metadata updated [Endpoint 0]
2023-05-09T22:12:20.136Z CNTRLR [Node 004] [~] [Binary Sensor] Any: true => false [Endpoint 0]
2023-05-09T22:12:20.139Z DRIVER « [Node 004] [REQ] [BridgeApplicationCommand]
│ type: multicast
│ target node: 1
│ RSSI: -53 dBm
└─[BinarySensorCCReport]
type: Any
value: false
2023-05-09T22:12:20.145Z SERIAL « 0x010c00a80001040330030000cba5 (14 bytes)
2023-05-09T22:12:20.147Z SERIAL » [ACK] (0x06)
2023-05-09T22:12:20.149Z CNTRLR [Node 004] [Binary Sensor] Any: metadata updated [Endpoint 0]
2023-05-09T22:12:20.151Z CNTRLR [Node 004] [~] [Binary Sensor] Any: false => false [Endpoint 0]
2023-05-09T22:12:20.153Z DRIVER « [Node 004] [REQ] [BridgeApplicationCommand]
│ RSSI: -53 dBm
└─[BinarySensorCCReport]
type: Any
value: false
2023-05-09T22:12:36.830Z SERIAL » 0x0103003bc7 (5 bytes)
2023-05-09T22:12:36.832Z DRIVER » [REQ] [GetBackgroundRSSI]
2023-05-09T22:12:36.836Z SERIAL « [ACK] (0x06)
2023-05-09T22:12:36.839Z SERIAL « 0x0107013bb3b3b37f0e (9 bytes)
2023-05-09T22:12:36.841Z SERIAL » [ACK] (0x06)
2023-05-09T22:12:36.843Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -77 dBm
channel 1: -77 dBm
channel 2: -77 dBm
2023-05-09T22:12:37.402Z SERIAL « 0x012900a8080004033003ff1d01000000000000000000000000000000000000000 (43 bytes)
When I press unlock from the UI this is what I get in the log it it helps (note that nothing actually heppens at the lock)
Subscribed to Z-Wave JS Log Messages…
2023-05-09T23:00:16.312Z SERIAL » 0x010f00a9010d036201002500000000d1c1 (17 bytes)
2023-05-09T23:00:16.314Z DRIVER » [Node 013] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 209
└─[DoorLockCCOperationSet]
target mode: Unsecured
2023-05-09T23:00:16.321Z SERIAL « [ACK] (0x06)
2023-05-09T23:00:16.324Z SERIAL « 0x010401a90152 (6 bytes)
2023-05-09T23:00:16.326Z SERIAL » [ACK] (0x06)
2023-05-09T23:00:16.328Z DRIVER « [RES] [SendDataBridge]
was sent: true
2023-05-09T23:00:17.523Z SERIAL « 0x011d00a9d100007600b57f7f7f7f01010300000000420100007f7f7f7f7f66 (31 bytes)
2023-05-09T23:00:17.526Z SERIAL » [ACK] (0x06)
2023-05-09T23:00:17.529Z DRIVER « [REQ] [SendDataBridge]
callback id: 209
transmit status: OK, took 1180 ms
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
ACK RSSI: -75 dBm
ACK channel no.: 1
TX channel no.: 1
beam: 1000 ms
2023-05-09T23:00:22.559Z SERIAL » 0x010e00a9010d0262022500000000d2c1 (16 bytes)
2023-05-09T23:00:22.560Z DRIVER » [Node 013] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 210
└─[DoorLockCCOperationGet]
2023-05-09T23:00:22.566Z SERIAL « [ACK] (0x06)
2023-05-09T23:00:22.569Z SERIAL « 0x010401a90152 (6 bytes)
2023-05-09T23:00:22.570Z SERIAL » [ACK] (0x06)
2023-05-09T23:00:22.572Z DRIVER « [RES] [SendDataBridge]
was sent: true
2023-05-09T23:00:23.796Z SERIAL « 0x011d00a9d200007800b57f7f7f7f01010300000000420100007f7f7f7f7f6b (31 bytes)
2023-05-09T23:00:23.800Z SERIAL » [ACK] (0x06)
2023-05-09T23:00:23.804Z DRIVER « [REQ] [SendDataBridge]
callback id: 210
transmit status: OK, took 1200 ms
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
ACK RSSI: -75 dBm
ACK channel no.: 1
TX channel no.: 1
beam: 1000 ms
2023-05-09T23:00:26.070Z CNTRLR [Node 013] Timed out while waiting for a response from the node (ZW0201)
I also have this lock. Make sure to pair using S0 security (not S2 or none). This lock is older and doesn’t play well with other security types.
1 Like
Sorry to bring back thread but how did you add the lock to HA in the first place?
I have zooz 800 usb stick and BE469 non-plus lock.
I can’t seems to add the lock to HA at all. I added Zwave JS UI, generated keys, then I added integration, now I am adding device, I go to the lock, hit schlarge button, enter 6 digit programming key, hit 0 and after several seconds the red checkmark flashes.
Tried at least 10 times. Detailed everything here
Suggestions are welcome.
I never got mine to work. It worked with Vera Lite and with a SmartThings v2 hub, but it won’t work with HA. It will “include”, but it times out, like others have said.
If it was paired to another controller before, you need to exclude it first otherwise you won’t be able to include it again. I had the same issue when I was switching all my stuff from my old vera lite to my 700 stick on HA/zwave-js ui
P.S you don’t have to exclude it using the old controller/gateway. Simply start the exclusion process from zwave-js ui / manage nodes / exclusion then on the lock press the schlage button → programmer code → 0. The green checkmark will flash to confirm the exclusion.
After this do the same but with z-wave-js ui in inclusion mode.
Even if it had not been paired to another network before, it worth a try. I had a lot of z-wave devices that needed this over the years to be able to be paired. Looks like that excluding the device is the only way to do a real reset.
Had mine working perfectly fine with zwave-js ui for 2 years. Then I recently (last month) got a BE469+ on warranty (the keypad on the BE469 died and Schlage sent me the new version for free) and its working fine also. I’m using an aetoec 700 controller, I was also using a Vera Lite before switching to HA 2 years ago… The only issue I had then is was I descrived above, not knowing I had to exclude the lock to be able to include it again. Wasted a good amount of time figuring this out lol.
Thank you. Exclusion was necessary as well as keeping the zwave stick within 5" from the lock as it was explained on this thread below.
Managed to unroll and enroll.
2 Likes