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
Thanks for the reply. I have excluded and factory reset probably 50 times trying to get this to work. I also tried enrolling with my NUC computer with Zooz stick right beside the lock.
The only thing I haven’t tried is taking the lock off the door, excluding, factory reset, and re-adding holding the lock up to the Zooz stick (instead of the other way around, though I don’t see why that should matter).
I did the exclusion/inclusion process with the lock still installed on the door with my aeotec 700 stick at its normal location, about 20 feet away from the lock and it worked fine. Maybe yours is defective. Try contacting Schlage, they have a good customer support, sent me the 469+ without asking any question (there is a lifetime warranty on this model), I just followed the steps here:
https://www.schlage.ca/en/home/contact-us.html
If its a 469 it MUST be within 6’ to pair properly (uses whisper mode) Max security S0
if it’s a 469ZP (ZW+) it can pair at any range that Zwave is supported and will do S2.
If it’s a 469 and you used the exclude, then reset then pair with the stick slapped against the lock and it STILL doesn’t work - call Schlage - they have a good warranty. Im waiting for my non plus to die so they can send me a ZP 
So I have the 469 and used to work fine, but recently was no longer working. I checked HA and most of the entities reported as not being supported by Z-Wave JS (wtf??)
I re-paired the device and now all I have is this
Any thoughts about how I can get it back to full featured?
LOL, I finally fixed it this AM. Just deleted the device, did a factory reset, and re-paired. Looks great now.