Schlage / Allegion BE469 Z-Wave lock

Configuration
22

That is correct. Te couple of years I was away frm here I worked quite closely with their Z-Wave developer so I learned a few general tricks.

You may want to open a discussion on the node-zwavejs GitHub repo for further guidance. They helped me when i had a device that had an incorrect database entry,.

23

I was able to get my lock to work with Home Assistant.

For unrelated reasons I decided to ditch my husbzb-1 and got a Zooz ZST10. When I rebuilt my network I switched to zwavejs2mqtt. The lock was excluded, then reset. I began inclusion from the zwavejs2mqtt control panel and it prompted for DSK. I confirmed and the lock interviewed successfully.

1 Like
24

Been using Z-Wave JS w/ a Zooz stick for a few days now w/ the Schalge
 anyone else having issues w/ the lock going offline? My Z-wave network is pretty robust
 and I didnt have this issue w/ SmartThings or Vera. Thanks!

25

+1 - just had this issue. Spent like 20 min trying to figure out why i could exclude but not add the device.

26

Now it’s my turn to have issues with this lock. Mine is an old version (the S0-compatible BE469, not the ZP version, which has S2 and Z-Wave plus support). This lock has been working rock solid on my Vera Plus. I’m new to Home Assistant and since this lock is an important piece of my home automation, I wanted to make sure it would work with HA. Not having luck with it running on RPi 4 with a RazBerry 7 so far.

I’m using zwavejs2mqtt and I can get the lock included just fine. It evens reports “included with S0_Security” (or something to that effect). However, even after the interview completes, both the lock status (locked or unlocked) and the ability to lock/unlock simply don’t work. The device responds to ping and everything. It currently reports these CCs:

  • Dock Lock v2
  • Configuration v1
  • Notification v3
  • Manufacturer Specific v1
  • Battery v1
  • Version v1

(I believe I got 7 CCs in one of my inclusion attempts - don’t remember the extra one. Now it only reports 3, 4 or 6. Nothing ever changes if I try to re-interview. I have to remove it and include it again)

I tried to follow the guidance in this thread: factory reset before any inclusion, exclude it first, complete inclusion in the first 10-15 seconds, have the RPi+RazBerry 7 very close to the lock (within inches) during inclusion. I also try to include it immediately after a factory reset.

I have zwavejs2mqtt logging to a file, but I don’t know what to look for.

What am I missing? Any other guidance?

Thanks!

27

Tried to include it again and got the 7th CC listed by the zwavejs2mqtt. The full list is now:

  • Dock Lock v2
  • User Code v1
  • Configuration v1
  • Notification v3
  • Manufacturer Specific v1
  • Battery v1
  • Version v1

Having said that, the lock status is now showing up as “unknown” (it was stuck at “open” before) and the lock options is now disabled (I had a lock and unlock options that would do nothing when clicked).

In addition, I found out how to enable zwavejs logs and I can see this there:

[Node 007] 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

So, I get “supports security: false” even though zwavejs2mqtt reported the node added with “S0_legacy”. Also, I have all encryption keys saved under setup in zwavejs2mqtt (S2 Unauthenticated, S2 Authenticated, S2 Access Control and S0 Legacy). :man_shrugging:t4:

After the interview completed, I tried to use the lock and then went to check the logs. I saw this:

2022-09-18T06:20:06.258Z CNTRLR [Node 007] Interview completed
2022-09-18T06:20:06.258Z CNTRLR [Node 007] The node is ready to be used
2022-09-18T06:20:06.258Z CNTRLR [Node 007] command must be encrypted but was received without Security encapsulation - discarding it

2022-09-18T06:21:02.644Z CNTRLR [Node 007] command must be encrypted but was received without Security encapsulation - discarding it

2022-09-18T06:21:20.556Z CNTRLR [Node 007] command must be encrypted but was received without Security encapsulation - discarding it

2022-09-18T06:21:20.650Z CNTRLR [Node 007] command must be encrypted but was received without Security encapsulation - discarding it

2022-09-18T06:22:17.890Z CNTRLR » [Node 007] pinging the node

2022-09-18T06:22:19.103Z CNTRLR « [Node 007] ping successful
2022-09-18T06:27:08.818Z CNTRLR » [Node 007] pinging the node

2022-09-18T06:27:10.071Z CNTRLR « [Node 007] ping successful
2022-09-18T06:27:21.397Z CNTRLR [Node 007] command must be encrypted but was received without Security encapsulation - discarding it

2022-09-18T06:27:21.411Z CNTRLR [Node 007] command must be encrypted but was received without Security encapsulation - discarding it


If I assume this inclusion wasn’t actually done securely as some of these logs indicate, how do I convince HA and this lock to establish a secure connection?

Thanks!

28

I had a few questions. I have two BE469’s (not the newer model with PZ on the end). I originally was only able to pair one of them and it worked for about a year and broke after so many updates. After it being offline for 6mo I decided it was time to have another look. I finally got Z-waveJS to work and removed the legacy integration.

I was able to add both locks with ease but I could never get both of them to add securely. I’m seeing a few differences regarding instructions found across the web. I even saw one that was so slow I thought it was going to time out on the keypad entry!

I started with a few rounds of factory resets and now I can’t get either to add securely. Someone please correct me if I am wrong here


Reset Procedure: Remove battery > push the buttons for a bit to discharge the internals > hold outside schlage > apply power > release button > try a default code > bolt cycles > success

Enrolment Procedure: Extend the bolt > Schlage > 6 digit code > 0 > Check or X

My burning question is when can you hit the add device button in Z-WaveJS? This lock seems to timeout in seconds for enrollment, but if you are adding the device without enrollment it will never add secure, correct?

That is what I have been doing, now I only have node 2 and node 3 and they are always node 2 and node 3, I see a lot of people mention they are up to 30, 60+. This tells me I’m doing something significantly different.

I have tried to let it sit after adding, then trying to add again while still registered and trying the enrollment a few times
 this doesn’t feel right, and hasn’t had any additional results.

I see a lot of articles mention exclusion, but this is no longer paired after a factory reset so we can skip this right? What should I try next? I have an Aeotec Z-Stick Gen5 (ZW090) if that matters.

edit Firmware versions are 128.22 and 128.56 - guessing on the second one from memory

Thanks!

29

Corey,

I was never able to get my BE469 to work. It would include, but not securely.

I must have factory reset it 30 or more times, exclude, include, even tried the mqtt driver.

It is a huge pain in the ass to take the NUC out of my closed and hold it directly on the lock to try and pair, but I did that 20 times too.

It just doesn’t work. I gave up and I’m using it as a dumb keypad lock.

As far as I can tell, NO ONE in the past year or two has gotten one of these to work.

30

Haha. They work, there is just something quirky we don’t understand. The one I originally had working is the one that will not secure connect anymore. I had one working fully yesterday and I am fully up to date. I’m patient and persistent, so I’m looking for some insight between attempts.

Range doesn’t appear to be an issue either. When they were both on they had a direct route to the hub. One is about 20ft and the other is about 40ft from the dongle ← this is the one that worked yesterday. I run HassOS in a virtual machine. I don’t have the ability to move a giant server to the lock, but taking the full lock assembly to the server was something I am likely going to try tomorrow. I might even rig up a poor man’s lab power supply to rule out weak batteries, I’m using fresh duracells.

31

you need to have really good battery and not rechargeable one,
the lock have a lot of difficulty to communicate without excellent battery.
those are good : Panasonic AA Batteries Super Heavy Duty Power Carbon Zinc Double A Battery 1.5v

32

I am also having problems with one of these locks. I’ve had it for years and used it with no problems with both Smartthings and Hubitat. I have it a foot away from the controller. I’ve done the factory reset + exclusion process, then inclusion. It usually includes with S0 but always has timeouts during the interview process. Once it includes it seems to immediately go offline and I can’t lock/unlock but it does respond to pings.

If I re-interview it drops half the command classes and all the values are undefined. I’m out of ideas.

Edit: Hah! 20 minutes later I had one more idea. Instead of excluding the node, I factory reset and then did a node replace. Maybe it was just luck this time but it worked!

33

Congrats. I’ll be waiting for a while. Might even get a newer z-wave stick first. Mine is new enough but still old. I love to see the status and logging, and I can’t even get that right now. I got a few other projects that are a bit more important for now.

34

I have one of the older BE469 locks and was able to get it successfully working with zwave-js-ui. After excluding the lock from SmartThings, I performed a factory reset on the lock. Then I included it to HA.

At first glance, I thought it worked right off the bat - everything was showing up properly, I could program lock codes, etc. But then I realized that updates from the lock weren’t being received (as in, if the lock was manually (un)locked or keypad used, HA had no idea).

I finally figured out that the lifeline association didn’t get set up. I couldn’t find a way to manually add that, so I ended up excluding, resetting, and re-including again. That time, the association was set up properly and I was then able to receive updates from the lock without issues.

35

I’ve got one of these. It has always worked well enough for me, but just recently started giving me trouble. I haven’t reset it yet as it’s still connected with security. But when I re-interview the node, it’s like it’s not getting everything in time.

36

The secret for me was that I needed to exclude the lock before it would pair, no matter how many factory resets I did.

37

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.

38

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

39

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

40

On the locks that are not very responsive, do they have association groups configured?

41

All 3 locks report one association group - which is Alarm Reports to the ZWave Controller