I have kind of a weird problem. So, I have the Kwikset 916 locks. The Zigbee works fine and when it "jams" (i.e. the door attempts to lock, but the bolt doesn't successfully go in), it changes the lock status to "unknown" so I can easily create a notification when the lock status becomes "unknown".
However, I discovered a bug earlier this year on the Z-Wave version of the lock. Detailed logs in one of my older posts: Z-Wave Kwikset 916 Jammed Lock Bug - #10 by HarleysWorld
I still have 2 of these locks in our home. What I have noticed is when the Z-Wave locks ATTEMPT to lock, but "jams", then the status REMAINS "unlocked" (instead of becoming "unknown" in the Zigbee version). Short of replacing the locks, how can I write my rule to catch this event?
I'm not sure if you can create a rule that trigger s on the lockING action or the "lock() command executed". Essentially, the Z-wave lock will execute the lock() command, but the status remains "unlocked" and I want a rule that basically says:
Trigger: Lock executing lock() command
Rule: Wait "x" seconds. If status = "unlocked", send notification.
It doesnāt Itās because the status doesnāt really change. Like, it would have been different if it went from unlocked to locked then back to unlocked during the jam, but as far as the rule is considered nothing has changed. I feel my only option is to trigger on the ālock()ā command that you see in the debug.
I donāt have locks to test this on, but I would think that when you send a lock command to the lock, it would generate a lock() event that could trigger a ruleā¦ If not, @TArmanās suggestion sounds like a good one.
His suggested rule could also wait to only lock once the door is known to be closed, and notify you when you try to lock an open door, or if the command is not successful.
Itās in the logs if I have ādebugā on. But, this is what I donāt know how to do. Like which option to pick on RM so I can use the lock() event that you see in the logs when the debug is on as a trigger. Do you know what option that is on Rule Machine? Sorry. Not super savvy with RM yet.
This only happens if the command is successful and the device sends a report back to the hub. Sending a command does not normally do anything on its own.
From the logs posted in the other topic, this lock doesn't seem to send anything when the lock is jammed, which is what would be really helpful to make this work on a driver. Without that, the virtual device idea seems like a reasonable approach with what's built in (if you really need a separare status from "unlocked," which is also likely true).
Iām intrigued! So, I need rules that make sure the statuses are synced right? So when I physically use the lock either via keypad or knob, itāll update the virtual lock. But, I should make all my ādigitalā operations be on the virtual lock and have a rule that says whenever theyāre not in sync, then throw a jam notification?
Nooooo. Okay Iāll have to play around with the virtual lock idea then. Not 100% sure how to go about that. Iām guessing itāll involve several rules?
Since the lock didn't complete the action, the driver may not have updated the lock status. Try adding a refresh command at the start of the rule with several seconds of delay to make sure you have the current status.
When I was doing these tests, I was just hitting the Lock command on the device page while leaving the door slightly ajar. It definitely just stays as unlocked and never updates to unknown like the Zigbee version
The Zigbee version works fine because it actually changes the lock status to āunknownā so I believe I can create a ālock status is changedā rule in RM, then check if that status is āunknownā then do a notification.
That makes sense, but we have 7 exterior doors and while we make sure the front door is locked as we leave, sometimes we forget about the others. We have an automation that locks all our doors for good measure once we leave the house (using the combined presence app of geolocation & WiFi). Itās fairly sensitive so it would give us time to turn back to lock any doors that fail to do so.
I had to add "not closed" to the doors Inovelli switch notification bar rule for our out of sight garage man door after discovering it was locked but not closed one evening. That door is now represented by a virtual lock that requires both locked and closed to show as locked.
Itās because the status doesnāt really change. Like, it would have been different if it went from unlocked to locked then back to unlocked during the jam, but as far as the rule is considered nothing has changed. I feel my only option is to trigger on the ālock()ā command that you see in the debug.
