Simplified Zwave Lock Manager

You may download or clone the project from

Many thanks to @ptdalen for his Zwave Lock Manager project, without which this project wouldn’t be possible.

I was looking for a bit simpler lock manager, as I only have one Zwave lock. If I add others, setting up a new manager would be simple with a few global replaces. Anyways, let’s take a look at one of the “codes” that I setup (Not every day of the week is displayed)

The top section is somewhat obvious. You can enter a name for the code slot, the PIN for the lock. The Notifications input_boolean will notify you when the code is used on the lock. The Enabled input boolean means the system is allowed to use the PIN with your lock, however it does not mean that your code is “in” your lock. Look at the Status notification. When that reads Connected, that means Home Assistant has sent the PIN to the lock. If it reads Disconnected then the code has been removed from the lock.

In fact, each code has it’s own automation that is triggered whenever it’s status notification changes. That automation adds or removes the PIN from the lock. By using a collection of binary_sensors it’s possible to add many different options to the lock system. Each option in the GUI has an associated binary_sensor, and those are “added” together (technically using the AND operator), so you can create some complex lock access scenarios.

I’ve added a few of them which I’ll try to describe. By default, when you setup a code, you set the name of the person using the code and the PIN. Whenever you change the PIN text, the system automatically turns of the “Enabled” input boolean. Turn the boolean on and you will have an “always active” code. Use these for your family members. The code I’m showing here is what I use for a neighbor who visits our pets when we go away. I just use the Enabled boolean to turn it on when we leave, and off when we get home.

To let someone access the lock a specifc number of times, I would enable the “Limit Access Control” boolean and use the slider to set the number of times the user can execute an “unlock” command.

Enable the Date Range and specify the Start/End dates, and the system will add the code when the system time falls between those ranges.

Below that are the “days” settings. If you want to let someone access the lock only on Monday-Friday, turn off the Saturday and Sunday booleans. Each day also has time settings. If the start an end values are the same, then the user can access the lock for 24 hours on that day. If you specify a range, the PIN can only be accessed during that time period.

Suggestions are welcome, and thanks again to @ptdalen whose code I borrowed and examined to put this together.


Download the code from github. The files need to be placed in the packages directory. I suggest putting all of these files in a directory called lockmanager so your directory structure should look something like: .../homeassistant/packages/lockmanager

N.B.* This package expects your lock to have the entity_id of lock.front_door_lock so you can either rename the entity_id of your lock in Home Assistant or do a global replace in the package files.

* For those of you who have ever wondered what N.B. means, it is an abbreviation for the Latin phrase nota bene, which simply means, “observe carefully or take special notice”.

The following files are included:

  • lock_manager_common.yaml
  • lovelace
  • lock_manager_1.yaml - lock_manager_6.yaml

Instead of creating six sets of entities, it found it was much easier to create lock_manager_1.yaml and copy that file to lock_manager_2.yaml, etc. and modify those files. The script will do that for you. It simply copies lock_manager_1.yaml to lock_manager_2.yaml through lock_manager_6.yaml and then uses sed to replace _1 to _2 through _6. Anytime lock_manager_1.yaml is modified, run the script to ensure the changes are propagated. The file lock_manager_common.yaml as you might suspect, is code that is common to every entity in the package. The contents of lovelace is the yaml code for displaying the six keypad codes. In the lovelace editor UI, use the raw config editor option to display your entire lovelace yaml. Go to the end of the file and paste the contents of lovelace.

Adding more user codes

The easiest way to add another user code “slot” is to modify the script. For example, suppose you wish to add a 7th slot. Open in your favorite editor and add the following:

cp lock_manager_1.yaml lock_manager_7.yaml
sed -i 's/_1/_7/g' lock_manager_7.yaml

Save and then run the script and then restart Home Assistant. Now you will have entities for the 7th slot. To add the UI elements, open the first slot with the UI editor and copy the contents and paste into an editor. Replace _1 with _7. Click the + icon in the UI and add a “manual card”. Paste the contents of your code, save and you’re done.


This looks great! I have been struggling to implement ptdalen’s lock manager for 3 locks; Almost working, and then ran into some issues regardless. Will give this a shot and let you know if I can get it working on 3!

Thank you releasing this and ptdalen for his original work!

I am getting this error when importing the config as-is:

@hassio:/data/home-assistant/packages$ docker exec -it home-assistant python -m homeassistant --script check_config -c /config
Testing configuration at /config
ERROR:homeassistant.util.yaml.loader:YAML file /config/packages/lock-manager/front_door/lock_manager_1.yaml contains duplicate key "front_door_accesscount_1". Check lines 3 and 9.
ERROR:homeassistant.util.yaml.loader:YAML file /config/packages/lock-manager/front_door/lock_manager_2.yaml contains duplicate key "front_door_accesscount_2". Check lines 3 and 9.
ERROR:homeassistant.util.yaml.loader:YAML file /config/packages/lock-manager/front_door/lock_manager_3.yaml contains duplicate key "front_door_accesscount_3". Check lines 3 and 9.
ERROR:homeassistant.util.yaml.loader:YAML file /config/packages/lock-manager/front_door/lock_manager_4.yaml contains duplicate key "front_door_accesscount_4". Check lines 3 and 9.
ERROR:homeassistant.util.yaml.loader:YAML file /config/packages/lock-manager/front_door/lock_manager_5.yaml contains duplicate key "front_door_accesscount_5". Check lines 3 and 9.
ERROR:homeassistant.util.yaml.loader:YAML file /config/packages/lock-manager/front_door/lock_manager_6.yaml contains duplicate key "front_door_accesscount_6". Check lines 3 and 9.

I am not seeing the duplicate jump out at me… any ideas?

Edit: Oh I see, there is indeed duplicate input_numbers in each lock_manager.

That’s a bug. I don’t know how that got in there. I’ll fix it later. I have that on my instance and it doesn’t seem to be a problem though.

Thanks for sharing and making this project. In what ways does it differ compared to ptdalen’s lock manager?

For one thing it looks like it’s a “plug and play” approach in a nicely set up package, whereas from my experience with ptdalen’s code it was a lot more complicated and I had to do a ton of tweaks to get it working.

The first difference is ptdalen’s is trying to accommodate using the same code across multiple locks. So you might create a code for Paul, and have it used across multiple locks.

In my opinion, this is a nice “want”, but it makes things unnecessarily complicated. Much easier to have each lock use it’s own lock manager package.

The other difference is this package allows you to build complex access schedules. My package has six built in user slots (though it’s easy enough to add new ones). Each slot has its own YAML file, which is a copy of the first and modified by a sed operation. Each slot has multiple binary sensors, where each of them defines an access parameter. By default, when you setup a slot with a user name and PIN and you enable it via an input boolean that slot becomes “active”. Whenever a slot becomes active, the PIN is added to the lock. So if you turn off a slot’s “enabled” boolean, the slot becomes “inactive” and the PIN is removed from the lock. This is what you would use for your family. Their PIN is always “active” and available 24/7/365.

Now let’s say you want to create a user whose PIN is only available between certain dates. You would set the start and end dates in the UI you want the the user to be able to access the lock with their PIN. Then you would turn on the “Use Date Range” boolean. There is an associated binary sensor that returns “true” if this boolean is off or it determines if the system time falls in the date range you set. So the lock is now active only if the “enabled” boolean is true and the date range binary sensor is true.

So for each lock condition you create, HA determines if the PIN is active by “adding” each binary sensor together. If any of them fail, the PIN becomes inactive and is removed from the lock. While I think I’ve covered the most useful conditions, you could a silly one like checking to see if the day is the 3rd Thursday of the month in November.

1 Like

Looks really nice. I have one site with 6 locks, two others with 4 locks. All Schlage.

What would it take to make that work?

Thank you very much for your work on this !

I would create a directory for each lock in the packages folder. Setup the first lock, then the second. You will have to do some global replaces to match your locks entity names etc.

It might make sense to exclude your locks, delete all their entities and then add them one at a time. If you aren’t using the vision sensors, delete everything related to that before starting. The tricky part is making sure you haven’t missed anything during the renaming. I just added _frontdoor to everything in the entity registry.

I decided to clean up the UI a bit by using Fold Entity Row so that the Access Options are collapsed by default.

Man, this is the greatest thing I’ve discovered for HASS recently! Got this up and running in like 15 minutes. I even played with the “limit access count” piece, which is nifty.

Thank you for doing this! I couldn’t get the original lock manager working :frowning:

@ptdalen I just had an idea that would allow you to share the PIN and access restrictions across multiple locks.

If you create a group of zwave locks, and used that group to add an input boolean for each member of the group, that boolean would determine if the user code “belonged” to the lock — along with the all of the access restrictions. So you wouldn’t need to create a separate manager for each lock. You would just modify the automations for ADD/UPDATE/CLEAR to apply those changes for any of the locks that are enabled.

I would add this myself, but I only have one lock so I couldn’t easily test it.

1 Like

I tried to make the install simple. Glad it was fast. Did you find this from my Reddit post?

I think so. I have one lock for now but will have two locks soon, so I’d love multi lock support too :slight_smile: