Simplified Zwave Lock Manager is now KeyMaster


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 added the PIN to the lock. If it reads Disconnected then the code has been removed from the lock. Simply put, Connected means the specified PIN is in the lock’s code slot at this moment and Disconnected means the PIN is not in the lock at this moment.

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 and 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 package together.

See the README for installation instructions.


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:

1 Like

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


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:

Nice work! I’m still new to Home Assistant.

How do I configure notifications? I’d like to have a notification that fires whenever a PIN code is entered that tells me which code was entered. I’m assuming you do this with automations, but I’m not sure.

I’m getting closer. I have the automation triggering when the keypad is unlocked. However, I’m not sure how to configure the data template to pass the name of the code that unlocked. Any ideas?

Here’s what I have right now that correctly sends a notification with the title of “Test” and the body of “Test Message”:

- id: 'front_door_unlock'
  alias: Unlock Front Door Notify
    - platform: state
      entity_id: lock.front_door_lock
      to: 'unlocked'
      from: 'locked'
    - condition: template
      value_template: '{{ states.lock.front_door_lock.attributes.notification == "Keypad Unlock"}}'
    - service: notify.notifier
        title: >
        message: >
           Test Message

I have been using ptdalen’s lock manager but never got the setting and deleting of codes working properly. I have just installed this simplified one and made changes to the entities in the config files. I installed the plug-ins via HACS and added the necessary lines to the resource area of lovelace (RAW config).

The code tab seems to load everything except the fold-entity-row cards and gives me an error:
Custom element doesn’t exist: fold-entity-row

I just installed the plug-ins but checked the versions anyhow and they match.
I cleared my browser’s cache (desktop and mobile) but still get the doesn’t exist message.

What else can I do to get this working properly? Anything obvious that I might have overlooked?

This lock manager looks very promising and I’d really like to get it working.

Edit: I’ve disabled the Day of Week restrictions for now as it’s not really something I’ll need on a day to day basis. Thanks for creating this!

If you follow the instructions of the first post, you shouldn’t have to create any automations for your notifications. They are already included. The important part is to create the UI by using the lovelace file that’s attached.

When you have the UI running, you should have 6 “codes” by default. Once you add a PIN and use the enabled slider that PIN will get added to your lock. If the status reads Connected that PIN should control the lock. If the Notifications slider is on, you will get a message whenever that PIN is used.

I just noticed that I forgot to include a script in my package!!! In lock_manager_common.yaml (and maybe other places) script.conditional_notify is called in several places. Below is an example where it’s used. Why did I create conditional_notify? Because I wanted to attach an input_boolean to determine if the notification should be sent. This way I didn’t have to use a condition template which is a pain in the neck. So if you look at the “action” below, it always calls conditional_notify and passes in the “condition” boolean. The script itself will only send a notification if the boolean is true.

    - alias: Front Door Sensor Close
        entity_id: binary_sensor.vision_security_zd2105us_5_recessed_door_window_sensor_access_control_frontdoor
        platform: state
        to: 'off'
        - service: script.conditional_notify
            boolean: input_boolean.dooraccess_notifications
            title: "Front Door"    
            message: "Closed"

And here is the missing script. Notice that it uses a condition to check if the passed in boolean is true? I use notify.notify which is configured to send me iOS notifications. You should modify this to send the notifications that you prefer. Since this is the only place that sends a notification, you only need to make one change. Encapsulation principle, kinda sorta. Technically you should pass in the service, but I wanted to make this easy for the non-programmer.

    - condition: template
      value_template: "{{(states(boolean) == 'on')}}"
    - service: notify.notify
        title: "{{title}}"
        message: "{{message}}"

I’m using the HACS integration from the Community Store. You might want to try installing the plugins I am using which are:

  • Lovelace Auto Entities
  • Lovelace Card Mod
  • Lovelace Card Tools
  • Lovelace Fold Entity Row
  • Monster Card

And at the top of my lovelace code I have the following resources:

  - type: js
    url: /community_plugin/monster-card/monster-card.js
  - type: module
    url: /community_plugin/weather-card/weather-card.js
  - type: module
    url: /community_plugin/simple-thermostat/simple-thermostat.js
  - type: module
    url: /community_plugin/lovelace-card-mod/card-mod.js
  - type: module
    url: /community_plugin/lovelace-fold-entity-row/fold-entity-row.js
  - type: module
    url: /community_plugin/lovelace-auto-entities/auto-entities.js
  - type: js
    url: /community_plugin/lovelace-card-tools/card-tools.js

Try duplicating that and see if it works. Let me know if you narrow it down. Also, you should look at this this post because there is a missing script in the package. You should just copy it to your script file, modify it so it works with the type of notifications you like.

Thanks for the reply. For whatever reason I can’t get fold-entity-row to work; it doesn’t really matter as I am very pleased with the rest of the package and won’t be dealing much with time restricted access in any case. I modified the notifying service and added a couple of sensors from ptdalen’s package (battery status and last person to unlock w/keypad) to round it off.