Reliable lock is draining my lock's battery life.
Do you have an automated refresh running every minute or something like that? Other than that, there’s nothing in Reliable Locks that would drain your battery. (And the impact of too many refreshes would happen even without Reliable Locks)
I have it set every minute. would that cause any draining?
Yes, you’re forcing your lock to wake up and communicate every minute. That will take a toll on batteries.
1 Like
So i was finally able to create the virtual switch function, but when the lock is basically auto locking every time it refreshes.
If i manually unlock / or use the switch to trigger it, it will lock again the next update cycle instead of just updating the switch status
That is quite odd. There’s nothing in the refresh code that could cause a lock. Can you turn on debug logging for both Reliable Locks, and on your lock device, and then send logs?
I can do that later.
I removed the app for now so I don't drive the wife crazy today. gotta keep the WAF high so i can tinker
1 Like
I just got onto Hubitat and am generally pleased compared to SmartThings. I am however having issues with some of the built-in applications being restricted to switches and dimmers only - one example would be the Groups and Scenes.
I downloaded the reliable locks app and wanted to incorporate locking our house into several scenes but couldn't. I therefore modified the driver code to include a "switch" capability and "on" / "off" methods to make it compatible with Groups and Scenes.
@jwetzel1492 - LMK if you want me to send the changes your way in case this is of interest to the community? It was a simple add-on capability and a couple of methods. Otherwise, you may want to just apply those to the next version of the code to add some flexibility where the Hubitat out-of-the-box framework does not offer it?
Thanks for writing this - I expect it to be very useful in my transition from ST !
Added app & child at 9:36, 9:54 unprompted refresh shown, and the lock changed to locked on the door.
Lock Instance Logs::
2020-10-12 10:03:34.144 pm debugCurrent Status: null
app:5922020-10-12 10:03:34.085 pm debugFront Door:refreshing
app:5922020-10-12 09:54:43.178 pm debugCurrent Status: null
app:5922020-10-12 09:54:43.083 pm debugFront Door:refreshing
app:5922020-10-12 09:36:12.724 pm debugFront Door Switch:setting unlocked
app:5922020-10-12 09:36:12.721 pm debugFront Door:unlocked detected
app:5922020-10-12 09:36:12.586 pm infoInstalled with settings: [enableDebugLogging:true, refreshTime:6, retryLockCommands:false, wrappedLock:Front Door, autoRefreshOption:30]
Physical Lock Device Logs
dev:1982020-10-12 09:55:31.630 pm infoFront Door was locked via command [digital][24]
dev:1982020-10-12 09:55:31.627 pm debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:24, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:0, zwaveAlarmStatus:0, zwaveAlarmType:0)
dev:1982020-10-12 09:55:31.566 pm debugparse: zw device: 07, command: 9881, payload: 00 71 05 18 01 , isMulticast: false
dev:1982020-10-12 09:55:18.674 pm debugskip cmd: ApplicationRejectedRequest(status:0)
dev:1982020-10-12 09:55:18.654 pm debugparse: zw device: 07, command: 9881, payload: 00 22 02 00 , isMulticast: false
dev:1982020-10-12 09:54:46.732 pm infoFront Door is unlocked
dev:1982020-10-12 09:54:46.726 pm debugDoorLockOperationReport: DoorLockOperationReport(doorCondition:2, doorLockMode:0, insideDoorHandlesMode:0, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
dev:1982020-10-12 09:54:46.660 pm debugparse: zw device: 07, command: 9881, payload: 00 62 03 00 00 02 FE FE , isMulticast: false
Any way to get the battery level to display as well?
Hmmm, yes I could probably pass that through. Might take a couple days to get to it.
Figured it'd help when using battery monitoring app.. have everything to use the wrapped handler vs the actual device.
Great app, the only thing that makes my August Pro lock sort of reliable. I had one question, is there any way to notify a device if after the set amount of retries (3 I think) and the command is still not followed?
Ah, interesting idea. I could probably add that at some point.
1 Like
Ok, I just release v1.2. (Best way to get it is with Hubitat Package Manager)
2 new features:
- Set a notification device to receive notice that repeated lock/unlock attempts have failed.
- Battery reporting. Battery reports from the real device get propagated to the virtual reliable device.
Ooh, hold on and don't update. I introduced a bug when I pushed it to github. v1.3 coming up in a minute.
Ok, v1.3 is up and fixes the bug.
Nevermind, battery reporting is working now
Has anyone been able to change the lock being wrapped after the instance has already been created? It seems to work successfully, but then the logs are full of cannot get displayName of null device and upon further investigation it appears that while the device label is changeable and mutable to the user. The device name is not, and does not appear to be reinitialized when wrapping a different lock in the same instance. This seems to cause the instance to go wonky and still try to communicate with the old lock.
Anyway, I got around it by making a new instance, but I was just wondering if this is a bug or by design.
Lol I had never considered doing that! Yeah, that would probably break things. In theory, I should lock it down so that you can’t do that, but to be honest, it’s pretty far down on my priority list. In the meantime, don’t do that! 
2 Likes
