KeyMaster Z-Wave lock manager and scheduler

I changed back to this sensor and updated to version 0.29. Still no observable communication with ozw

Check your logs for errors.

yeah, i get how it works…i wasn’t thinking there would be exponential numbers of codes in there. but if clear works for me, why not use it? i wasn’t asking for him to code a custom solution for me (although i certainly appreciate it), i was asking how i could get the custom code in there if i were to change it myself.

i mean, i guess i could have just set up an automation to run the zwave clear when the slot is disabled, though. i hadn’t thought of that.

Progress! With a few notes:
Above you mention:

Then from the UI you can add the input_booleans:
allow_automation_execution:
name: ‘Allow Automation’
initial: off

When you mention UI I’m assuming you are referring to creating a toggle in “Helpers” to create this input_boolean, it doesn’t allow you to set the key to allow_automation_execution as described. In order to get this to work correctly I had to name it “Allow Automation Execution” which resulted in the correct entity name.

After restart of HA, I had to set allow_automation_execution to true and I now see it setting codes. I’m not sure if this is because OZW was not restarted when restarting HA or if this boolean should be set to initial state “on”?

Did you add the mqtt sensor I posted?

The automations there toggle the input_boolean based on the status of the ozw network.

The initial state should be “off”.

yes, the mqtt sensor is in the configuration.yaml. :man_shrugging:

Check it’s state, and make sure also that the zwave up automation has it’s action: block as you’re post doesn’t show it.

- alias: zwave up
  initial_state: true
  trigger:
    - platform: homeassistant
      event: start
    - platform: state
      entity_id: binary_sensor.ozw_network_status
      to: "on"

  condition:
    - condition: state
      entity_id: binary_sensor.ozw_network_status
      state: "on"

  action:
    - service: homeassistant.turn_on
      entity_id: input_boolean.allow_automation_execution

Sorry, newbie here, I don’t know how to check the state of the mqtt sensor? I don’t see it as an entity but I’m creating it in the configuration.yaml without error.

I see now that your zwave up has different actions than those found on FutureTense’s github repo. I’ve changed my automation to reflect your change. On restart input_boolean.allow_automation_execution appears to be off

Dev-tools->states look for binary_sensor.ozw_network_status if the sensor loaded correctly you should see either on/off as it’s state.

If it doesn’t exist, then there’s a config issue.

Sorry. Totally get it. Just always felt like then”risk” was always over exaggerated.

binary_sensor.ozw_network_status = on

good then zwave up and zwave down should trigger properly for you and turn the input_boolean on when you restart HA

The logs show that input_boolean.allow_automation_execution quickly toggles on then off on restart:

Turned off
5:08:55 PM - 2 minutes ago

Turned on
5:08:55 PM - 2 minutes ago

Can you post your current automations? both up and down

- alias: homeassistant start-up
  initial_state: true
  trigger:
    platform: homeassistant
    event: start
  action:
    - service: input_boolean.turn_off
      entity_id: input_boolean.system_ready
    - service: input_boolean.turn_off
      entity_id: 'input_boolean.allow_automation_execution'

- alias: zwave down
  initial_state: true
  trigger:
    - platform: state
      entity_id: binary_sensor.ozw_network_status
      to: "off"
  action:
    - service: homeassistant.turn_off
      entity_id: input_boolean.allow_automation_execution


- alias: zwave up
  initial_state: true
  trigger:
    - platform: homeassistant
      event: start
    - platform: state
      entity_id: binary_sensor.ozw_network_status
      to: "on"

  condition:
    - condition: state
      entity_id: binary_sensor.ozw_network_status
      state: "on"

  action:
    - service: homeassistant.turn_on
      entity_id: input_boolean.allow_automation_execution

remove that automation and you’ll be fixed

Everything appears to now be working. Thank you! I haven’t fully processed what is now different from what was recommended in README.md but the setup / control issues appear resolved. Is there anything I should be considering to get the Notifications feature to work?

You can use the snippet from this github issue, modify to your taste.

1 Like

I’m seeing this in my logs once each minute:

synchronize_codeslot_backdoor_6 has been triggered by time pattern
8:40:40 PM - 12 minutes ago
synchronize_codeslot_backdoor_4 has been triggered by time pattern
8:40:40 PM - 12 minutes ago
synchronize_codeslot_backdoor_7 has been triggered by time pattern
8:40:40 PM - 12 minutes ago
synchronize_codeslot_backdoor_1 has been triggered by time pattern
8:40:40 PM - 12 minutes ago

What lock do you have? Your probably experiencing something similar to Lock-Manager and will need to disable all the automation.enable_codeslot_sync_ automations.