I was also having the same issue so I rolled back to the previous version of KeyMaster and fix it
Found my solution to the errors. The newest version of Keymaster (v0.0.63) requires 2021.9 or greater. I thought my system was up to date but my core was at 2021.8.x. When I updated to 2021.9.2, the errors went away. My fault for not making sure my system was up-to-date.
I am still having an issue with KeyMaster stuck at adding/deleting. After I added my 3 locks to lovelace view, I noticed my front door (parent) all 10 slots showed Adding for PIN status. My other 2 locks garage door (child) and back door (child), showed Disconnected for their PIN status. Before I uninstalled KeyMaster, I had 3 users in the 1st 3 slots on all locks. I added the 3 users in the same order to the parent lock and it seemed to work correctly. The user information was on all 3 locks and the PIN status shows Connected on all locks. I added a test user to the 4th slot and it is stuck at Adding on the parent lock but the children locks show Connected. Then I tried to add 2 more test users. One in the 5th slot and one in the 7th slot. Both have a PIN status of Adding on all locks.
This is my HA debug log.
https://pastebin.com/raw/eqXbwt3H
I used the parent lock to disable/enable a code slot.
This is my Zwave2MQTT debug log.
https://pastebin.com/raw/xNbRczQv
Node 18 is Garage Door (child)
Node 21 is Back Door (child)
Node 23 is Front Door (parent)
Schlage BE469
Hi. I am returning to try keymaster again after working out some zwave issues with my locks. I have 5 Yale Assure locks. Every time I use keymaster to to configure a lock (even with just 5 lock codes), I get about 100 new entities showing up in my master dashboard, and most of them have generic names like ânotificationsâ or days of the week, or start times etc⌠With 5 locks, it materially slows down dashboard loading etcâŚ
Am I doing something wrong? These entities donât look very useful, and I am just wanting to use it to manager the lock key codes instead of using the zwavejsmqtt elements. It really seems to clutter things up, so I am wondering if there is a different card that should be created for the master dashboard?
You probably want it on itâs own dashboard, so that it only loads when you explicitly want it to, and with 5 locks you might even want to put each lock on their own dashboard.
1 Like
This thead seems to have derailed from the initial question - where did we end up with that?
Is it supposed to already be smart enough to take door open/closed status into account with autolocking?
My preference would be that it not attempt to lock if the door is open⌠and optionally do so when the door does close. @mikeg1130âs suggested automation sounds correct to me. When the time expires, if the door is closed lock, otherwise remain in a âshould lockâ state and lock when the doorâs state becomes closed.
Just triggering the auto-lock regardless of door open/closed state seems pretty pointless - especially given that there is a config option in place already to define the door sensor. 
EDIT: Looks like maybe I just need to upgradeâŚ
I assume what you mean by master dashboard is the auto-generated Overview? If youâre using Keymaster then I strongly recommend that if you want to keep an auto-generated Overview dashboard that you do the following:
- Create a new Lovelace dashboard (and likely restrict it to just Admins)
- Let that dashboard stay as an auto-generated one
- Take control of the default Overview dashboard and get rid of everything that isnât actually useful on the view
- Create another dashboard exclusively for Keymaster locks. When you add a lock one of the things that Keymaster does is generate a Lovelace yaml file for you to stick into a custom dashboard that creates a view specific to that lock. Youâll find the file in config/packages/keymaster/<lockname>/<lockname>_lovelace For more information on this see this wiki article about it
Finally, about all of those generate entities. Yes, theyâre all useful, but primarily only if youâre using the advanced features of Keymaster. Theyâre all consumed and used by the generated Lovelace view and become a lot more understandable if youâre using that view!
1 Like
Andrew, this is very helpful. I actually donât use dashboards that much - control is done by voice using lots of Google hubs, the android quick controls exposed in assistant on android, as well as Lutron switches in the house that trigger things. But the bulk of what I use HA for is driven by automations - I donât use HA like a remote control.
That said, if something is broken, or I am working on an automation, then I use the dashboards to figure out whatâs broken, so slogging through tons of devices makes that harder, and usually itâs when I have added something, so itâs present in the Overview and not yet moved to another dashboard (like I have for AV, HVAC, Pool, etcâŚ)
Is there a way to keep the Overview view that stuff is auto-added to when a new integration is installed, but keep keymaster entities out of it?
PS Can I just include those lock yaml entities instead of doing lots of cut and pastes? It would seem this would be a better way to keep things in sync if I am changing things around.
Thx!
Technically, you donât need the Lovelace yaml defined anywhere. The entities are defined in the generated lock packages. But programming them would be a pain without them.
I see that my code slots (4 - 10) are unavailable on my front door (parent) lock. I have the code slots set as available in zwave2mqtt. Any ideas how to fix this?
I have yet to get the yamlâs !include option to work for these dashboards. At least not with making changes in the HA raw editor, it always complains about not being able to parse the !include 
Update: Looks like this is expected behavior per this
Yes, the front end Doesnât have the ability to look inside included files
@FutureTense, thanks for sharing this with the community. I just installed this under 2021.9.3. I have noticed that if I toggle the enabled boolean for a code it does not trigger the synchronize_codeslot_frontdoor_X automation. If I toggle the current day of the week it does. Is this a bug or intended functionality?
It can in YAML mode, not storage mode.
(Just to make it clear for others)
Please open a github issue for any bugs.
I installed KeyMaster 0.0.63 via HACS
I installed via HACS, Number Box, card-tools, auto-entities, and fold-entity-row
I pasted the lovelace file into a view.
Tried to add 3 pins.
EAch one says:
Pin Status: Adding
Seems stuck.
Try clicking on âAdvanced Optionsâ and then âReset code slotâ. That seems to have worked for me.
You asked for, so Iâm giving it to you, but maybe not exactly how you want it. I
Sorry.
I too have several dings in my doorframe where the deadbolt locked while I was slamming the door shut. See the Door open check beta release for more info.
But in a nutshell: All integration commands that lock/unlock the device are now being sent to a âshadow lockâ. This lock (named boltchecked_LOCKNAME) will first determine the status of the door. When it receives a lock command, if the door sensor is closed, the command is executed. If the door sensor is open, input_boolean.keymaster_LOCKNAME_retry is set to True. When the door sensor reads closed (presumably because the door was closed!) and if input_boolean.keymaster_LOCKNAME_retry is True the lock command will be called again.
In fact, every time the lock command is attempted, if the door is open than the next time time the door is closed it should lock. However any other commands to the lock should override this âlock retryâ attempt.
Maybe Iâm having a hard time understanding, but why canât you do what I did with my automation? Stupid simple⌠It will not try to lock until the door is closed⌠That is when the timer starts⌠I posted this some time agoâŚ
alias: Front Door Auto Lock
description: ''
trigger:
- type: not_opened
platform: device
device_id: blahblahblah
entity_id: binary_sensor.front_door_ias_zone
domain: binary_sensor
for:
hours: 0
minutes: 5
seconds: 0
milliseconds: 0
condition:
- condition: device
device_id: blahblahblah
domain: lock
entity_id: lock.assure_touchscreen_deadbolt
type: is_unlocked
action:
- device_id: blahblahblah
domain: lock
entity_id: lock.assure_touchscreen_deadbolt
type: lock
mode: singleBecause itâs not that simple. Lock commands get issued all over the place. The new approach will retry a lock command the moment the door is shut if the command hasnât been overridden elsewhere. Iâm surprised I didnât think of this when I wrote the original autolock.
I was thinking about this a bit more, mostly because I was confused about why you used device_id in your YAML. Let me guess, you started your automation with the GUI?
Your Auto-Lock automation might work well for you, but I guarantee it wonât for 99% of the population using Z-Wave locks, while KeyMasterâs implementation will. Why? Because your implementation requires an opened/closed sensor. Many locks donât come with those. One of our goals is to support the widest population possible. When it comes to any change/idea, me and the other devs are constantly thinking of is âwill this F things up?â We are willing to make âbigâ changes â if the juice is worth the squeeze. The shadow lock is a prime example. It wasnât an inconsiderable amount of effort, but Iâm confident itâs going to be âfuture proofâ for any new code we might add.