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?
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
Virtual lock locked
Virtual lock unlocked
IF(virtual lock unlocked) THEN
Unlock physical lock
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###
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:
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.
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.
You can swap the physical lock device for the virtual using "Swap Apps Devices" from the main Settings menu.
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.
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).
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.
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.
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 .
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).