Lock.lock service call fails under certain conditions - (Schlage Connect Z-Wave)

Configuration Z-Wave
1

I am having an issue where lock.lock fails sometimes. Specifically, if the lock was most recently unlocked manually (either by turning the deadbolt by hand, or punching the code in the keypad), then the service call will fail once, and then succeed if I run it a second time.

Setup details:

Home Assistant: Version 0.96.3 in a virtual environment on a Raspberry Pi 3
Z-Wave controller: Nortek HUSBZB-1 USB stick
Lock: Schlage (Allegion) BE469ZP Connect Smart Deadbolt (Z-Wave)

Some observations:

  • If I alternate calling lock/unlock from HA without physically manipulating the lock, then the call doesnā€™t fail
  • If I wait a few minutes after physically unlocking it, then sometimes lock.lock works on the first try
  • The opposite is also true: if I physically lock the deadbolt, then lock.unlock fails once
  • The lockā€™s ā€œlock_statusā€ attribute is often incorrect or misleading (says unlocked when itā€™s really locked, etc.). I can provide more detail on this if it would be helpful

My Z-Wave configuration:

zwave:
  usb_path: /dev/ttyUSB0
  network_key: !secret zwave_network_key

The API call from the Developer tab:

Service: lock.lock
Entity: lock.schlage_allegion_be469zp_connect_smart_deadbolt_locked
Service Data: { "entity_id": "lock.schlage_allegion_be469zp_connect_smart_deadbolt_locked" }

I tried setting the ZWave logger to debug but couldnā€™t find anything helpful in the log, though maybe someone can tell me what to look for.

Would really appreciate any advice!

2

Bumping this as I am all out of ideas. Please let me know if thereā€™s anything I could have done to improve the post.

3

Try checking the zwave logs themselves from the Zwave config panel. Keep in mind that locks are secure devices which means they take longer to send info over to HA and read them. I would say after about 5 seconds or a lil longer your lock will respond to the command. I am guessing you may have dropped command errors in the zwave log and if that is the case then your issue may be with interference. However if you are trying to lock the door immediately after you unlocked it then you are probably bottlenecking something.

4

Thanks a ton! It turns out I am getting a ā€œdropping commandā€ error in the cases where lock or unlock fails. So youā€™d guess this is caused by interference, rather than a bottleneck of commands? Thatā€™s confusing because I can repeatedly and quickly lock/unlock from HA without fail (takes 3-5 seconds), but something about locking/unlocking by hand affects the ability of the next command to go through.

This is particularly problematic because I have a door sensor that triggers lock.lock when the door is closed; if Iā€™m leaving the house, I unlock the door manually and close it behind me, but lock.lock usually fails because I just unlocked it manually.

Should I just add a ~20 second delay on the autolock automation? Hopefully thereā€™s another workaround since itā€™s unnerving to walk away without hearing the door lock behind me.

5

Well the lock itself does an autolock feature of 30 seconds. Personally I lock my door after 3 minutes because sometimes I may be coming in and out of the house so I donā€™t notice it. I would add a delay personally because the lock is probably not accepting commands at that moment.

6

Makes sense. I disabled the 30 second feature because I got tired of it locking while the door was open. I suppose Iā€™ll just add a delay to my existing automation.

Last question, then - do you know how I could call lock.lock until there is confirmation that it worked? Loosely speaking, something like: when the door becomes closed, while lock is unlocked, loop through: [lock.lock, wait 1 minute]. That way I can rest easy that the command didnā€™t get dropped after I left the house. I guess a trigger with the time platform would do it, rather than triggering when the door goes from open to closed?

Really appreciate your responsiveness. This has been very helpful.

1 Like
7

Quick question. How is your zwave mesh? Do you have many non battery zwave devices? I have three zwave locks, and have communicated with several people in the community. The most common issue when things work sometimes and not other times, is a poor zwave network. Especially with battery powered devices such as locks. You should not have to add delays, etc.

8

You may also want to watch the ā€œalarm_typeā€ sensor that was createdā€¦ see if it goes to ā€˜9ā€™ after a manual lock/unlock. (you cannot remotely do anything in a ā€œlock jammedā€ state until the next manual turn is successful, without jamming.) My one lock was doing that pretty bad so I lubricated it, checked to make sure the mounting plate wasnā€™t overtightened, and it has been much better.

9

Interesting. I actually just have this one (battery) deadbolt as far as zwave devices. The Pi + USB zwave stick are only about 15 feet from the lock so I would have thought that would work well enough, even without a mesh of non battery devices?

This is probably irrelevant, but the same USB stick also controls 2 zigbee sensors and 3 zigbee switches (all battery) and there a Hue hub on the same table, though it sounds like zigbee and zwave donā€™t generally interfere with each other.

10

Dang, looks like itā€™s alternating between 21 and 22 like it should, and it turns easily. Appreciate the suggestion! I feel like this is on the right trackā€¦thereā€™s something about a manual lock/unlock that seems to jam up the network in a way that rapid lock/unlocks from the API do not.

11

I have the same controller, and it also controls quite a few zigbee devices. When I first moved from Smartthings to Home Assistant, my locks were one of the first things I moved over. I had issues exactly like you report. If you read through the community, youā€™ll see that most people who report issues with locks usually only have one or two zwave devices. Even being 10-15 feet away. After I moved over the rest of my powered lights and switches the problem went away.

I just feel bad for the people who spend days, weeks, tweaking thier configuration to try to make it work. When it should just work. The code for HA and locks is solid. if youā€™re not having an automation, script, template issue, and just an issue with locking/unlocking via the HA UI, itā€™s almost definitely the zwave mesh. Some people are luck enough to get it to work with just a device or two, but many do not.

Try the usual, unpair from zwave/ha. Reset the lock itself. Re add the lock securely like before. It may help. If that does not help I recommend getting a wall switch or two, or a zwave repeater.

12

Bummer! Good to know that Iā€™m not crazy, though. Will definitely try the things you suggested. Very glad there are folks with more experience troubleshooting this stuff than myself. Thank you!

13

I know this was a while ago but Iā€™m just recently converting to HA and experiencing the exact same problem. Were you able to get this sorted? Did adding wired zwave devices help?
Thanks in advanced for any feedback.

14

This actually fell off my radar as well, so no update unfortunately. Couldnā€™t justify buying a zwave switch just for this issue after all. I ended up adding a fail safe automation that locks the door every minute if itā€™s closed, instead of just triggering once when the door closes.