I recently got a Schlage BE469ZP lock and everything works great. I’d been locking and unlocking the door both physically and with zwave one-off toggles for a bit and have had no issues with locking or state.
I finally set up a couple automations based on my routines: one to unlock the door each weekday morning and one to lock the door each night (config below).
The odd part is that the morning unlock works just fine, but the evening lock automation changes the lock state (it reports “locked”) but the lock doesn’t physically turn. I have to toggle it back to unlocked and then to locked again to make it work.
Morning Unlock
alias: Unlock front door on weekday mornings
description: ""
trigger:
- platform: state
entity_id:
- schedule.weekday_mornings
from: "off"
to: "on"
condition:
- condition: zone
entity_id: person.jay
zone: zone.home
- condition: state
entity_id: lock.entryway_frontdoor_lock
state: locked
action:
- service: lock.unlock
target:
entity_id: lock.entryway_frontdoor_lock
data: {}
mode: single
Nightly Lock
alias: Lock Door on Schedule
description: ""
trigger:
- platform: state
entity_id:
- schedule.secure_home
from: "off"
to: "on"
condition:
- condition: zone
entity_id: person.jay
zone: zone.home
- condition: state
entity_id: lock.entryway_frontdoor_lock
state: unlocked
action:
- service: lock.lock
target:
entity_id: lock.entryway_frontdoor_lock
data: {}
mode: single
As you can see, these are almost identical save for the referenced schedule, the current lock condition, and the action service (lock vs. unlock).
I’ve tried the disable/enable trick reported as a fix for similar issues with no luck.
A couple other interesting and notable picees:
I’m still new here and still using the UI for whatever that’s worth. I’ll move to yaml files soon enough.
Traces look identical in both cases (it appears everything worked), no condition is failing – which makes sense given the lock state is updated to report locked.
Manually running the automation action works as expected, the door physically locks.
I had a very similar issue with a light switch not long ago but disable/enable or cloning the automation would give me a working copy. That doesn’t work in this case.
One more odd bit - yesterday I modified the lock schedule to include the current time and the automation instantly kicked in and locked the door as it should.
That was promising, so I set the schedule back to the usual (10pm) and unlocked the door to see if it was fixed – at 10pm, the status changed to locked but the door did not lock.
Theres no reason to worry about using yaml…
What Zwave coordinator are you using?
I was using an older coordinator and it was behaving smilarly with a newer lock. I upgraded to a new coordinator and it cleared up the issue.
I hadn’t considered the controller but it’s a Zooz 800 Series (ZST39 LR).
I mention the UI vs. YAML bit since I had a very similar issue with a switch controlling smart lights where the automation wouldn’t turn on the light but a manual “Run” on the automation worked fine. The fix was to clone the automation and re-save it, deleting the original. It made me think there was an issue with the UI and missing an attribute of some sort.
I have 3 of these locks (paired with the zooz 800 as well). I don’t know for sure but I believe the locks themselves are really flaky. One of mine was rock solid from day one but the other two were very inconsistent in their reporting all three doors are almost equidistant from the radio and have similar wall obstruction material). I wound up RMAing them and the replacements (with seemingly newer firmware at least) are now working well. It’s a pain but I’d try replacing the lock if you can still.
Good to know, I’ll keep that in mind as a last-resort at least.
These two pieces of data are what drive me nuts:
The scheduled routine always executes, it just doesn’t actually turn the lock on my normal schedule.
If I modify the schedule to include the current time or a time coming up soon it works.
It almost makes me think of a sleep-status type of thing but the morning unlock is flawless when there’d be no activity for hours. I’m going to play with more time schedules to see if I can figure out any sort of pattern. Having 10pm consistently fail to turn the lock but 7pm work just fine makes no sense.
Another thing to try… Does your automation also involve a bunch of other z wave devices (or run at the same time as other automations that do)? I used to have a sleep automation that would turn off all my lights, lock doors, etc. If you do have a lot of other simultaneous z wave activity, try putting the lock at the front - to essentially get in before the potential barrage of later commands going out. I had a similar experience - being able to manually lock whenever, but once part of the automation with all the other activity, it wouldn’t hear the commands. Moving it to the first action helped a lot. I still wound up replacing my flaky ones and was able to move them later in the automation but rearranging them to the top almost completely eliminated the issue for the “bad” firmware (or maybe defective radio hardware?) ones.
Tried one more thing today. I set it for 7pm to lock the door and send me a notification. At 7pm the usual happened: lock status says locked, door isn’t locked, and I got the notification which is at the end of the automation.
I then deleted 7pm from my schedule, fixed the lock status back to match the unlocked state, then added 7pm back to the schedule. No touching the automation… only the schedule. It triggered and locked the door instantly.
Apologies for turning this into a liveblog but I’ve narrowed things down a little more.
The issue (lock status changes to locked but lock does not turn) consistently happens on a a scheduled event. However, I can always trigger the lock by including the current time in the schedule (ie. saving the schedule triggers the event).
I have no idea why that would behave differently but I have enough sample size to say it works that way. Unlocking still works fine on a schedule every day.
Likely my last update on this. I just changed from a schedule helper (triggering on the off → on state) to a time trigger and things work as expected.
Again, since triggering the workflow was never the issue I’m not sure why this happened but if I’m able to narrow it down further I’ll update for others but I have a working solution and time is a bit easier to work with anyway.
