[RELEASE] Auto Lock

What's next?

  • Any recommendations?

Release notes:


Version 1.1.46 3/12/2021

  • 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.


Install available on Hubitat Package Manager or through my GitHub links below.

GitHub Link - Parent

GitHub Link - Child

What devices I use:
Yale Assure Lock SL with Z-Wave - Smart Key Free Touchscreen Deadbolt -Works with Ring Alarm, Samsung SmartThings, Wink and More (Hub required, sold separately) - Satin Nickel

TENAVOLTS 1.5V AA Lithium Rechargeable Battery, 1.8h Fast Charge, USB Charger, Constant Output at 1.5V, 2775 mWh

EyezOn Envisalink EVL-4EZR IP Security Interface Module for DSC and Honeywell (Ademco) Security Systems, Compatible with Alexa

Honeywell Ademco VISTA-21IP Control Panel w/Onboard IP Communicator

Ecolink Intelligent Technology Z-Wave Easy Install, Battery Operated, Door/Window Sensor, White & Brown (DWZWAVE2-ECO)

TalentCell Mini UPS Uninterrupted Power Supply 27000mAh 98Wh Lithium ion Backup Battery with DC 12V/9V/5V Output for Wireless Router, Modem, LED Light, CCTV Camera, Smartphone and More


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?


Pull request already submitted. Fixed a namespace error in the parent app I forgot to change.


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?

1 Like

I'll need a bit to see what all is envolved but I can give it a shot.

1 Like

Excellent release, @lewis.heidrick, very cool.

A couple of things I noticed under the category of "Man, are you picky @danabw ...

The header has a "null (Unknown)" title in it when you're creating a new child:

Example from Auto_Off from CSteele that does this differently (yes, I'm suggeting you mightl brashly steal code): :wink:

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.

1 Like

I had the same thought.

Maybe add "Minutes" or "Seconds" to the field literals when the setting changes, or ?

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.

1 Like

Is this

in response to this

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.

What am I missing?

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.

Awesome work @lewis.heidrick, you sold me!

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...

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.”
“When [virtual switch] is [on], disable default lock time”

followed by something like:
“Until [virtual switch] is [off]”
“Until override [locked] happens [x] time(s)”
“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.

Thanks again for sharing, this is great.

1 Like

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.

1 Like

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.


Locking works as expected. Unlocking does not.

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'?

Might have mixed up the variable on one of the handlers. What action were you resting against? A lock trigger or contact trigger? Was the door open?

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.

1 Like

Thanks, I'll dig into it once the babies go to sleep.

1 Like