Thanks for that. Generally all my locks work fine with the default value. It’s just ever so often one doesn’t so I’m hoping increasing the number slightly will eliminate this.
1 Like
I had the same issue and it seems to have done the trick for me. Thanks for figuring this one out.
1 Like
I have one of these annoying Kwisket zigbee volts.
Main problem I'm having now after implementing the reliable lock app is that manually locking/unlocking the lock physically does not report the state change.
I have some automations setup that get triggered when the lock locks/unlocks but it only works when I do it via software. Locking/unlocking physically does not report the state change. I can go into device of the actual lock, click the "refresh" button then it pushes through the lock status change
Hi, I'm using this app now for a Kwikset lock which I've had issues with staying connected.
I noticed in the logs these entries repeating over and over though.. any idea what's causing this? (app:408 is my Reliable Lock instance)
app:4082021-08-24 09:36:39.028 am errorjava.lang.NullPointerException: Cannot get property 'displayName' on null object on line 246 (method batteryHandler)
app:4082021-08-24 09:36:39.003 am debugFront Door Lock (*):battery detected
app:4082021-08-24 09:36:36.032 am debugFront Door Lock (*):refreshing
...
app:4082021-08-24 07:36:36.039 am debugFront Door Lock (*):refreshing
app:4082021-08-24 07:13:36.738 am errorjava.lang.NullPointerException: Cannot get property 'displayName' on null object on line 229 (method wrappedLockHandler)
app:4082021-08-24 07:13:36.729 am debugFront Door Lock (*):locked detected
...
app:4082021-08-24 07:11:49.061 am errorjava.lang.NullPointerException: Cannot get property 'displayName' on null object on line 235 (method wrappedLockHandler)
app:4082021-08-24 07:11:49.037 am debugFront Door Lock (*):unlocked detected
thanks
Those lines (246, 229, and 235) are where it's interacting with the virtual "Reliable Lock" device that it created when you set it up. Does that device still exist? (You should be able to see it in your devices screen.)
Yep, both the real and virtual locks still exist. I did rename my actual lock from "Front Door Lock" to "Front Door Lock (*)" after setting up the reliable lock - only so I wouldn't get the 2 confused. Do you think the name change or the * symbol is creating the error?
Yeah, that's the problem. Behind the scenes, the virtual device is named relative to the real device. So, see how in parenthesis, the reliable one says "Reliable-Front Door Lock"? It got that name when you created it. But since you changed the name of the real lock, the code can't find the virtual device.
I should probably investigate if there's a better way to get a reference to the virtual device. But I probably won't have a chance until at least the weekend.
@jwetzel1492
Use DNI as the unique identifyer. Throw in there something like "ReliableLock_AppID"
Here's an example I use in one of my apps:
addChildDevice("hubitat", "Virtual Presence", "CombinedContact_${app.id}", null, [label: thisName, name: thisName])
You can use something like this to modify the value:
if (present) {(getChildDevice("CombinedContact_${app.id}")).arrived()}
Then it doesn't matter if they change the name. Hope this helps.
4 Likes
Will this work with a garage door opener?
Wasn't written to do so but you could probably do so through virtual device association. Use the door opener as the trigger device, virtual lock as the trigger to open or close, and then create a rule when locked close the door or when unlocked open the door.
1 Like
Actually, I came across your z-wave garage door driver code for gocontrol/linear.... 
Np, just wanted to make sure you had an option.
Thanks. Can you give a bit more description of the advantages of the gocontrol garage door driver you made? Feel free to DM if preferred.
@jwetzel1492 Hey Joel, thanks for the Reliable Locks app. I just submitted a pull request to support an "unknown" state from the underlying wrapped lock: https://github.com/joelwetzel/Hubitat-Reliable-Locks/pull/4
My Yale lock recently started getting jammed on the door frame and it was reporting "unknown" but the Reliable Locks instance of the lock reported "unlocked" (which wasn't totally accurate).
I wasn't sure if there are other models of locks that set the lock property to something other than unlocked (the else statement didn't have a else if conditional so anything other than locked was considered unlocked so maybe there are other locks that send something else?) but I figured I'd offer this PR. Feel free to modify if necessary.
2 Likes
Have been using this app - works great. I would like to do something similar to this with some of my shades. Does anyone know if anything exists? If not I was going to see if I could modify this code to achieve that.
Been using this app for a while and it's been super reliable (no pun intended) with my Schlage locks. Wondering if it's possible to have this expose the code entered to open so automations can be triggered for certain users?
It’s already a trigger in rule machine - lock code and then name of lock code.
Got it - I don't use Rule Machine ( I used an external rules engine ). As this need is a rare one-off I guess I can figure out what I need it to do. I just need to trigger a mode change based on an entered code.
