@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.
Don’t get me wrong, I’m semi new to HA and have very VERY basic programming skills… This is why I asked. The whole automation was generated using the GUI so I’m not sure how/why it uses the device id. My lock is a Z-wave lock but my door sensor is ZigBee.
Sorry, but it sounded like you were miffed I didn’t use it. Most of the code we get asked to implement haven’t cut the mustard for various reasons. I ignored yours because it requires a door sensor to be installed. There were other issues, but that was a non-starter
I have two different types of automatic locks.
- Deadbolt style in which case this is 100% what I want
- Handle lock style in which case it doesn’t matter if the door is open or closed when it gets locked it won’t ding the doorframe.
In the case of the second, is there a way to not have it pay attention to the door sensor (yes I do have one). Just curious, it’s not an issue to me if there isn’t a way, but it’s a use case I personally have where I want the door to lock no matter what after a given amount of time, but sometimes not 
basically, I need to software control the auto-lock because there are regular blocks of time where I don’t want it to auto-lock, but outside of the those blocks I do.
Just set it to the “fake” sensor. It will behave as if the door is always closed.
I just received my Home Assistant Blue in the mail. I decided to setup a new instance of Home Assistant rather than migrate. I’ve got everything setup just the way I had it on my old HA Docker container that was running on a Synology NAS… except for keymaster. I’m getting “entity not available” errors and “custom element doesn’t exist” Lovelace errors.
Also, the following error popped up in the logs:
Logger: homeassistant.helpers.service
Source: helpers/service.py:128
First occurred: 12:17:56 PM (2 occurrences)
Last logged: 12:31:25 PM
Unable to find referenced entities timer.keymaster_game_room_door_autolock
keymaster was running fine on my old HA instance, and I believe I followed the same installation procedure with the new HA instance. I’m using the same Aeotec Gen 5+ Z-Wave Stick and the same locks. The Z-Wave locks are responding normally from Home Assistant. I really have no idea what I’m doing wrong. The only real difference that I can think of is that I was running HA core before and I’m running HA OS with Supervisor now. Any help is greatly appreciated.
Make sure you have the latest keymaster downloaded. There was a version out there that might have a bug
Make sure you completed the pre-install step:
I moved the following to the very top of my configuration.yaml file and that fixed the entity errors:
homeassistant:
packages: !include_dir_named packages
However, the “custom element doesn’t exist” Lovelace errors persist.
Also addressed in the wiki:
I feel like such a dope. I didn’t read down far enough after I got the entity errors. Thank you so much. I’m all good now.
1 Like
You’re not the first nor the last person to miss bits of a wiki.
Enjoy!
1 Like