Schlage BE469ZP missing IDs and some IDs reported as undefined.

[kubiej21]

I recently purchased 5 Schlage FE599 keypad locks and 1 Schlage BE469ZP deadbolt. The FE599s have all worked well, however, the BE469ZP has been giving me issues.

I realized that I was having issues when I could not set a user code via the keymaster integration. Comparing the FE599 locks against the BE469ZP, it appeared that the BE469ZP was missing ids such as userIdStatus, userCode, etc. Looking around online, I stumbled on this post https://github.com/zwave-js/node-zwave-js/issues/3933 , that appeared to show the ID's that I think are missing in my case.

I have tried including/excluding the lock a number of times, have tried re-interviewing, and have also factory reset the lock. It is worth noting that the lock is approximately 5 feet away from my z-wave dongle and has direct line of sight (no walls).

While re-interviewing the BE469ZP (node 12 in the logs below), I noticed that the FE599s that were powered on appeared to be responding as well. Is this expected behavior? If I request node 12 to be re-interviewed, I guess I expect to only see node 12 respond.

While including or interviewing node 12, I am getting a large number of timeouts. I am guessing the missing ID's are related to the timeouts. See pictures for reference...

Using Home Assistant OS (2022.4.4) on a Raspberry PI 4
Aeotec Z-Stick Gen5+ zwave dongle.

node 12 debug info.txt
zwavejs2mqtt_2022-04-16.log
zwavejs_2022-04-16.log

[AlCalzone]

There's something really weird with the lock... At first it communicates fine with round-trip times of < 100 ms:

# Outgoing message (to the lock)
2022-04-16T16:21:58.037Z DRIVER » [Node 012] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      45
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 216
                                    └─[AssociationCCGet]
                                        group id: 1

# Acknowledgement (got the message)
2022-04-16T16:21:58.077Z DRIVER « [REQ] [SendData]
                                    callback id:            45
                                    transmit status:        OK, took 30 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -41 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1

# Response
2022-04-16T16:21:58.129Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 92
                                    └─[AssociationCCReport]
                                        group id:          1
                                        max # of nodes:    2
                                        node IDs:          1
                                        reports to follow: 0

and then all of a sudden, it doesn't respond at all (despite acknowledging the message)

2022-04-16T16:21:58.563Z DRIVER » [Node 012] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      48
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 219
                                    └─[AssociationGroupInfoCCInfoGet]
                                        group id:      1
                                        refresh cache: false

2022-04-16T16:21:58.602Z DRIVER « [REQ] [SendData]
                                    callback id:            48
                                    transmit status:        OK, took 30 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -41 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1

... no response

or takes several seconds:

2022-04-16T16:21:59.649Z DRIVER » [Node 012] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      49
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 220
                                    └─[DoorLockCCConfigurationGet]

2022-04-16T16:21:59.688Z DRIVER « [REQ] [SendData]
                                    callback id:            49
                                    transmit status:        OK, took 30 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -41 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1

... a bunch more queries after the driver gave up on waiting ...

# 4 seconds later: the response
2022-04-16T16:22:03.603Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 95
                                    └─[DoorLockCCConfigurationReport]
                                        operation type:               Constant
                                        outside handle configuration: false, false, false, false
                                        inside handle configuration:  false, false, false, false

Z-Wave JS times out waiting after the Request-ACK round trip time plus 1s, which is in line with the Z-Wave specifications. I'm not sure where in the specs I took this from, but the general principle is described in #1518

the BE469ZP has been giving me issues.

FWIW, you're not the only one. I've seen issues with this lock (or the BE468) so often in issues, that I put it on my "do not recommend" list: https://zwave-js.github.io/node-zwave-js/#/getting-started/device-review?id=the-list

[kubiej21]

Thanks for looking into this and taking the time to respond. Is there a way to increase the timeout time? I guess I'm curious to see if the lock will respond more appropriately if given more time.

[AlCalzone]

There is a driver option for this:
https://zwave-js.github.io/node-zwave-js/#/api/driver?id=zwaveoptions -> timeouts.report, but I'm not sure any application exposes these.

Increasing the option does have the downside that any communication attempt where a device doesn't respond will cause delays. And since your lock is responding within 50 milliseconds at the start, but suddenly takes 100x longer, makes me think there's something going on with it. Battery low maybe?

[kubiej21]

Hmm... I'll have to do some research to see if I can attempt to leverage that.
Yeah, I understand the issues with increasing the timeout - I was just interested in it purely from a testing standpoint. I wouldn't want to use it long term in a "production" environment.

Brand new batteries. The lock even reports the battery level as being 100%.

I have an extremely small z-wave network at this point. The only devices on my network are the locks as well as a couple of Aeotec repeaters (which the Schlage locks don't appear to like using).

[robertsLando]

This can be set by manually editing settings.json in store.Check hidden settings here

[robertsLando]

Example:

{
    "mqtt": {
        ...
    },
    "gateway": {
       ...
    },
    "zwave": {
        "port": "/dev/serial/by-id/usb-0658_0200-if00",
        "options": {
			"timeouts": {
				"report": 2000
			}
		}
    }
}

[Berzerker]

Did you ever solve this or figure anything I'm out? I'm having the same problem with my BE469ZPs

[AlCalzone]

See workaround in #4474 (reply in thread)

[Berzerker]

Thanks. I tried adding this but it didn't seem to fix the issue (I also pinged you in the HA discord zwave channel)

[david-pekrul]

For anyone that comes across this, I had this same problem, and I'm using zwave2jsmqtt web interface. I toggled the setting "Increase Node report timeout" and reinterviewed the lock. I still got a few report timeouts, but only 4 compared to the 30+ without. After that, the interview completed and I'm seeing all the values well defined in my options. I've since turned off the setting.