Thanks. That’s good info. Schlage must be slightly different but adding the condition won’t hurt schlage users and will make this more comparable with Yale (and maybe others). Good find.
I’ve updated my package and pushed to my git repository thanks for the details
@nalipaz @ptdalen Great work guys. I just imported your package and modified to work with my set up. Everything looks as expected but when I try to set code looks like it’s not working. Am I missing anything obvious?
FYI
- Lock - Schlage Connect BE469
- Z wave - entity name correct
- I Can lock/unlock via HA
Do I need to turn on all the automation? Tried already, did not work.
Do I need to set an end date for always access? Tried already, did not work.
Must be something stupid that I am missing.
Is sensor.date__time a custom sensor?
Sorry for the delay. Couple of things come to mind to check.
So, the locking and unlocking really has nothing to do with the package, but it does at least mean that your locks are paired. Do you have all the sensors (7 I think)? Paired securely, etc.
So you put in a name and a code, then turn on the switch for the lock(s) you want the code to be set for.
Your lock is named - lock.lock_front_door_lock, (not locked, right?)
Did you name it in the entiry registry file?
Most often naming is the issue.
Can you set codes manually via the zwave panel?
I’m about to switch my Schlage lock over from Wink, but I was wondering if these instructions are still the best way to add the lock?
For example, the first step to generate a network key. I wasn’t sure if that was still necessary given the instructions are over 6 months old (that’s like 5 years in HASS years).
I’m running Hass.io and there is a pair secure zwave option in the zwave control panel.
check this post I made SOLVED Schlage Deadbolt Z-Wave Connect Added to HA a while back on this topic. I thought that was the post you were referring to.
I see @ZStanard has provided the details, but shorter answer is that you definitely need a network key for ANY device that gets added securely. Typically devices that require secure would be locks, covers (garage door/windows, etc), but other devices may also require secure pairing.
Yes, thank you. That was the post I had linked to.
I just wanted to make sure it was still the best method since it was from Dec 2017.
Yes, I have all 7 entities as below.
Back Door Deadbolt Entities
sensor.back_door_deadbolt_power_management:
sensor.back_door_deadbolt_access_control:
sensor.back_door_deadbolt_sourcenodeid:
sensor.back_door_deadbolt_alarm_level:
sensor.back_door_deadbolt_alarm_type:
sensor.back_door_deadbolt_burglar:
sensor.back_door_deadbolt_system:
lock.back_door_deadbolt_locked:
zwave.back_door_deadbolt:
I modified all the package to accomodate above names. I did change entry register file to get the name I wanted.
I am not able to set code via service pannel. I used below service and service data
Service
lock.set_usercode
Service Data
{
“node_id”:20,
“code_slot”:3,
“user_code”:“2030”
}
I also tried from Z wave panel it did not work either I have attached 2 screenshots to show what exactly I did.
Before calling set code
after set code call
Couple of things.
1 - The package file itself would have no effect of setting the codes via zwave control panel or with a service call. If those are not working, try 1st just unplugging the batteries, wait a few seconds and then plug back in. This fixed weird issues like you are experiencing most of the time. if that does not work, unfortunately the next step it to remove and add secure node again. Get the codes set working before spending time on the package.
- As far as your door lock names did you also modify the code, switches, etc for your new door names
- input_boolean.door_keypad_17_garage_switch
- input_boolean.door_keypad_18_garage_switch
condition:
action:
# if your lock does not end in "door_lock" ie. often its "door_locked" change line 3 below to match
# no other things should need to be changed
- service: lock.set_usercode
data_template:
node_id: >-
{% set object_id = trigger.to_state.object_id %}
{% set lock_name = "_".join(object_id.split("_")[3:-1]) %}
{% set lock_id = 'lock_' ~ lock_name ~ '_door_lock' %}
{{ states['lock'][lock_id].attributes.node_id }}
I just cut out a small section to explain better how it sends the lock code to the right lock.
This
{% set lock_name = "_".join(object_id.split("_")[3:-1]) %}
parses the name of the input boolean and pulls the name “Garage” (or front or back) from the name of the entity
{% set lock_id = 'lock_' ~ lock_name ~ '_door_lock' %}
This combines the name “garage”, etc to end up with lock_id being = to lock_garage_door_lock
lastly
this
{{ states['lock'][lock_id].attributes.node_id }}
ends up with lock.lock_garage_door_lock, which is used for the automation. If your lock is named differntly, that is fine, just make sure you change the code throughout the package in all of the logic.
With all that said, your issue at this time is not with the script,. After you are able to add codes via the control panel then come back to the package
Thank you for a prompt reply. I will get back with my findings later on.
H there, thanks for all the hard work getting this working. I’ve adapted the code to my house, basically removing the 2nd and 3rd locks, and adapting the names.
The one problem I am running into is that the codes and names frequently get cleared (I’m only using codes 1 and 2 right now). Which means I end up getting notifications like “Front door unlocked by Unknown”.
Has anyone else experienced anything like this?
The name gets cleared when the door is locked or unlocked manually, which is what most people do after they come into the house. Do you ever get the correct name? name would be getting pulled from here
frontdoor_code:
friendly_name: 'Front Door Code'
value_template: >
{% if is_state('sensor.lock_front_door_deadbolt_alarm_type', '19') or is_state('sensor.lock_front_door_deadbolt_alarm_type', '18') %}
{% if is_state('sensor.lock_front_door_deadbolt_alarm_level', '1') %}
{{ states.input_text.door_keypad_1_name.state }}
So lock the door, check the sensor, unlock the door check the sensor, keypad, manual, etc. Is it changing?
Might be a typo somewhere causing the value not to be getting set
I realize the name for Front Door Code gets cleared, I mean the actual name and code for Code 1, or Code 2 (the only codes we use) are now “unknown”.
I think it might be related to the issues I was having with ZHA. About 1/3-1/2 the time when I restart HA, it failed during the initialization of ZHA. Last night I got sick and tired of dealing with that issue so I removed any zigbee items from my setup.
I will keep an eye on this and see if the names disappear again.
Make sure you have the history sensor added. (I think). It will keep any input texts, booleans, etc after a restart.
Recorder component.
I have this happen when a startup doesn’t complete fully (usually because of a config error) and HA for some reason will write bogus states to the database. 
Likely a bug that needs fixing.
Yes. Recorder component thanks for the correction. I feel like that component should be mandatory. Really saves a lot of mishaps.
I was able to get it working when I renamed everything to what you have in the package. I guess there was some typo / naming mismatch somewhere. Few things I have noticied so far in my week usage.
- Temprorary Code only gets activated if you set it for future time.
- iOS Push notification does not seem to work all the time.
- battery_level attribute is no longer present is Shclage lock I guess. Are we suppoed to replace it power management?
Good deal. I have answers/questions to your questions. 
- I think that is true, I’ll double check the code, The automation that sets the code only runs when the start time is equal to the current time.
- Is there a specific notification that never works, or do some notifications work intermittently. If that the case, its more likely not an issue with the package, but with the notifier. Just let me know which ones you seem to be having the most trouble with and I’ll look closer at the yaml
- Battery level should be working, I’m on the latest version and it’s working for me using the battery template included in the package. Maybe there is something new I’m not aware of? So what made you say that it’s not present?
Thanks for your replies
I have tons of log in my log like following
2018-08-10 00:54:24 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render icon template Back Door Deadbolt Battery Level, the state is unknown.
2018-08-10 00:54:24 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render template Front Door Deadbolt Battery Level, the state is unknown.
2018-08-10 00:54:24 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render icon template Front Door Deadbolt Battery Level, the state is unknown.
2018-08-10 00:54:24 ERROR (MainThread) [homeassistant.components.sensor.template] Could not render icon template Back Door Deadbolt Battery Level: UndefinedError: 'mappingproxy object' has no attribute 'battery_level'
2018-08-10 00:54:24 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render template Front Door Deadbolt Battery Level, the state is unknown.
2018-08-10 00:54:24 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render icon template Front Door Deadbolt Battery Level, the state is unknown.
2018-08-10 00:54:24 ERROR (MainThread) [homeassistant.components.sensor.template] Could not render icon template Back Door Deadbolt Battery Level: UndefinedError: 'mappingproxy object' has no attribute 'battery_level'
2018-08-10 00:54:24 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render template Front Door Deadbolt Battery Level, the state is unknown.