Mine is working. Start throwing this into your generated automations actions block to track what is firing and what is not. Especially the FrontDoor Add Code automation
- service: persistent_notification.create
data_template:
title: "debug"
message: "message goes here"
When that sensor changes to Connected, it should add the PIN to that slot. Likewise when it’s disconnected it will delete the PIN.
I missed this. That’s a good idea. Yes, you have to tweak you other automations, however you can create sensors with your naming scheme that just pony off the new lock name. I do this all the time so I only have to change entity names in one or two places.
This is the code that adds a new PIN. I’d investigate that the nodeid matches the zwave nodeid of the lock.
- alias: FrontDoor Add Code
condition:
- condition: state
entity_id: 'binary_sensor.allow_automation'
state: 'on'
trigger:
entity_id: binary_sensor.active_frontdoor_1, binary_sensor.active_frontdoor_2, binary_sensor.active_frontdoor_3, binary_sensor.active_frontdoor_4, binary_sensor.active_frontdoor_5, binary_sensor.active_frontdoor_6
platform: state
to: 'on'
action:
- service: lock.set_usercode
data_template:
node_id: >-
{{states.lock.schlage_allegion_be469zp_connect_smart_deadbolt_locked_frontdoor.attributes.node_id}}
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set index = 17 %}
{% set code_slot = object_id[index:] %}
{{ code_slot }}
usercode: >-
{% set object_id = trigger.to_state.object_id %}
{% set index = 17 %}
{% set code_slot = object_id[index:] %}
{% set codetext = 'frontdoor_pin_' + code_slot | string %}
{% set code = states['input_text'][codetext].state %}
{{ code | string }}
Anytime a Code is Enabled, this fires.
Oh snap! I forgot to document this. Make sure you have created a sensor named binary_sensor.allow_automation .I use this during startup to prevent automations from running. Put this where you create sensors. Then create the input_boolean allow_automation_execution and set it to true.
allow_automation:
friendly_name: "Allow Automation"
value_template: "{{ is_state('input_boolean.allow_automation_execution', 'on') }}"
There are some missing scripts that run during setup to turn this on and off. I’ll add them later.
Yes that was it. Ok two last questions.
Deleted codes are randomized per what @ptdalen discovered that you can’t “wipe” slots. I was going to see if you could factory reset the lock to wipe the slots, but that doesn’t work.
Six digit codes might work with a little tweaking. Matter of fact it might work already. I just haven’t adjusted the lock to try .
Ya I saw something about that in the other discussion.
Ok I have tested 6 digits and they seem to work. I will be adding a couple more locks soon. Thank you for all your work on this, it is a great addition!
@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 must be doing something wrong here… I do exactly above and I get lock_manager.ini is incomplete or does not exist?
Are you sure you saved it in the same location as the setup.sh script? That’s the only way you will get the error, or if it is empty.
I saved the FrontDoor.ini after editing it in the same directory yes, but there is no lock_manager.ini in that folder structure on github only a lock_manager.txt?
It shouldn’t matter. It scans every ini file in the directory. Are you in the directory before you run the script? Is every value populated in the ini?
Yep, I even tried renaming the frontdoor.ini to lock_manager.ini
changed the folder to lock-manager from what i had it as last night (screenshot shows lockmaster)
Why is it creating BusyBox? In any case you should debug the script and see what’s happening at line 42. See if your ini file is retrieved from that. Change line 57 to true. All of those lines should print a value.
I am running into the same issue as lazycro. wondering if it could be that i’m currently running 105 beta.
I found some old threads about it being related to Hass.io… I really haven’t had more time to play with it and I only dabble with Home Assistant itself in my small free time so debugging the script isn’t high priority at the moment for me.
When I add this I get a config check error:
input_boolean.system_ready:
name: 'System Ready'
initial: off
Had to put it as:
system_ready:
name: 'System Ready'
initial: off
Which passed config check and I think is correct, but need to reboot and check 
Ok so I think I lied on the 6 digit code working. It looks like everything works however disabling a code doesn’t not. The lock is expecting 6 digit codes and you send a 4 digit random and it doesn’t take. So somewhere you need to add a “Code Length” variable that we can set. It would be ideal if it would use this variable for the random number, and if possible validate that the code entered is the correct length to make it more wife approved
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: KeyMaster Z-Wave lock manager and scheduler - #37 by crzykidd
Find the clear code automation and you will see where it generates a 4 digit PIN. Just bump that up to 6