KeyMaster Z-Wave lock manager and scheduler

Share your Projects!
2226

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

EDIT: Looks like maybe I just need to upgrade…

2227

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
2228

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!

2229

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.

2230

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?

2231

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 :frowning:

Update: Looks like this is expected behavior per this

2232

Yes, the front end Doesn’t have the ability to look inside included files

2233

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

2234

It can in YAML mode, not storage mode.
(Just to make it clear for others)

2235

Please open a github issue for any bugs.

2236

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.

2237

Try clicking on “Advanced Options” and then “Reset code slot”. That seems to have worked for me.

2238

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.

2239

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: single
2240

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

2241

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.

2242

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.

2243

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

2244

I have two different types of automatic locks.

  1. Deadbolt style in which case this is 100% what I want
  2. 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 :wink: 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.

2245

Just set it to the “fake” sensor. It will behave as if the door is always closed.