Detect when a door fails to lock in Rule Machine

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

Reports on mode.change if locks fail to.lock or doors are open etc.




2 Likes

Just remembered something (bit of DOH on my part)...the lock's built-in auto-lock setting. I don't use that on my Schlage BE469 and haven't remembered it until just now when I saw your description. My HE lock automations are set to only try to lock when the door reports closed, and in that state they are always successful. So it would be really unusual for me to see that type of error (only if my door contact sensor wasn't working properly).

I left the door partly open so the deadbolt wouldn't be able to close and locked it from the Device page and of course got the same "unknown" status. :slight_smile: So it does report something when a lock event fails, my bad... :slight_smile:

1 Like

Thanks all!

@danabw: just checked with my ex-ADT locks and they do not report an unknown state when the deadbolt fails :man_shrugging:. Doesn't matter now since my virtual garage door abstraction is working like a charm but that sure would've been easier.

@kahn-hubitat: very cool, very cool indeed! I'll take a look... nice job. :+1:

1 Like

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."

For our Schlage deadbolts, I use a rule like this to detect when the lock is unable to extend the bolt. The event text will be "{lock name} is jammed."

Thanks, Tom!

This is my problem--it never logs anything other than the resulting state of a lock or unlock command/event. If the command/event fails, I don't see that. I do see the command to lock and could obviously combine that with the lock's resting state a few seconds later by gleaning the logs but I learned that after I was done with my current solution.

PS: mine don't even support the event trigger "changed"--any rule I created using that event never ran.

Don't know if it's the locks or driver. I'm using the Generic Zigbee Lock driver with my locks.

I'm using Z-Wave. Have tried the generic driver as well as the model-matched Schlage driver but the behavior is the same.