KeyMaster Z-Wave lock manager and scheduler

Ok, started trying the optional settings. Not sure I’m putting the code in the correct places since I’m getting the following errors:

Error loading /config/configuration.yaml: while parsing a block collection
in “/config/automations.yaml”, line 1, column 1
expected , but found ‘?’
in “/config/automations.yaml”, line 23, column 1

I pasted input_booleans and binary_sensor into configuration.yaml. I pasted the the rest of the code (startup, cleanup and custom cleanup) into automations.ymal. Where am I going wrong?

Without seeing automations.yaml, configuration.yaml, and the scripts, it’s hard to say what’s wrong. Here’s the relevant code from my setup:
configuration.yaml

automation: !include automations.yaml
binary_sensor: !include binary_sensor.yaml
input_boolean: !include input_boolean.yaml
script: !include scripts.yaml


homeassistant: 

input_boolean.yaml

################
#Used for the garage side door lock
#https://community.home-assistant.io/t/simplified-zwave-lock-manager-update/166419/24
#https://github.com/FutureTense/lock-manager/blob/4c8adaebcb0a2b0412ae71c5952538f433dae084/FrontDoor.ini
################
allow_automation_execution:
  name: 'Garage Side Door Lock Add-in Automation Block'
system_ready:
  name: 'System Ready'
  initial: off

binary_sensor

- platform: template
  sensors:
   ################
    #Used for the garage side door lock 
    #https://community.home-assistant.io/t/simplified-zwave-lock-manager-update/166419/24
    #https://github.com/FutureTense/lock-manager/blob/4c8adaebcb0a2b0412ae71c5952538f433dae084/FrontDoor.ini
    ################
    allow_automation:
      friendly_name: "Allow Automation"
      value_template: "{{ is_state('input_boolean.allow_automation_execution', 'on') }}"
    system_ready:
      friendly_name: "System ready"
      value_template: "{{ is_state('input_boolean.system_ready', 'on') }}"
      device_class: moving

automations.yaml (added through the web UI)

- id: '1588459516157'
  alias: homeassistant start-up
  description: ''
  trigger:
  - event: start
    platform: homeassistant
  condition: []
  action:
  - data: {}
    entity_id: script.1588459432325
    service: script.turn_on
- id: '1588459691457'
  alias: Zwave_loaded_Start_System
  description: ''
  trigger:
  - event_data: {}
    event_type: zwave.network_ready
    platform: event
  - event_data: {}
    event_type: zwave.network_complete
    platform: event
  - event_data: {}
    event_type: zwave.network_complete_some_dead
    platform: event
  condition: []
  action:
  - data: {}
    entity_id: script.1588459315583
    service: script.turn_on

scripts.yaml (added from the web UI)

'1588459315583':
  alias: system_cleanup
  sequence:
  - data: {}
    entity_id: input_boolean.system_ready
    service: input_boolean.turn_on
  - data: {}
    entity_id: input_boolean.allow_automation_execution
    service: input_boolean.turn_on
'1588459432325':
  alias: customstartup
  sequence:
  - data: {}
    entity_id: input_boolean.allow_automation_execution
    service: input_boolean.turn_on
1 Like

Thanks for your files. That helped immensely and I fixed several errors based on it. I’m not sure how to use the UI to add script and automation. What do I select for Action type? I notice you have several entity IDs in your automation.yaml. Does this refer to a device? If so, what device am I selecting for each of these items? Where do you find these and what is it referring to? This isn’t clear to the novice in the github directions.

The line - id: ‘1588459516157’ not an entity id, it seems to be an ID number of the automation. The scripts also have an ID when you do them from the web UI.

Automation action type will be “call service”, service is “script.turn_on”, and the name is whatever name you gave the script. If you do it and you’re not sure, you can save it, then select “edit as YAML” to compare it to mine and then play around with that until you get it. Once you have it all done, restart HA, watch for you z-wave network to be ready, then check the automations “last triggered” to see if they fired. If they fired, check the state of your booleans and binary sensors to make sure everything is communicating.

Ok, I got to be really close now. My files are looking more like yours now. I Still have the following error, but I don’t understand the message

Invalid config for [input_boolean]: invalid slug input_boolean.system_ready (try input_boolean_system_ready) for dictionary value @ data[‘input_boolean’]. Got OrderedDict([(‘allow_automation_execution’, OrderedDict([(‘name’, ‘Allow Automation’), (‘initial’, False)])), (‘input_boolean.system_ready’, OrderedDict([(‘name’, ‘System Ready’), (‘initial’, False)])), (‘notify_frontdoor_1’, OrderedDict([(‘name’, ‘Notifications’)])), (‘daterange_frontdoor_1’, OrderedDict([(‘name’, ‘Use Date Range’)])), (‘smtwtfs_frontdoor_1’, OrderedDict([(‘name’, ‘Use SMTWTFS’)])), (‘enabled_frontdoor_1’, OrderedDict([(‘name’, ‘Enabled’)])), (‘accesslimit_frontdoor_1’, Orde… (See /config/configuration.yaml, line 17).

Config.yaml

Configure a default setup of Home Assistant (frontend, api, etc)

default_config:

Uncomment this if you are using SSL/TLS, running in Docker container, etc.

http:

base_url: example.duckdns.org:8123

Text to speech

tts:

  • platform: google_translate

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
binary_sensor: !include binary_sensor.yaml
input_boolean: !include input_boolean.yaml

hacs:
token: !secret HACS_github
appdaemon: true
theme: true

homeassistant:
packages: !include_dir_named packages

zwave:
usb_path: /dev/ttyACM0

Scripts.yaml:

‘1589578080898’:
alias: system_cleanup
sequence:

  • data: {}
    entity_id: input_boolean.system_ready
    service: input_boolean.turn_on
  • data: {}
    entity_id: input_boolean.allow_automation_execution
    service: input_boolean.turn_on
    ‘1589580122412’:
    alias: customstartup
    sequence:
  • data: {}
    entity_id: input_boolean.allow_automation_execution
    service: automation.turn_on
  • device_id: ‘’
    domain: ‘’
    entity_id: ‘’

Automations.yaml

  • id: ‘1589577285592’
    alias: HomeAssistant Start-Up
    description: Lock Manager Startup Script
    trigger:
    • event: start
      platform: homeassistant
      condition:
      action:
    • entity_id: script.customstartup
      service: script.turn_on
  • id: ‘1589578886811’
    alias: homeassistant start-up
    description: Home Assistant Start-Up Automation
    trigger:
    • event: start
      platform: homeassistant
      condition:
      action:
    • data: {}
      entity_id: script.customstartup
      service: script.turn_on
  • id: ‘1589579154920’
    alias: Zwave_loaded_Start_System
    description: ‘’
    trigger:
    • event_data: {}
      event_type: zwave.network_ready
      platform: event
    • event_data: {}
      event_type: zwave.network_complete
      platform: event
    • event_data: {}
      event_type: zwave.network_complete_some_dead
      platform: event
      condition:
      action:
    • data: {}
      entity_id: script.1589578080898
      service: script.turn_on

Binary_sensor.yaml:

  • platform: template
    sensors:
    ################
    #Used for the garage side door lock
    /FrontDoor.ini
    ################
    allow_automation:
    friendly_name: “Allow Automation”
    value_template: “{{ is_state(‘input_boolean.allow_automation_execution’, ‘on’) }}”
    system_ready:
    friendly_name: “System ready”
    value_template: “{{ is_state(‘input_boolean.system_ready’, ‘on’) }}”
    device_class: moving

input_boolean.yaml:

allow_automation_execution:
name: ‘Allow Automation’
initial: off

input_boolean.system_ready:
name: ‘System Ready’
initial: off

1 Like

You have a problem with the naming of your system_ready input_boolean. Compare it to allow_automation_execution and you’ll figure it out, I’m sure. The rest of it I can’t help you with though. I can’t read it (point 11 How to help us help you - or How to ask a good question).

1 Like

Kevin,

Thanks for the help! I very much appreciate your time and knowledge. After you cued me into the issue, the log message started to make more sense. I went through all of the code again and didn’t see an issue. But the log suggested a fix which worked (at least in part…) I changed input_boolean.system_ready from the GitHub instructions to input_boolean_system_ready. Upon doing a check config, I got the lovely green check mark.

Results:
Now the interface works when I change the code and enable the code slot 9. I see messaging over the zwave log when I manipulate all of the basic functions of each slot.

Issues:

  1. Slot 1 which has a previously programed code will not change when a new code is input in HA. I do see traffic going over Z-Wave. I need to continue to digest the messages to attempt to figure out for myself.
  2. When disabling a slot, I see traffic going over the zwave network. However, the previous code continues to function.
  3. I have not attempted the advanced settings yet because the basic settings are still not fully functional. Therefore, I don’t expect time limiting to work since I can’t disable codes anyway.

So my questions are as follows:

  1. Is there a problem in the directions on GitHub or did I make a mistake somewhere else? I assume that the answer is that I screwed something up somewhere. With that, here is my assesment:
    a) I still don’t understand how the “input_boolean_system_ready” is being called, so I’m not sure where to start troubleshooting. The only place I see it aside from input_boolean.yaml is in binary_sensor and in Scripts.yaml. In both of those files, the trouble script is defined as “input_boolean.system_ready” as defined in the GitHub instructions.

  2. Based on the above analysis, Should I try to rename every instance of this entity_id to input_boolean_system_ready? Or is there another place issue that I’m missing?

  3. I remember reading in an above post someone else struggling with the reset issue, but it was more of a bug as my memory serves. I will go back to that post and reread, but is there something else in a previous post that i may have missed that can clue me in?

Again, thanks for all the help! I’m new to HA and it will take me a minute to understand how the file structure and code works. I’ve never been a great coder and it definitely takes me a bit of time to understand what’s going on.

Here are a couple more observations:

  1. When setting a code to slot 1 which has a previous code set from the lock’s keypad, I get the following messages in the zwave log:
    a) Received user code report from node 2 for user code 1 (Not Available).
    Note: I don’t get this message when conducting the same operation on an unused slot (Slot 9 in my case)
    b) Received User Code Report from node 2 for User Code 1 (Occupied)
    c) Node0002, Notification: ValuseChanged

Note: my lock is Node 2.

I think the issue is that the lock is refusing to accept an external code because that slot has a code input in it already which was set at the lock itself. I’m wondering if a factory reset on the lock will fix this. I will try that in the next couple days and report back. For now, I want to get the rest of the system working and I can’t lock my family out of the house. I don’t trust my HA and coding skills enough to make that leap.

  1. EDIT: I found a post above that talks about one of my issues. Codes programed using the keypad will not show up in HA. You have to remove those codes on the lock and reprogram them in HA. I will do a factory reset on my lock in the next couple days and confirm this.

  2. EDIT: I again pored through my code and searched this topic. I think my issue is the same as crzykidd.

@crzykidd I updated the project with several things related to that problem you had with the missing input_boolean that prevented the automations from firing. If you are getting lots of notifications upon booting HA, you will want to add the entitites and code I put in README.MD

I added all this and it works great. I even added: binary_sensor.system_ready to the badges for the lock page. The only issue is the docs on the name as referenced in the post above

I’m had the same System_Ready configuration error and I can’t get the code to randomize when disabled. Can you tell me what your fix was? I don’t see the resolution in your posts above. Was it just the name change of System_Ready in binary_sensors? When I made this change, my check config got the green check, but it did not fix my disable code issue.

EDIT 3:

After a couple more days of troubleshooting, I deleted all the optional code and started again. I may have found an error in how I input the code the first time. When attempting to create the automation
Zwave_loaded_Start_System, the event type doesn’t auto populate like the other automatons did. I think when I ran into this issue before, I manually entered them using the editor. Is this normal behavior? Is something missing from my configuration that would prevent this form auto-populating? I don’t remember creating any other zwave references like we do for the homeassistant start-up automation… Can anyone point me in the right direction?

You are 100% correct. This is mandantory code to make the Lock Manager communicate with the lock. Everything up to this point was focusing on creating the interface. The “Optional Code” appears to focuses on translating the GUI to zwave messages and setting the correct conditions on startup. I didn’t see any log traffic until I implemented the optional code.

I recommend that the GitHub directions be modified so that it doesn’t indicate that this code is “optional”… To a novice like myself, it sends the wrong message.

2 Likes

That’s not really the point. This code is used to prevent Automations from firing when Home Assistant is first loading. Without it you will get all sorts of notifications that are reporting states instead of events. I called it “Optional” because when I’m restarting HA a dozen times an hour I get annoyed with the constant notification sounds.

Now that I think about it, 90% of my development is to fix a problem that annoys me.

Ok folks, I’m back. Sorry for the long hiatus. No, the virus didn’t get me.

Anyone care to update me on anything that might need my attention? The last problem I remembered was an issue with the setup script not working for some people. However one of you smart folks debugged it and discovered that gawk wasn’t installed for those people. I updated the README to reflect this.

I haven’t made any changes to the package, but if you have any improvements or fixes you think I should add, throw them at me. I’m glad to see that there are several forks!

@FutureTense - I have a quick question about the way you show that a code is loaded or not. I believe you turn on/off an input boolean after a code is added/removed, right? I’m finding that occasionally that codes fail to load due to zwave issues. I will say that most of the time when that happens it when I’m adding and deleting codes quickly when I’m testing things. I was thinking that it would be cool to really get a true update from zwave to know that the code really loaded. Maybe the new openzwave 1.6 will have a bit more reporting capabilities.

Are you referring to the Status field where it says Connected/Disconnected?

Yes, I believe that’s the one. It’s what tells you the code is in the lock or not, right?

Yeah, this is the special sauce that makes this package work. A code slot is “active” meaning the lock is “hosting” a PIN that will control the lock. A lock has a file for each code slot. For example, frontdoor_lock_manager_1.yaml is for the code slot #1 for the front door. Let’s look at it:

    active_frontdoor_1:
      friendly_name: "Status"
      value_template: >-
         {{
            is_state('binary_sensor.enabled_frontdoor_1', 'on')  and  
            is_state('binary_sensor.access_count_frontdoor_1', 'on')  and  
            is_state('binary_sensor.daterange_frontdoor_1', 'on') and
            is_state('binary_sensor.smtwtfs_frontdoor_1', 'on')  
         }}
      device_class: connectivity

So in order for a slot to be active, four binary sensors need to be true. Let’s look at the first sensor binary_sensor.enabled_frontdoor_1 Search for that sensor definition and you will see:

    enabled_frontdoor_1:
      value_template: "{{ is_state('input_boolean.enabled_frontdoor_1', 'on') }}"

So “enabled” means that input_boolean is on. I didn’t need to create a sensor to check if the input_boolean was turned on, but I did it for consistency. By creating a lot of binary sensors, I can “add” them together to determine the status of the code slot. Let’s look at the smtwtfs_frontdoor_1 sensor. What does this mean?

    smtwtfs_frontdoor_1:
      friendly_name: "Status"
      value_template: >-
         {{
            is_state('binary_sensor.sun_frontdoor_1', 'on')  or  
            is_state('binary_sensor.mon_frontdoor_1', 'on')  or  
            is_state('binary_sensor.tue_frontdoor_1', 'on')  or  
            is_state('binary_sensor.wed_frontdoor_1', 'on')  or  
            is_state('binary_sensor.thu_frontdoor_1', 'on')  or  
            is_state('binary_sensor.fri_frontdoor_1', 'on')  or  
            is_state('binary_sensor.sat_frontdoor_1', 'on')   
         }}

Ok, this is a little different. This is doing an OR operation on that slot’s “day” sensor’s for every day of the week. Once again, what does this mean? Well, go find the code to see:

    sun_frontdoor_1:
      entity_id:
        - sensor.time
        - input_datetime.sun_start_date_frontdoor_1
        - input_datetime.sun_end_date_frontdoor_1
      value_template: "{{ ((is_state('input_boolean.sun_frontdoor_1', 'on'))) and (strptime(states('sensor.date'), '%Y-%m-%d').strftime('%A') == 'Sunday') and ((states.input_datetime.sun_start_date_frontdoor_1.state  == states.input_datetime.sun_end_date_frontdoor_1.state) or ((states('sensor.time') >= states('input_datetime.sun_start_date_frontdoor_1')[0:5]) and (states('sensor.time') <= states('input_datetime.sun_end_date_frontdoor_1')[0:5]))) }}"

So the “Sunday” sensor returns true if the Sunday input boolean is turned on AND the current system time falls in between the times specified in the UI. Every Code slot defaults to every day’s boolean being on and the time range being 00:00-00:00, which means every minute of the day of the week is included. So to limit codes from being on, you exclude them from days of the week and/or times as well. The access_count, and date range “exclusion” UI features work in a similar fashion.

So the “active” status is those four “big” sensors added together, and those sensors are comprised of “smaller” sensors, which may be comprised of even smaller sensors, but eventually they are defined by UI elements and/or system states.

Once you understand this concept, it’s not hard to expand upon it. Let’s say you want to use this package so people (code slots) can only access a lock on business days, during business hours. You would disable the Saturday and Sunday input booleans so those codes would be removed whenever the system time changes to either of those days. You would also change the time ranges to 09:00-17:00 for Monday-Friday, so the code (PIN) is added to the lock when the system time changes inside that range and is removed outside that range.

Now let’s say that you want to add a feature that a slot is inactive on Federal holidays. you would need to add an input boolean to turn this feature on/off. You would add this to lovelace.head file and add the sensors to lock_manager.txt file. The setup.sh script takes these files to construct the <lockname>_lock_manager_X.yaml files. (The setup script is also a big part of the “special sauce”, so you don’t have to create many files and modify them by hand).

When you are adding this new “Federal Holiday” feature, you’re going to add new binary sensors to lock_manager.txt file. We already determined we need an input_boolean to determine if this feature will be on/off for a code slot. So this sensor would return “true” if the input_boolean is on (to exclude holidays) and if today is a federal holiday.

You might add something to lockmanager.txt like:

    exclude_federal_holiday_LOCKNAME_TEMPLATENUM:
      friendly_name: "Exclude Federal Holiday"
      entity_id:
        - sensor.time
      value_template: >-
         {{
            (is_state('input_boolean.exclude_fedholiday_LOCKNAME_TEMPLATENUM', 'off'))  and  
            ( pseudocode to return TRUE if  the current system time (as expressed in states('sensor.time') is on the date of a federal holiday)
         }}

So now when you enable that slot’s input boolean for Federal Holiday, it will remove the code (or prevent it from being added) if the system time falls on a federal holiday.

1 Like

Other than the gawk issue I think all the indexes should be able to be set to -1 (could be wrong I didn’t review ALL the bits). That was the other fix for a major portion of people posting.

I don’t follow. The indexes for what?

Here’s the snippet:

      action:
        - service: lock.set_usercode
          data_template:
            node_id: >- 
                {{states.lock.schlage_allegion_be469_touchscreen_deadbolt_backdoor.attributes.node_id}}
            code_slot: >-
                {% set object_id = trigger.to_state.object_id %}
                {% set index = -1 %}
                {% set code_slot = object_id[index:] %}
                {{ code_slot  }}
            usercode: >-
                {% set object_id = trigger.to_state.object_id %}
                {% set index = -1 %}
                {% set code_slot = object_id[index:] %}    
                {% set codetext = 'backdoor_pin_' + code_slot | string %}
                {% set code = states['input_text'][codetext].state %}
                {{ code | string }}

The set index = -1 part :slight_smile:

Not sure why this is cropping up, unless a sensor name got changed. Regardless, using -1 shouldn’t work. The point of setting the index is to get the slot number, which is found by examining the name of the object that triggered the automation. I believe those object names were always 14 and 17 long, so I hard coded it. I modified the code to set the index to position of the rightmost underscore plus 1, so it should get the correct slot number now.

But I don’t know what to do in order to test it using the “wrong” lock names you chose. So perhaps you can use test it with this file:

You will need to run setup.sh again, of course. If that works, I’ll merge the change into the master branch.

Thanks for the full details. Greatly appreciated. I’m doing something similiar with multiple input booleans. The issue I’ve noticed is that once in a while the lock failed to complete the zwave command and the input booleans have no way of knowing that. So the status is code is in the door, but it really is not. Or the opposite, the code does not get removed. This does not happen to often, but it does occasionally. For me at home, it’s no biggie, but for scheduled codes or maybe a vacation rental home, it would be a bigger deal, if a code failed to load or remove. I’d love to be able to get a zwave status update back saying, command completed successfully.