Door Lock Inconsistant

[broyuken]

Describe the Bug

Zwave door lock doesn’t consistently lock

Steps to Reproduce

Click lock card, or have lock automation. Sometimes it works, sometimes it doesn’t.

Expected Behavior

It works every time.

Log Output

On mobile right now but will get logs tomorrow.

Screenshots

Config File

mqtt_url: mqtt://auto_username:auto_password@auto_hostname
mqtt_options: ""
livestream_user: xxxx
livestream_pass: yyyy
disarm_code: ""
enable_cameras: true
enable_modes: false
enable_panic: false
branch: addon
debug: ring-*
location_ids:
  - ""

Install Type

Addon

Version

V5.6.7

Operating System

HAOS

Architecture

X86_64

Machine Details

NUC

[tsightler]

Out of curiosity, what do you think can be done about this? Is there something in the ring-mqtt logs that makes you think this problem is related to ring-mqtt? Overall, ring-mqtt simply sends the lock/unlock command to the Ring API, which sends it over the websocket to the Alarm base station, which then sends it via Z-wave to the lock. The command either fails or it doesn't at any point along the chain. If the command fails, the lock should revert to its current actual state, from the "locking" or "unlocking" state. It's not clear what else could be done or why you believe this is a problem with ring-mqtt vs some other component of the chain. What do the ring-mqtt and Ring history logs show during such an event?

[tsightler]

Closing due to no response. I don't think there's anything I can do about it anyway.

[broyuken]

That's fair, I'm still trying to narrow down if this only happens through HA or if the app does it at times too. I don't use the ring app very much so tough to tell. I also had my automations calling a lock group, instead of the individual lock which may have been causing an issue as well. I'll do some more testing and if I think this may be ring-mqtt related I'll open a new ticket.

[tsightler]

I own a Kwikset Z-wave lock that is paired with Ring for testing purposes. I also see occasional failures for lock/unlock operations, but I see this with the Ring app as well and the event is logged in the Ring app in all cases, thus I don't think this can be related to ring-mqtt, nor do I think there is anything I can do about it. Ring does appear to support "jammed" state, which many locks have.

You don't have to use the Ring app per-se, just, when you notice a failure, look at the device history in the Ring app/web console and see if it displays a failed lock/unlock attempt. That is enough to show if ring-mqtt is doing its job or not. In my case, when there is a failure, there is always a corresponding entry in the Ring history log for the device so I know ring-mqtt is sending the command and it's failing further down the line.

I suppose I could add some kind of retry logic if it fails to enter the requested state in a given amount of time, but this can also be handled in an automation and I'm not sure I want to get into putting that kind of logic into the code because it is difficult to do correctly and satisfy everybody so, today, I just leave it up to users to deal with failure cases in their automations as you have to assume failures will happen in any case.

Will be interested in hearing what you find out. Thanks!

[broyuken]

I see a failed to lock by home assistant (the user name I have set up for the integration) every time there is a failure so it looks like ring-Matt is doing its job on my side as well. I’m debating moving the lock directly into HA but I like how ring lets me easily create door codes and sync it with the alarm.

[tsightler]

Yeah, that's exactly why I have my Kwikset lock configured this way as well, all of my other locks are direct to HA, but that single lock is used for access with a code and it's just so much easier to setup and share codes directly in the app vs setup code in HA and create automations to disable alarms, etc. But I do see the same failure issues.

I'll think about the idea of adding a simple retry logic, I have something like this in the alarm control panel for failed arm attempts.