KeyMaster Z-Wave lock manager and scheduler

schwieb · December 6, 2021, 2:29pm

I successfully installed keymaster without errors but nfortunately I am unable to write pin codes to either of my Kwikset 910 locks beyond the initial write. To fix the issue, I am planning on FULLY uninstalling keymaster, factory RESETTING both locks, rePAIRing the locks, and reinstalling keymaster.

I want to make sure I cleared everything before starting the reinstall and would appreciate any tips. So far I have:

Removed both locks from the integrations
Uninstalled Keymaster in HACS
Manually removed entities in automations.

Is there anything else I need to do? Thanks for any help you might be able to provide!

jclarke0000 · December 6, 2021, 7:38pm

My installation of Keymaster is mostly working. But the UI seems to get stuck on “Adding” when I try to enable a PIN. Z-Wave JS logs show the PIN being written successfully, but the Keymaster UI just shows “Adding” beside PIN status. It never gets to the connected state.

zwave_js logs show the code being updated, user PINs redacted by me (And I can verify the new code works, and the old one no longer does)

2021-12-06T19:23:29.127Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:     57
                                    transmit status: OK
2021-12-06T19:23:29.130Z CNTRLR   [Node 004] [~] [User Code] userCode[2]: "XXXXXX" => "XXXXXX"        [Endpoint 0]
2021-12-06T19:23:29.131Z CNTRLR   [Node 004] Scheduled poll canceled because value was updated
2021-12-06T19:23:30.055Z SERIAL « 0x010b00a800010402984000bb38                                        (13 bytes)
2021-12-06T19:23:30.056Z SERIAL » [ACK]                                                                   (0x06)
2021-12-06T19:23:30.059Z DRIVER « [Node 004] [REQ] [BridgeApplicationCommand]
                                  └─[SecurityCCNonceGet]
2021-12-06T19:23:30.067Z SERIAL » 0x011600a901040a9880c59edf72dc33c25005000000003ae3                  (24 bytes)
2021-12-06T19:23:30.068Z DRIVER » [Node 004] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x05
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      58
                                  └─[SecurityCCNonceReport]
                                      nonce: 0xc59edf72dc33c250
2021-12-06T19:23:30.075Z SERIAL « [ACK]                                                                   (0x06)
2021-12-06T19:23:30.077Z SERIAL « 0x010401a90152                                                       (6 bytes)
2021-12-06T19:23:30.078Z SERIAL » [ACK]                                                                   (0x06)
2021-12-06T19:23:30.079Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2021-12-06T19:23:30.096Z SERIAL « 0x011d00a93a00000100bb7f7f7f7f01010300000000020100007f7f7f7f7fb4    (31 bytes)
2021-12-06T19:23:30.097Z SERIAL » [ACK]                                                                   (0x06)
2021-12-06T19:23:30.098Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:     58
                                    transmit status: OK
2021-12-06T19:23:30.114Z SERIAL « 0x012700a80001041e9881782de0650c9cf22731f8ab1978518dacd5e571c55f649 (41 bytes)
                                  1a086ea2f3a00bbd8
2021-12-06T19:23:30.115Z SERIAL » [ACK]                                                                   (0x06)
2021-12-06T19:23:30.117Z CNTRLR   [Node 004] [~] [Notification] notificationMode: "push" [Endpoint 0] [internal]
                                   => "push"
2021-12-06T19:23:30.118Z DRIVER « [Node 004] [REQ] [BridgeApplicationCommand]
                                  └─[SecurityCCCommandEncapsulation]
                                    │ sequenced: false
                                    └─[NotificationCCReport]
                                        notification type:   Access Control
                                        notification status: 255
                                        notification event:  New user code added
2021-12-06T19:23:59.166Z SERIAL « 0x010b00a800010402984000be3d                                        (13 bytes)
2021-12-06T19:23:59.167Z SERIAL » [ACK]                                                                   (0x06)

But in Keymaster, this is what I see:

It will just sit on “Adding” forever.

Some things to note, not sure if they make a difference:

I’m using two different code lengths: slot 1 uses a 6-digit code, while slot 2 uses a 4-digit code. My lock supports this as per the user manual (Yale Pro SL)
I’ve set advanced options for slot 2 so that the code is only active on Mondays between 8AM and 6PM.

I’m running version 0.0.77 of Keymaster, HA core version 2021.11.5, Supervisor 2021.10.8, Home Assistant OS 6.6. Running on an Odroid N2+ with a Zooz 700 ZWave USB stick.

Locks operate normally and reliably over Z Wave when locking/unlocking.

EDIT: I’ve also noticed that my automation to enable/disable the code doesn’t work either. The code should have been disabled at 6:00 pm, but it is still active. The UI correctly shows “Disconnected,” but the code still works when I try it on the lock keypad.

schwieb · December 7, 2021, 1:14pm

I have completely re-set my two Kwikset 910 locks, uninstalled keymaster, repaired and reinstalled. Unfortunately after doing all of that it appears I am having the same experience as @jclarke0000 above.

I am able to write the codes with keymaster but the status remains on adding.
I am unable to disable any codes with keymaster.
I am able to write and clear codes manually using the developer tools services option with zwave_js.set_lock_usercode and zwave_js.clear_lock_usercode
I am able to unlock and lock the doors with Home Assistant

I am running the 2021.11.5 version of HA and v0.0.77 of keymaster.

jclarke0000 · December 7, 2021, 2:00pm

Like @schwieb I can confirm that I can also manually set and clear codes if I call the set_user_code and clear_user_code services via developer tools. This works reliably. I’m only having problems trying to manage the user codes via the UI.

jclarke0000 · December 8, 2021, 2:57am

An update for Z-wave JS became available today. I installed the update and it seems to have fixed my issues. I can now manage codes through keymaster’s UI properly for both of my locks. I’ll keep an eye on this, as the real test will be next Monday when the scheduled code, currently disabled, should become active.

EDIT I have noticed that the keymaster_lock_state_changed event no longer fires if I lock or unlock the lock over Z-Wave using HA’s regular UI (e.g., entity card). The event fires only when a PIN code is used, or when the deadbolt is manually turned by hand. Before the Z-Wave update, the event would fire and the action_text field of the event object read something like “RF unlock operation.”

FutureTense · December 8, 2021, 5:02am

Look at frontdoor_keymaster_common.yaml and find the notification automation.


  - alias: keymaster_frontdoor User Notifications
    id: keymaster_frontdoor User Notifications
    trigger:
      platform: event
      event_type: keymaster_lock_state_changed
      event_data:
        lockname: frontdoor
    condition:
      - condition: template
        value_template: "{{ trigger.event.data.code_slot > 0 }}"
      - condition: template
        value_template: "{{ is_state('input_boolean.notify_frontdoor_' + trigger.event.data.code_slot | string, 'on') }}"
      - condition: state
        entity_id: input_boolean.frontdoor_lock_notifications
        state: "off"
    action:
      - service: script.keymaster_frontdoor_manual_notify
        data_template:
          title: frontdoor
          message: "{{ trigger.event.data.action_text }} ({{ trigger.event.data.code_slot_name }})"

You can copy this to your own automations and replace script.keymaster_frontdoor_manual_notify to disarm your system. You should remove or replace the last two conditions because they might prevent this from firing. I would create a condition that checks to see if trigger.event.data.code_slot is in [1, 2, 4] so that it only disarms when those slots are used. e.g. if slot 3 is the maid and you want to make sure they have to disarm your panel “normally”.

FutureTense · December 8, 2021, 5:10am

Yeah, I suppose I should remove that. But I left it in because I still use that personally, lol.

FutureTense · December 8, 2021, 5:16am

Why do you want to use webhooks in the first place?

FutureTense · December 8, 2021, 5:29am

It depends on how you want to organize things. If I were to add this feature to KeyMaster, I’d add a disarm toggle for each user in the gui. In the example a few posts above, that’s a single automation for all slots. But there’s no reason you couldn’t create an automation for each slot. But it’s a sloppy approach. I prefer code to be centralized.

You might have noticed there is yaml for each slot, likemfrontdoor_keymaster_1.yaml but there is also frontdoor_keymaster_common.yaml which is used by all slots. I try and keep the slots as small as possible.

FutureTense · December 8, 2021, 5:30am

That’s my fail safe procedure. Works every time. Sometimes I reboot the system too.

schwieb · December 8, 2021, 1:52pm

My locks are now working with the latest zwave-js 1.50! Thanks for pointing that out @jclarke0000

I also appreciate the work of the developers. I know this is a time consuming endeavor to create an maintain.

schwieb · December 9, 2021, 3:38pm

Ok, I must be doing something stupid regarding the notifications because they dont work.

I added this to scripts.yaml

frontdoor_manual_notify:
  mode: parallel
  sequence:
  - service: notify.notify
    data:
      title: '{{ title }}'
      message: '{{ message }}'

I turned on the notifications:

I toggled the notification for each code:

I also tested the script with developer tools and I get a notification as expected.

What am I missing?

jwsample · December 9, 2021, 3:52pm

If you look at the lock device in the zwavejs integration do you have any disabled entities?

schwieb · December 9, 2021, 7:33pm

I had alarmtype and alarmlevel disabled, but I thought I could use the fake sensors instead. I will enable them, redeploy the locks, and try again to see if that might be the problem.

jwsample · December 9, 2021, 7:47pm

If alarm level reports the code slot you might find it more convenient to just use state change automations on those variables versus trapping the events.

schwieb · December 9, 2021, 8:59pm

Not sure I follow on how to do that!

jwsample · December 9, 2021, 9:52pm

Here’s an example (untested)
Here’s a keymaster lock that has many codes but you want to send a notification when either of the first two codes are used. The ‘to’ portion in the state triggers don’t need a ‘from’ portion so they will fire every time.

alias: Automation that does something
description: ''
trigger:
  - platform: state
    entity_id: sensor.<door_name>_alarmlevel_2
    to: '1'
  - platform: state
    entity_id: sensor.<door_name>_alarmlevel_2
    to: '2'
condition: []
action:
  - service: notify.notify
    data:
      message: 'some message'
mode: single

schwieb · December 10, 2021, 12:43pm

I figured out what I was doing wrong with the notifications! The installation wiki indicates creating this script:

<doorname>_manual_notify:
  mode: parallel
  sequence:
    - service: notify.phones
      data:
        title: "{{ title }}"
        message: "{{ message }}"

but you actually need to prepend ‘keymaster_’ to the script name like this:

keymaster_<doorname>_manual_notify:
  mode: parallel
  sequence:
    - service: notify.phones
      data:
        title: "{{ title }}"
        message: "{{ message }}"

To re-state the obvious, you also need to change the ‘doorname’ and ‘service’ section to your own specifications.

rct · December 11, 2021, 3:48pm

Migrating to ZwaveJS2MQTT, trying to setup KeyMaster per the documentation. I have Schlage BE469ZP deadbolts. While I have 16 entities for the lock, I don’t see a user code sensor or access control sensor. The entities I have are:

binary_sensor.mudroom_deadbolt_access_control_keypad_temporary_disabled
binary_sensor.mudroom_deadbolt_access_control_lock_jammed
binary_sensor.mudroom_deadbolt_home_security_intrusion
binary_sensor.mudroom_deadbolt_low_battery_level
binary_sensor.mudroom_deadbolt_power_management_replace_battery_now
binary_sensor.mudroom_deadbolt_power_management_replace_battery_soon
binary_sensor.mudroom_deadbolt_system_system_hardware_failure
binary_sensor.mudroom_deadbolt_the_current_status_of_the_door
lock.mudroom_deadbolt
sensor.mudroom_deadbolt_access_control_keypad_state
sensor.mudroom_deadbolt_access_control_lock_state
sensor.mudroom_deadbolt_battery_level
sensor.mudroom_deadbolt_home_security_sensor_status
sensor.mudroom_deadbolt_node_status
sensor.mudroom_deadbolt_power_management_battery_maintenance_status
sensor.mudroom_deadbolt_system_hardware_status

What am I doing wrong?

wittjosiah · December 11, 2021, 8:11pm

Thanks for making this great integration, it seems like exactly what I’m looking for to manage the pins on my locks.

I’ve been trying to set it up and while I’ve run into a few hurdles along the way I’ve managed to sort most of them out so far, however I’ve gotten a bit blocked and I’m not sure what’s wrong now. What’s happening is that all the pin statuses are always “Adding” or “Deleting” rather than “Added” or “Deleted”. I checked the locks and confirmed that there doesn’t seem to have been any changes to the codes as far as I can tell, it seems like they aren’t communicating. I saw this section in the wiki Troubleshooting · FutureTense/keymaster Wiki · GitHub but it hasn’t seemed to resolve itself.

As suggested, I’ve enabled debug logging (though I had to enable it system-wide as the service didn’t like when I pasted in the suggested yaml data). These are the logs that I saw which looked relevant to keymaster, but they don’t really seem to indicate much to me: 2021-12-11 14:35:59 DEBUG (MainThread) [custom_components.keymaster] DEBUG: Code - Pastebin.com.

Some other potential relevant details of my setup:

Locks are Yale Assure Lock SL Touchscreen Deadbolts
Running on a Raspberry Pi 3 with HomeAssistant OS (version 6.6)
Core is version core-2021.11.5 and Supervisor is version supervisor-2021.12.1
Using an Aeotec Z-Stick Gen5
Setup with ZwaveJS addon/integration (version 0.1.50)

Does anyone have any suggestions on what I should try to get it working? Thanks!