Is there any way to clear the name of the last user? …or set it to something else? That doesn’t update when locked or unlocked from the inside…or when locked or unlocked by the hub.
There’s more than one way to solve this, but that would make it really simple. “Who” actually unlocked the lock might not update for month if everyone else doesn’t actually need to use the keypad because the hub does it…or they use the “thumb” turn on the inside.
That is still accurate, it is the last person to used the keypad. That could be info you want to know a few days later, but if it got updated to "unknown" or "physical" when the lock was changed in other ways, you lose that info.
I'm just not clear why you would want to clear that... it is still accurate to the last person who used the keypad. Does the driver at least give you a timestamp of the last manual unlock? That does seem like info that could be handy, but I don't see why it needs to wipe out the accurate history of who last used the keypad.
Because it’s easy to write a rule that triggers off…
If the door is unlocked by “X” do “Y”
Without having to do something like match text that include “thumb” or somehow match that the hub unlocked it by another rule.
“Who” unlocked the door 3 days later can be found in the logs. I can’t think of a single rule I’d build that would be based on anything except who “JUST” did something. Forensics are more what logs are for.
Hope that helps.
.BTW…there are last activity timestamps..but not anything tied to the username field that I can see…even deleting that user from lock doesn’t clear it.
The attribute is called “lastCodeName”. It will only change when a user code is used to initiate an unlock event.
lastCodeName should not change when the lock is locked/unlocked using the thumbturn (physical), when locked using the keypad (physical), or when locked/unlocked using another app (digital).
As with other events, lastCodeName will only work as a trigger in the instant that it changes. It will not act as a trigger at a later point of time, or when the lock is locked/unlocked by the thumbturn, or digitally, or locked using the keypad.
Rule Machine provides other means to use physical/digital events as triggers. Sample rules distinguishing such events can be found on the community. Here’s one such example:
If needed, such events can be used to populate a hub variable, which can serve as a trigger for other automations.
THANKS as always …you guys are really fast!
What is the benefit from a rule perspective to know the name of the person who unlocked the door a week ago? That is my opinion though..maybe nobody else cares and that’s fine.
The problem is currently…from what you guys are saying…anything matching the user is going to fail…unless the last person who unlocked the door physically is the same person who did it last with the keypad. It seems like a great time to change the user to “unknown”…since that’s what is really happening.
I can already copy %text% to a local variable and determine which part of the lock was used to open the door. Like I said in my original post…I can write more complicated rules and get around it the username not updating.
It just seems to makes sense to me that if the last time the lock was unlocked or locked…it wasn’t associated with a user…that field should not list a user.
To me, it’s just how “I” wish it worked …and the only answer I guess is really…it doesn’t …not for what I want to do.
All that said…it’s still awesome that I can do work arounds and make this work on the hub! This is without a doubt the best platform on the current market IMHO.
Where are you getting this from? As explained above, a change in lastCodeName will act as a trigger only in the instant of that change. It will not act as an automation trigger a week from now (unless the RM trigger option “and stays …” is used). Perhaps there is a fundamental misunderstanding here of how Hubitat triggers function.
Matching a user will only work when a code is used. All other lock operations (physical and digital) are not user specific, and therefore lastCodeName should not be used as a trigger or condition in such automations.
Your suggestion of changing the content of the lastCodeName attribute for all lock operations is something you should take up with lock manufacturers. For all locks I have had (Schlage, Kwikset, Yale), a code is only sent by the lock with lock operations that use the code. For example, such information is sent by the lock when a code is used to unlock. But code information (or even a blank code) is not sent for physical and digital operations. It would be presumptuous for Hubitat or any other automation system to randomly stick in a code (or delete it) under these circumstances.
OK, so that field is basically useless for anything but forensics and can’t really be used in a rule at all. That is the answer. THANKS!