Refactored retry logic on locking, unlocking, and validation
Added jam detection and clearing attempts
Version 1.1.35 2/17/2021
Added locking and unlocking notifications.
Version 1.1.26 1/17/2021
Added locking options for lock, contact closes, presence departs, modes, hsm, and prevent locking under any circumstances.
Version 1.1.25 1/17/2021
Ability to create a virtual combined presence device from the parent app
Version 1.1.22 1/11/2021
Unlocking on presence arrival option
Low battery notifications
HSM Locking only when in certain modes
HSM Push Notifications of alerts
Set HSM Status when locked or unlocked
Able to select individual types of logs.
Version 1.1.13 1/5/2021
Added unlock dropdown selection to add or remove options from the display
Added detailed instructions for most of the controls. Thanks, JNS for the suggestion. Guidance is toggleable.
Use seconds toggles the language on the timer grammar to the appropriate metric.
Added presence arrival unlocking option.
Added state sync fix. If it finds itself in the wrong state, it tries to correct itself.
Resolved some issues with the pause and modes feature.
Version 1.1.6 1/3/2021
Reworked handlers to be more efficient and process locked door while the door is open.
Reworked retry logic and timers
Added options for both lock and unlock modes.
Added device status to the lock and door contact in the drop-down
Version 1.1.4 1/2/2021:
Configurable number and time between retries added
Spanning title issue fixed
Some under the hood changes to status updates
Some preparation work for future additions such as lock and contact status as well as battery percentages on the app page, presence triggering, and notifications.
Version 1.1.0 12/31/2020:
Fix for the only run when features
Added a check if the lock is locked while the door is open and automatically unlocks it.
Fixed some states where status could get out of sync.
Added current states to the lock and contact sensor drop-down.
This text will be hidden
Current Features:
Presence arrival unlocking option - recommend using combined presence with this feature.
Automatically relocks door when unlocked at a specified delay
Contact sensor optional.
Avoids locking while the door is open if a contact sensor is provided
Temporary logging options
Able to prevent the application from executing between certain times, certain days of the week, certain modes.
Override switch for when you want to keep the back door unlocked for parties or whatever.
Introducing Auto Lock:
This new app automatically locks the door after it is unlocked with a specified delay. I was looking for a locking app with parent/child structure to keep my apps organized so I came up with this. The original code is based on Chris Sader's Auto-Lock Door app with his permission. You can name the child apps whatever you like. I just used my lock names because it was simple.
Thanks for the additional cusomizations and options you've added, @lewis.heidrick! And thank to @chris.sader for starting this app, and graciously supporting Lewis' enhancements.
@lewis.heidrick - Can we assume this will migrate to HPM in the future?
New release out. Lots of goodies added. Configurable number and time between retries, spanning title issue fixed. Some under the hood changes to status updates and made some additions under the hood in preparation for future additions such as lock and contact status as well as battery percentages on the app page, presence triggering, and notifications.
@lewis.heidrick. Thanks for your work on this. Any thoughts of adding HSM status to the 'Only Run When' section? In my case I have Day, Evening, Late Evening, etc modes as well as Armed Home, Armed Night and Away for HSM. I only want some of the doors to auto-lock when in Day mode and HSM is set to Armed Home. When in AH the side entry to my garage isn't armed and I am in and out all the time so I don't want it to auto-lock but if I set HSM to AH I do want it to auto-lock. Thoughts? Does anyone else have a use case like this?
And just to confirm, I wasn't sure if the "Default to minutes. Use seconds instead." applied to both the lock delay and the retry timing. The retry timing field is separated from the minutes/seconds setting by the number of retries setting, so I wasn't 100% sure if the minutes/seconds applied to both.
How do retries work? As in if the lock fails, or if the door contact sensor isn't closed it will wait and re-try, or both? I'm personally interested in the latter (door sensor isn't closed)
If the door is open and the lock gets locked it will immediately unlock it and then retry if failed the retry number of times then give up. Until the next trigger event.
If so I just tested it and with the door open and locked it didn't unlock the door.
My thought is that there should be a separate toggle to enable 'unlock if door is open'
I was thinking that the retry meant the app would try to lock the door again X times if the first attempt failed.
Also, you have the lock status displayed next to the child app name. After testing the door open but locked thing I thought it would make sense to display both the lock state and the door state there.
The lock should try x times for each trigger event. If a new trigger event happens the retry counter is reset back to the variable. The door open does trigger seperate logic in that it takes a different set of circumstances to lock it again and it has unlock logic when open.
I have what might be a super specific feature request for just my use case so take it with a grain of salt:
Instead of enable/disable I’d actually like to be able to set a secondary auto lock time based on whatever ...switch/mode/button press/Boolean...
Example:
When our groceries are delivered on the front porch, and I need to go in/out a few times I could double tap the inovelli light paddle next to the door and the lock changes my default auto lock value from 3 mins to my secondary value of 10 minutes.
Bonus points if it automatically changes itself back to my 3 min default after the 10 min window executes.
——
Now that I think about it, guess it’s just a request for more control over the override option you already have...
So something like:
“When [virtual switch] is [on], override default lock time to [x] minutes.”
-or-
“When [virtual switch] is [on], disable default lock time”
followed by something like:
“Until [virtual switch] is [off]”
-or-
“Until override [locked] happens [x] time(s)”
-or-
“Until time is [time]”
———
That way, if I have a party and turn it off Friday night, I know my default will automatically turn back on Saturday at 6am.
Anyway, just thought I’d throw it out there for consideration.
The logic in the app for the disable switch actually sends all logic paths to a sink hole. To override with alternate time it would be easier to have a variable take precedence over the default lock time. I have a ton of requests coming in from all over the place but I'll try to take a look soon.
A new release is on HPM and it's not in finished form but I'm on baby duty so figured I'd let you guys play with it and tell me what I broke. I added separate delays for lock and unlock. I added descriptors for the time variables. The page was taking up a lot of space so I condensed the sections into hideable fields. I'll probably default the lock collapsible field as open but it's currently set to closed. Just let me know what you prefer. I added a separate lock handler to cover cases where the door is in weird states. I haven't tested it much though.
Try it again with 1.1.5. I built a handler for the lock to cover this edge case but haven't tested it.
It should just immediately unlock it if the door is open to prevent smashing the bolt against the frame, but I haven't tested the new handler method so there may be bugs. There are toggles for both lock and unlock retries now though. A toggle to enable/disable the unlock feature is likely, I just haven't had time today.
It's in the works, if you look in the code you'll see some stuff about lockStatus, contactStatus, lockBatteryStatus, and contactBatteryStatus. I'm going to provide different display options based on what the user prefers since not everyone is going to want all that on their page but some will.
Lock, Contact, and Battery status will be showing up on the device selection lists soon, I couldn't get working tonight. There is also a refresh option coming where you can refresh the lock at intervals if it doesn't respond well for whatever reason.
It appears that the unlock function is stilling following the setting for 'Locking Options'. I tested this multiple times. If I set unlock to 2, 5. 10, 30 sec it was doing it after 1 minute, which is what I had my lock setting set for during testing. I then set the unlock to 5 mins and the lock to 10 secs, it unlocked after 13 sec. Let me know if you want me to try anything specific.
It might make it easer to understand the options if they read something like 'Locking Options (Door Closed:)' and 'Unlocking Options (Door Open)'. I think that may save you some time answering questions like 'Why would I want the door to unlock'?
The door was open for the testing I outlined above regarding the unlock. I would open the door, lock it and then time how long before it unlocked. Each time I changed settings I did the same procedure. I only noticed issues with the unlock function.
