Haha! The Law of Leaky Abstractions – Joel on Software (Different Joel. Not me. But his blog is on point.)
Ok, I just published an update for the battery issue.
1 Like
@jwetzel1492 I use this for one of my door locks (my only smart lock) and it is flawless. I wish you made this for garage door openers too! Nice job!
1 Like
Hey @jwetzel1492 any idea why this virtual lock isn't supported by google home?
One of my main reasons of using this app was to keep from having like four different rules and a virtual switch for google.
Here is the line from the logs:
app:682021-04-09 09:52:09.784 pm warnThe following devices are not supported by Google Home and will be removed from your device list:[Reliable Front Door]
Ah. I see. Locks don't work with Google. I would suggest changing the instructions to remove the Google Home since that doesn't work. Thanks!
I created a pull request on the code to change this.
Are you using the in-built Google Home application? Or the community "Google Home Community" app ([Alpha] Community-maintained Google Home integration)? I use the latter, and can control my door lock from my Google Home Hub and phone.
@jwetzel1492: Wow, what a good piece of software ! I hated all my 3 Schlage Connect, they were working occasionnaly. I tried Reliable locks and did many tests and for now it is working like NEVER before ! Thank you so much.
2 Likes
You can always install a separate Battery tile. I have a separate Dashboard just with all the batteries.
Thanks for the great app. Its a game changer with respect to my four locks. Just a quick question (and execuse my coding ignorance). I want to increase the number of times the app will retry to lock/unlock. To do this, do I change the 5 (circled below) to a higher number or is there another section in the code I should change? Thanks again!
No, that's an indication of the delay (in seconds) before that particular command will be run.
That’s correct.
Would it be possible to request this be a configurable parameter in your next release? Or is there a reason why it shouldn't be changed?
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.
