Lock automation design question

[jwilner]

Hi -- This is not so much a feature request for keymaster (great product!) but an automation design question for a new house. Happy to contribute code if that were the cleanest solution though. Also please let me know if I should direct these questions elsewhere.

Anyway, to enter the house there's an outer gate followed by an inner door. Both will have keyless Yale Assure Lock 2s with zwave modules installed; I'm using zwave_js since that seems to be the blessed path nowadays.

I would like to achieve the following UX:

a) When certain users enter a code for the outer gate, the inner door also opens b) if the automation doesn't work for whatever reason, the same code should work for the inner door. c) When other users (e.g. delivery people) enter a code for the outer gate, the inner door remains locked (so that packages can be left in the interstitial area). d) Generally, it should be possible to issue temporary keys of both sorts.

Keymaster goes a long way in terms of the key management for b, c, and d.

To fulfill (a) it looks to me like I can't use keymaster's user code detection because of https://github.com/FutureTense/keymaster/wiki/Troubleshooting#missing-sensors, but I can rely on the parameters.userId field of the zwave_js_notification event (where userId corresponds to slot or some other notion of insertion order). I can vaguely see how I can write automations like if device_id == GATE_ID and event_label == "keypad unlock operation" and parameters.userId == 2: unlock(DOOR_ID) .

I can live with this if need be, but it feels a bit brittle -- to add a single user for whom the inner door automatically unlocks, I'd need to touch three separate pieces of configuration (1. add a gate lock code, 2. add a door lock code, and 3. define a new automation). Ideally this would just be an extra checkbox in the UI or something to propagate the code a slot for the inner door and create the automation. Keymaster's parent-child notion is close to getting me the propagation, but isn't granular enough to address both A + C.

My questions are:

• does the overall approach (e.g. even using keymaster) seem sane?
• how would you suggest I make the management less brittle?

Perhaps I could simplify things by just handling codes for use case C out of band -- i.e. via the Yale Access app -- and then using Keymaster's parent-child notion w/in HA and write some sort of automation that would detect if the user id is one managed by Keymaster and then open both doors. Of course, having the key management divided across platforms is not as nice.

Thanks again for a great tool.

[firstof9]

You don't need those sensors, keymaster also emits events (keymaster_lock_state_changed) ingested from zwavejs and outputs them for you as well.

[jwilner]

@firstof9, thanks, I’ll check out those keymaster events you suggest.

Do you think using those events would simplify the configuration so that I wouldn’t have to keep three different locations in the conf in sync?

[jwilner]

@firstof9 based on the code, it looks you enrich the event w/ the name values from the configuration. That suggests that I could use a naming convention for slots across both locks (e.g. jwilner-both for slot M in gate_lock and jwilner-both for slot N in door_lock and write a generalized automation that does something like if gate_lock and "both" in ATTR_CODE_SLOT_NAME: unlock(door_lock), which is a definite improvement because it would reduce from 3 to 2 the number of touch points to add one of these special users in the config. Does that make sense to you?

If so, a possible improvement over a naming pattern would be to permit some sort of structured metadata for matching in the triggers. E.g. if ATTR_CODE_SLOT_TAGS.get("unlock_both", False). Would such a structured metadata field for code slots be a valuable addition IYO?

[firstof9]

It would be easier to ask for automation assistance on the forum thread. There's tons of skilled automation crafters on the forum :slightly_smiling_face:

[jwilner]

Thanks @firstof9 I'll bring up in the thread if there are any opportunities for improvement, but I've got a baseline working here. I name code slots with BOTH-DOORs in the name and then:

trigger:
  - platform: event
    event_type: keymaster_lock_state_changed
    event_data:
      lockname: gate
      action_text: Keypad unlock operation
condition:
  - condition: template
    value_template: "{{ \"BOTH-DOORS\" in trigger.event.data.code_slot_name }}"
action:
  - service: lock.unlock
    data: {}
    target:
      device_id: d6dc8d424851db218bfe4fe64f910165

[firstof9]

I wouldn't use the device_id as they're not stable (they can change if something happens). Use the entity_id instead.

[jwilner]

@firstof9 ya thanks, good tip.

For posterity: https://community.home-assistant.io/t/keymaster-z-wave-lock-manager-and-scheduler/166419/2875?u=jwilner