Detect when a door fails to lock in Rule Machine

Hey folks,

I have two Schlage smart door locks. On occasions when the door isn't fully closed, the smart lock tries to do its thing and fails because it can't properly extend the deadbolt. I figured I'd create a rule to detect this condition (which proved trivial for overhead garage doors) but, so far, I've been unable to track this state.

When I create the conditional trigger using the lock devices, the only events they seem to publish are "Locked", "Unlocked" and "Changed". I've tried using "Changed" but if it doesn't successfully change, this condition never evaluates to true so the actions never run.

The event log for the lock does know that the failure occurred--is there a way to use that event within a rule?

Any other suggestions, of course, most welcome!

Thanks!

The lock won't give you a failure state, AFAIK. But you can know:

  • Is the door open or closed, and for how long
  • Is the door unlocked or locked

I use a combination of the Notifications app to tell me if the door w/the lock has been open more than x minutes (I actually have two notifications, one tells me when it's open for 5m, and another when it's open for 15), and a simple rule that auto-locks the door if it's closed for 7m (in case I'm just out in the front yard for a bit doing sommething).

There's also an auto-lock app w/a TON of options in HPM:

Since you can't get failure to lock notification, getting open/unlocked, or closed>lock action can be used to fill in.

Does this show in the events page from the device page? Are one of the state values for the lock updated when the failure occurs?

Rule Machine can only act on actual lock events. There may be additional information that shows in the logs, but unless it shows in the "events" section of the device page, then it cannot be used in RM.

What you can do in RM is setup a rule to notify when the lock command is called, but the lock remains in an unlocked status after a set period of time (basically what Auto Lock does, but it has a number of other features). To do this though, you'd want to setup a virtual lock and tie that to a rule. Just like you found, rules run on events which (typically) occur by an update from the device. If the physical lock never updates, then the rule will not trigger. Using a virtual lock would ensure that the device update occurs (since it's not necessarily tethered to the status of the physical lock).

So, your rule would be something like

Trigger:
Virtual lock locked
Virtual lock unlocked

Actions:
IF(virtual lock unlocked) THEN
	Unlock physical lock
ELSE
	Lock physical lock
	Delay 10 seconds ### Can be tweaked to the expected amount of time for the lock to successfully lock###
	IF(physical lock unlocked)
		Notify: "Lock problem" ###Or whatever message###
	END-IF
END-IF

All I see on my Schlage Device page in Events related to lock commands is below, I don't see errors when it doesn't complete, but the lock will accurately report it is unlocked when lock fails:
image

I figured. It was more meant to be a leading question so the OP would know where to check besides the logs. I've edited my post.

1 Like

Thanks.

I already have all that stuff setup. When one of those auto-lock events triggers, I want the Sonos speakers to tell me if it fails like they do with my door sensors, garage doors, etc.

// EDIT: missed the HPM app--I'll take a look. :+1:

1 Like

Thanks!

The event does show up in the device's Events page, yes. I was hoping there'd be a way to consume that even if the trigger was something else.

I've tried what you suggest but RM doesn't trigger unless the lock event results in a locked state--that is, it's not triggering on the request to lock, it's triggered by the resulting state... which never gets there because the deadbolt can't extend fully.

Here's a high-level descriptive view of some of the related the rules I've got so far:

... and the details of the individual rules I have for both the front and back doors:

I created two isDoorLockedDelayed booleans that track the state of the locks with a 20s delay in an effort to trigger the rule on "Lock changed" and then use the delayed state relative to the "Changed" event to infer that the event was a lock, not an unlock--obviously, that's not working either.

II wonder if there's a variable that contains the "Command" or "Command called" string--I'll go check and see.

That leads me to wonder: is there a way to enumerate all of a given device's variables?

Then the attribute/value pair listed for the event is what you want to check for in the rule. When I say "has an event" I do specifically meaning a "jammed" (or something similar) event. Not the standard lock/unlock.

Barring that...

You can swap the physical lock device for the virtual using "Swap Apps Devices" from the main Settings menu.

1 Like

Does this show up in the descriptionText logs or on the device's event page?

In either event, what is the precise wording of the text in the descriptionText logs? It is possible to use that as a Trigger in Rule Machine, after converting the descriptionText log to a hub variable.

If you post a screenshot of the log, I'll post JSON for rules you can import.

Appreciate the input all!

Summary: the lock has no "in progress" state of any kind, only resulting state. If a lock attempt fails, there's no way to detect without knowing what the action was--I've found no way to determine that programmatically. I was also incorrect that the Debug log contained the lock's failure to extend the deadbolt--the error was a battery warning after I dug a bit. My bad.

I've spent the past hour setting up a virtual garage door controller (that does support interim/in-progress state) and using it to abstract the real lock. I've finished creating the rules to sync the state of the virtual device to the smart lock. I used the device replacement tool to switch all existing rules. I'm now in the process of creating a rule that triggers when the virtual garage door is in a CLOSING state, I'll start with an event delay on the real lock with a 10s timeout that then checks the realtime state of the lock. If it's still unlocked after that, then I know it failed.

I think this'll work so, optimistically, thanks again for all the input (I might yet be back if it doesn't).

Also open to other ideas. :+1:

Per the post above: I was also incorrect that the Debug log contained the lock's failure to extend the deadbolt--the error was a battery warning after I dug a bit. My bad.

Would you mind posting a sample of that anyway for mine and other's education?

Thanks!

I’m on my mobile right now, but you can find several examples if you search for instances where people have needed to know whether a lock has been closed using the thumbturn (from the inside), or a button (from the outside).

I’ve posted at least one such example in the last year or so. But there are other similar approaches that have been posted.

Edit: here you go

1 Like

It does log the thumb vs. digital actuation. :+1:

That's awesome--thanks so much. I'm sure that'll come in handy very soon given how much time I spend tinkering now.

If you save your other "event" to a hub variable, you can use the variable changing as a trigger. And use a condition to test whether the change contains the desired word before proceeding with the rule.

Just tried to import the JSON to keep it handy on a paused rule until I need it but when I select Restore Apps, I get:

Realtime log indicates pretty much the same:

... I'm thinking glitch so maybe a reboot but any thoughts?

Have you looked at the Auto Lock app yet? It is pretty extensive in its scope of actions, options, notifications, etc. I know it's fun to play w/custom automations, been down that rabbit hole many times myself, but the auto lock app might be "enough" and simplify your life...

I started to and got distracted with my own idea... kindred spirits of tinkering ratholes I guess :slight_smile: .

I've proven this approach works now so I'll move on to my next project for the moment (deterministically detecting when my FPL power is down and my Generac is running... kinda working but I've got a new air pollution Zigbee sensor that I think'll nail it for me).

That said, I do appreciate the pointer and am steadily learning that I should start with HPM before going off on my own (fun as it may be).

Thanks again!

1 Like

It's one of the best features of HE, frankly, and totally community developed and maintained. Kinda cool... :smiley:

1 Like

My back door wasn’t closed all the way this afternoon when I went on the patio. I heard my Schlage Zigbee lock attempt to lock and yes it does report an unknown state:


Bottom/first event was it trying to lock and second is the failure and top/third is when I manually locked it.

2 Likes