Seems like Lockdown is more to stagger the events using a virtual switch. I guess that is nice, and I could see myself using it, but in my case I would also need "Un-lockdown". For now all I really need is....
Truly "Reliable Locks" - (I never thought there would be anything I missed about ST. This is it!)
@jwetzel1492 I would be endlessly grateful if you could add this feature to resend lock AND unlock commands every 10 seconds until it locked/unlocked! If you do please let me know when to update and I will happily be a test dummy!
Any thoughts on when you might have a chance to add it? I am hoping to not have to put these locks back on ST, but planning a trip and need them to be reliable while we are gone.
Good news! I've posted an update to GitHub. You only need to update the ReliableLocksInstance.groovy file for the child app.
There's an option: "Retry lock/unlock commands if the lock doesn't respond the first time?" I found that I had put comments in to explain what this SHOULD do, but I hadn't actually implemented it before I got distracted by something else. It is implemented now.
It will retry up to 3 times. (Though you can easily change that in the code. Look for the number 3 on line 180.)
(Sidenote: I would not rely purely on smart locks for security in a house. What I mean is that if I were leaving on a trip, I would not drive away with the house unlocked and then lock it on my phone. I would make sure things were locked before I left. However, I'm guessing maybe you're using it to let people in and out of your house while you're gone?)
I just wanted you to let you know this has made ALL the difference with my locks. I have not had to request a second "Lock/Unlock" since installing the update.
I will be recommending this to anyone I see that has any issues
It makes me wonder if other hubs implement a similar process by default which makes them better than HE with locks. Either way mine are truly Reliable Locks now thanks to your update.
below are all today's logs for that lock (some overlap).
I had not given it a command just noticed it was "unlocked" but my Dash said "locked" so I looked (now that I think about it I did a manual "refresh") . It seems like "refresh" or 30 minute refresh does not "retry", but when a command is sent it does.
That might be by design, and my lack of understand the app.
My locks are working much better, but sometimes they stop reporting. No clue why. A reboot always fixes it.
Is there a way to base a rule, to reboot the hub, on when reliable locks does not get a response from the lock after x amount of minutes, or retries? Sorry I don't know how that works if this is a dumb question my apologizes.
IMPORTANT UPDATE: Reliable Locks can now be installed from Hubitat Package Manager. This is the best way to make sure you keep up-to-date with bug fixes and new features.
You could certainly do that. In ReliableLockVirtualDevice.groovy, you'd need to change the capability from Lock to Switch. Then it would mostly be a find-and-replace to change the names of the events and attributes that it and the app instance deal with.
Great App. Thanks for posting.
Can i ask 2 questions please.
i have an auto close set on my Kwikset ( programmed at the lock...will lock 30 seconds after opened) No reason that this should interfere with reliable locks is there? thinking that if I send sn open command then 30 seconds later it locks will this cause any confusion.
i like the status refresh...any chance this concept could be applied to the garage door status or open / close command?
You could certainly make a variation of this that did refreshes on garage door status. I think I would do it without any retries. For example, if the reason that the door didn't close is because the electric eye saw something in the way, it would be bad to keep retrying.
Thanks. I’m thinking mainly for the status. For some reason I’ve been seeing the door open and the status hasn’t updated. Hoping this might pick up on that.
Regards.
Mac
Thank for very much!
issues
