Schlage Lock Needs 2 attempts before it does anything

[kaizokudave]

So I recently added a Schlage BE469ZP into my Z-wave network. I noticed that it wasn't responding as necessary. So I gave it a couple days and recently got the update, but no change in behavior.

Basically, I've noticed that doing anything manually, reports back to the hub with no issues. (At the end of the logs attached.)

But, if a command is sent from hubitat, i need to press it twice. I thought it was just a delay, but it's not. I can actually wait SEVERAL minutes later and press it again and it'll go as expected. So it's basically the second command works.
There's a Zwave switch right next to is, a Jasco ZP IIRC, and it works every press every time.

I have another lock, it's a BE469, but a slightly older model. It works, flawlessly.

I'll try it on another lock, but has anyone else run into this?

I attached a picture pointing out the issue.
Logs below

---

dev:2982021-03-26 09:44:05.665 am infoFront Door Lock was locked by thumb turn [physical]
dev:2982021-03-26 09:44:05.659 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:21, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:1, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:44:05.647 am debugparse: zw device: 23, command: 6C01, payload: 14 09 71 05 15 01 00 FF 06 01 00 , isMulticast: false
dev:2982021-03-26 09:44:05.381 am infoFront Door Lock was locked by thumb turn [physical]
dev:2982021-03-26 09:44:05.376 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:21, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:1, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:44:05.367 am debugparse: zw device: 23, command: 6C01, payload: 13 09 71 05 15 01 00 FF 06 01 00 , isMulticast: false
dev:2982021-03-26 09:44:00.434 am infoFront Door Lock was locked [digital]
dev:2982021-03-26 09:44:00.429 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:0, doorLockMode:255, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:44:00.420 am debugparse: zw device: 23, command: 6C01, payload: 12 07 62 03 FF 00 00 FE FE , isMulticast: false
dev:2982021-03-26 09:43:34.618 am infoFront Door Lock was unlocked by thumb turn [physical]
dev:2982021-03-26 09:43:34.613 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:22, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:2, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:43:34.605 am debugparse: zw device: 23, command: 6C01, payload: 11 09 71 05 16 01 00 FF 06 02 00 , isMulticast: false
dev:2982021-03-26 09:43:34.372 am infoFront Door Lock was unlocked [digital]
dev:2982021-03-26 09:43:34.368 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:2, doorLockMode:0, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:43:34.360 am debugparse: zw device: 23, command: 6C01, payload: 10 07 62 03 00 00 02 FE FE , isMulticast: false
dev:2982021-03-26 09:42:05.114 am infoFront Door Lock was locked by thumb turn [physical]
dev:2982021-03-26 09:42:05.110 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:21, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:1, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:42:05.055 am debugparse: zw device: 23, command: 6C01, payload: 0F 09 71 05 15 01 00 FF 06 01 00 , isMulticast: false
dev:2982021-03-26 09:42:04.897 am infoFront Door Lock was locked [digital]
dev:2982021-03-26 09:42:04.866 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:0, doorLockMode:255, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:42:04.765 am debugparse: zw device: 23, command: 6C01, payload: 0E 07 62 03 FF 00 00 FE FE , isMulticast: false
dev:2982021-03-26 09:33:11.695 am warnskipped alarmType:25
dev:2982021-03-26 09:33:11.690 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:25, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:4, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:33:11.678 am debugparse: zw device: 23, command: 6C01, payload: 0C 08 71 05 19 01 00 FF 06 04 , isMulticast: false
dev:2982021-03-26 09:33:11.465 am infoFront Door Lock was unlocked [digital]
dev:2982021-03-26 09:33:11.460 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:2, doorLockMode:0, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:33:11.447 am debugparse: zw device: 23, command: 6C01, payload: 0D 07 62 03 00 00 02 FE FE , isMulticast: false
dev:2982021-03-26 09:33:06.913 am debugunlock()
dev:2982021-03-26 09:32:19.505 am debugunlock()
dev:2982021-03-26 09:31:55.792 am infoFront Door Lock is locked [digital]
dev:2982021-03-26 09:31:55.781 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:0, doorLockMode:255, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:31:55.769 am debugparse: zw device: 23, command: 6C01, payload: 0B 07 62 03 FF 00 00 FE FE , isMulticast: false
dev:2982021-03-26 09:31:53.937 am warnskipped alarmType:24
dev:2982021-03-26 09:31:53.932 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:24, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:3, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:31:53.922 am debugparse: zw device: 23, command: 6C01, payload: 0A 08 71 05 18 01 00 FF 06 03 , isMulticast: false
dev:2982021-03-26 09:31:51.508 am infoFront Door Lock was locked [digital]
dev:2982021-03-26 09:31:51.504 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:0, doorLockMode:255, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:31:51.480 am debugparse: zw device: 23, command: 6C01, payload: 09 07 62 03 FF 00 00 FE FE , isMulticast: false
dev:2982021-03-26 09:31:47.217 am debuglock()
dev:2982021-03-26 09:29:30.016 am debuglock()
dev:2982021-03-26 09:29:17.693 am warnskipped alarmType:25
dev:2982021-03-26 09:29:17.689 am debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:25, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:4, zwaveAlarmStatus:255, zwaveAlarmType:6)
dev:2982021-03-26 09:29:17.678 am debugparse: zw device: 23, command: 6C01, payload: 07 08 71 05 19 01 00 FF 06 04 , isMulticast: false
dev:2982021-03-26 09:29:17.496 am infoFront Door Lock was unlocked [digital]
dev:2982021-03-26 09:29:17.491 am debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:2, doorLockMode:0, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:2982021-03-26 09:29:17.459 am debugparse: zw device: 23, command: 6C01, payload: 08 07 62 03 00 00 02 FE FE , isMulticast: false
dev:2982021-03-26 09:29:12.820 am debugunlock()
dev:2982021-03-26 09:28:35.931 am warnencryption is: false
dev:2982021-03-26 09:28:35.926 am warndescription logging is: true
dev:2982021-03-26 09:28:35.922 am warndebug logging is: true

[lewis.heidrick]

@ryanp was having something similar going on but for manual operations.

[tony.fleisher]

Not sure if it is what is going on for you, but lock issues like this are a common issue with weak z-wave meshes. What other z-wave devices do you have?

In general, locks seem to work better with beaming repeaters nearby (even if they are relatively close to the hub); from my understanding this has to do with the beam that is required to wakeup the FLiRS device before sending the command.

[lewis.heidrick]

@tony.fleisher

beam that is required to wakeup the FLiRS device before sending the command.

In zwave settings look in the route and see what device it's talking to between the lock and hub. If it's not a plus device this could very well be the issue.

[kaizokudave]

I've got mainly Z-wave devices on my network, with some zigbee.
The Jasco switch next to it is a Zwave repeater. (Literally inches) That one works 100% of the time, no issues. There's an Aoetec Beaming repeater that has a LOS to both devices, it's about 15ft away. Then that repeater has a LOS to the Hub, which is also about 15ft away. However, the devices may be talking to the Hub, which is.. about 20ft away as the crow flys, if that crow could fly through a 2nd story and a few walls.

I'd buy the weak zwave mesh if the light was flakey, but it's also ALWAYS the second command that works, and it works timely. Which is the damnedest thing.

[cwwilson08]

I think @bcopeland said he had one of these on the way. Maybe he can work some magic for us.

[kaizokudave]

I don't thing I have any non-Z-wave Plus devices in my network actually.

Dumb question, I can't seem to find the route options. Little help locating it?

[lewis.heidrick]

Its the last column 01 is the hub and 23 is the lock. The number is the id referenced in the first column. 0A is the device right before the lock that it's talking to.

[kaizokudave]

Ha, figures, it's talking to the light switch, which is literally right next to it. (like, inches)

So, if I'm reading this right, (and backwards):
23 - The lock is talking to 0A.
0A - The ZWP switch it's sitting inches from, is talking to 12.
12 - The Aeotec Repeater is talking to 01.
01 - Is the Hub, and the green grass grows all around, and the green grass grows all around....

So, the only thing I think to do, is try and force it to talk to the repeater.. but I can't control that right?

Edit: Tried a Z-wave repair on the device, taking same path.

[tony.fleisher]

@kaizokudave

the only thing I think to do, is try and force it to talk to the repeater.. but I can't control that right?

Correct. You can't force a particular route, but the device level z-wave repair may result in it switching to a different route.

[rlithgow1]

I had a similar issue like this when I paired one of my locks. I didn't follow my own advice.. I ended up removing it from HE, (don't worry about rules it's attached to) Factory reset it (pull power, press the schlage button a few times to drain the caps, press and hold the schlage button and reconnect the battery. Hold until the green check mark flashes 3 times and release the schlage button). Shut down the hubitat from the settings menu and pull the power (at the wall, not the hub) Wait 5 mins and power back up. Now pair the lock within 3 feet of the hub. Once completed and hub and lock in permanent position, run a z-wave repair. That hopefully will cure you.

[dnickel]

I find locks a real oddity.
I have a Kwikset and 2 Weisers. One of my Weisers operates just fine while the other works
flawlessly digital but won't report any event change if you manually turn the knob.
I have to poll it every 5 miniutes to get a status refresh. And yes the usual, new bats, removed and added, next to a Z-wave+ mains powered repeater.
Weird.

[spalexander68]

I too have noticed my Schlage lock needs two commands to lock or unlock it. Doesn't happen all the time, just most of the time. It is 15 feet from my Hub. I have an Aeotec repeater 3 feet from it and a Ring repeater about 10 feet on the other side of it. It has always routed (according to its details) to the hub and not through any of the repeaters.

The other weird thing is that this lock has always been rock solid until I upgraded to the C7 hub. I ended up wrapping my lock in the Reliable Locks app and it works well.

[kaizokudave]

I find locks a real oddity.
I have a Kwikset and 2 Weisers. One of my Weisers operates just fine while the other works
flawlessly digital but won't report any event change if you manually turn the knob.
I have to poll it every 5 miniutes to get a status refresh. And yes the usual, new bats, removed and added, next to a Z-wave+ mains powered repeater.
Weird.

I'm totally with you. For shnitizingiggles I was just playing with another lock. It's a Yale. Same amount of hops, but on the other side of the house. So, pressing lock.. nothing... zero... just says lock(). BUT, when I do a refresh, it shows everything fine. The lock did infact lock. Just never reports anything bag. I'm guessing it'll report at next poll that it's locked. As you said.. weird..

[kaizokudave]

I'm going to have to try that app out.

Originally, I have an older BE469, just Zwave, connected to ST. No repeaters other than that light switch. Worked everytime. No issues, until the lock radio died. (Almost 4 years later).

This is the first time i've tried to replace it. The other two locks in my house.. ya know I SWEAR sometimes they don't work, but I never know if my wife just woke up and let the cat or the dogs out in the middle of the night. (I could look but ya know.. i'm Lazy.)

[672southmain]

I, and others, have reported the same thing, now on 2.2.6.130. I changed from BE469NX to BE469ZP when I migrated from C-5 to C-7, so I never used BE469ZP on C-5, and I never used BE469NX on C-7.

Never saw this behavior on C-5 with BE469NX.

Major performance problems

I have 2 Schlage BE469ZP locks on a C-7 now running 2.2.6.129. Both locks each have a Ring Alarm Extender Gen 2 within a few feet of the lock. While I am not seeing what you are reporting (and the behavior hasn’t changed with 2.2.6, was there with 2.2.5), I am seeing it take 2 lock/unlock commands from the driver page to cause action (doesn’t matter whether the commands are sent spaced by many seconds, or just a second), as others have recently reported, too.

[dnickel]

Interesting, since this was reported I have noticed my front door lock is picking an choosing when it wants to operate. It's a Wesier and has always been fine. I did a repair to get a better route and threw a Aeotec 6 repeater close to it as well.
Watch and see.