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.
I get that immediately after a restart as well. I assume its because the template does not have the necessary data yet since it has not received it from the lock.
I do realize even though it is only during a restart, I’ve learned a little more since I worked on this. I think using something more like this will keep those errors away
sensor:
- platform: template
sensors:
motion_sensor_attic_battery:
friendly_name: "Attic Multisensor Battery"
value_template: "{% if states.zwave.motion_sensor_attic %}
{{ states.zwave.motion_sensor_attic.attributes.battery_level }}
{% else %}
unknown
{% endif %}"
unit_of_measurement: '%'
# entity_id: zwave.motion_sensor_attic
icon_template: >-
{% set battery_level = states('sensor.motion_sensor_attic_battery')|int('unknown') %}
{% set battery_round = (battery_level|int / 10)|int * 10 %}
{% if battery_level == 'unknown' %}
mdi:battery-unknown
{% else %}
{% if battery_round >= 100 %}
mdi:battery
{% elif battery_round > 0 %}
mdi:battery-{{ battery_round }}
{% else %}
mdi:battery-alert
{% endif %}
{% endif %}
Obviously this is not for my door lock, but the logic is the same. I’ll see if I can this working this weekend. I’ve just been blowing it off
I updated the battery templates so that they do not throw the errors on restart any more. I’ve pushed my changes to github, so feel free to pull it down. Should be much better now.
1 Like
Thank you. 
Thats not accurate, alarm_level also changes on other events. See here - http://s7d5.scene7.com/is/content/BDHHI/ApplicationNote-UsingASCII-Z-Wave-Locks
I wanted to add this here because I have tested this on my Schlage BE469 and it works great! I verified that the state of the slot becomes (Available) which means it cleared the code completely! No random code or all zeros. I successfully merged this into my own fork for open-zwave and pulled this into HA.
I am going through setting these up now. I didn’t use all of the available options but ones that I thought were most likely to be used for certain situations. I noticed in the below post you set a value to “Tamper”. Are you sure that works? I think you have to use the actual int value. See below
<Value type="list" genre="config" instance="1" index="7" label="Lock Alarm Mode" units="" read_only="false" write
_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
<Help>The alarm is turned off by default. After installation, you will need to turn on your alarm. Activi
ty Alarms when the door opens or closes. Perfect for monitoring doors while you re at home. After the alarm is triggered, there is a built-in 3-s
econd delay for it to reset. Sounds two short beeps. Tamper Alarms when the lock is disturbed, while locked. Senses subtle activity at the lock.
Sounds 15 second Alarm (90 dB) Forced Entry Alarms when significant force pushes against the door, while locked. Perfect for nighttime or when yo
u re away from home. Least sensitive mode Sounds three-minute shrill, steady alarm (90 dB)</Help>
<Item label="Alarm Off" value="0" />
<Item label="Activity" value="1" />
<Item label="Tamper" value="2" />
<Item label="Forced Entry" value="3" />
I am going to test this shortly but this is the code I have so far… I am going to setup a default type of UI but will explore a better Lovelace after.
input_select:
lock_config_value:
name: 'Select Value:'
options:
- Enable
- Disable
- Alarm Off
- Activity
- Tamper
- Forced Entry
initial: []
icon: mdi:select
lock_config_param:
name: 'Select Parameter:'
options:
- Beeper
- Vacation Mode
- Lock And Leave
- Lock Alarm Mode
- Auto Lock
initial: []
icon: mdi:select
script:
lock_config_set:
alias: Lock Config Set
sequence:
- service: zwave.set_config_parameter
data_template:
node_id: 50
parameter: >
{% if is_state("input_select.lock_config_param", "Beeper") %} 3
{% elif is_state("input_select.lock_config_param", "Vacation Mode") %} 4
{% elif is_state("input_select.lock_config_param", "Lock And Leave") %} 5
{% elif is_state("input_select.lock_config_param", "Lock Alarm Mode") %} 7
{% elif is_state("input_select.lock_config_param", "Auto Lock") %} 15
value: >
{% if is_state("input_select.lock_config_value", "Enable") %} 255
{% elif is_state("input_select.lock_config_value", "Disable") %} 0
{% elif is_state("input_select.lock_config_value", "Alarm Off") %} 0
{% elif is_state("input_select.lock_config_value", "Activity") %} 1
{% elif is_state("input_select.lock_config_value", "Tamper") %} 2
{% elif is_state("input_select.lock_config_value", "Forced Entry") %} 3
I kind of dropped off the changes via UI for zwave settings, but I can say with a very high level of confidence that the settings are ascii, vs values. I struggled for a while before realizing that. Easiest way to test was by just sending json. With that said, here is where I stopped,
input selects
lock_zwave_option_3:
name: Enable or disable the beeper.
options:
- Enable Beeper
- Disable Beeper
lock_zwave_option_4:
name: Prevents all user codes from unlocking the deadbolt
options:
- Disable Vacation Mode
- Enable Vacation Mode
lock_zwave_option_5:
name: Press the Outside Schlage Button to lock the deadbolt
options:
- Enable Lock & Leave
- Disable Lock & Leave
lock_zwave_option_7:
name: Alarm sounds based on door activity
options:
- Alarm Off
- Activity
- Tamper
- Forced Entry
lock_zwave_option_8:
name: Activity Alarm Sensitivity
options:
- Medium Sensitivity
- Most Sensitive
- Medium/high Sensitivity
- Medium/low Sensitivity
- Least Sensitivity
lock_zwave_option_9:
name: Tamper Alarm Sensitivity
options:
- Medium Sensitivity
- Most Sensitive
- Medium/high Sensitivity
- Medium/low Sensitivity
- Least Sensitivity
lock_zwave_option_10:
name: Forced Entry Alarm Sensitivity
options:
- Medium Sensitivity
- Most Sensitive
- Medium/high Sensitivity
- Medium/low Sensitivity
- Least Sensitivity
lock_zwave_option_11:
name: Disable Local Alarm Controls
options:
- Enable local alarm controls
- Disable local alarm controls
lock_zwave_option_15:
name: Auto lock
options:
- Disable auto lock
- Enable auto lock
lock_zwave_option_16:
name: User code pin length (changing Lenth erases all codes)
options:
- 4
- 5
- 6
- 7
- 8
And a group
zwave_door_lock_options:
name: zwave configs for schlages
view: no
entities:
- input_select.lock_zwave_option_3
- input_select.lock_zwave_option_4
- input_select.lock_zwave_option_5
- input_select.lock_zwave_option_7
- input_select.lock_zwave_option_8
- input_select.lock_zwave_option_9
- input_select.lock_zwave_option_10
- input_select.lock_zwave_option_11
- input_select.lock_zwave_option_15
- input_select.lock_zwave_option_16
Just never verified every single setting, or created any automations to handle it, but this shoud be a good Start, maybe this will save you a bit of typing. If you do create some automations, I’d love to see what you come up with.
I tried two things… This one example should enable the beeper. When I set this parameter and value in the zwave control section, it works just fine. So I may have to dig into the debug logs to see what service is being called.
{
"node_id": 50,
"parameter": 3,
"value": "Enable"
}
and
{
"node_id": 50,
"parameter": 3,
"value": "255"
}
using the zwave.set_config_parameter service and nothing is even showing in the OZW logs. Weird.
The first example looks right. The second won’t work. Let me do some digging. It’s been a while since I played with this
I figured it out. So odd it takes text but I had the wrong value.
{
"node_id": 50,
"parameter": 3,
"value": "Disable Beeper"
}
That worked!
I’m going to make some automations now. Especially with the Lock Alarm Mode for different times of the day to change the mode.
1 Like
Here is a reddit post from a while back that should help
Setting Zwave Parameters - Having issues https://www.reddit.com/r/homeassistant/comments/8ohi31/setting_zwave_parameters_having_issues/
Yea good deal. Figured it out right before you posted. I think once I get this done, the only thing that my lock fails to perform is notify HA of alarm_level 24 and 25 which is a known issue. I plan on scraping through all the pull requests for open-zwave to see if there was anything added. I also have a dev environment up that I can test on in a bit that has everything cherry picked plus more from others that tweaked their code. I even added the clear usercode to make it work appropriately vs having all zeros or random numbers used.
This code should do it…
https://github.com/edif30/home-assistant-config/blob/master/packages/lock.yaml
1 Like
Great stuff, when I get a bit of time, I’ll probably see about adding some of this into my lock package as well. Two quick questions,
Why did you choose to use different wording for code changed and code added for slots 1-6 and 7-15? I’m guessing it’s just because you only use 6 slots, so if anything was done with those slots it would be an “add”? I may just use changed across the board if that’s the case, but it’s just a preference.
For the zwave config parameters, the two selects are not tied to each other right? So if you were not familiar with the options you “could” select two options that were not related? Wonder if you can have a input select that depends on the value of a different input select?
Great stuff!
Edit: Also, what is the purpose of the lock it up, and unlocks scripts. I mean I understand what they do, but since you can call lock/unlock from automations easy enough, what would be the goal for this? Just trying to understand the logic, so maybe I can streamline some things as well, thanks
Edit2: good job on the additional alarm types “sensor.front_door_db_alarm_type”, I see they came from the kwickset manual, I looked and looked for a similar manual for schlage, but could not find one. Do you happen to know if schlage will report those values (low battery etc?) No worries either way, I’m definitely going to add them to my lock package since I want the package to work with as many zwave locks as possible.
Edit3: figure just adding as I go along is better than 50 posts. Once someone replys then I’ll do a new post. So… I asked for help with how to optimize a large sensor template, and I’ve think this would work. The wording is a little bit changed for my package, but still, pretty nice.
value_template: >
{% if is_state('sensor.front_door_db_alarm_type', '112') and is_state('sensor.front_door_db_alarm_level', '0') %}
Master Code Changed
{% elif is_state('sensor.front_door_db_alarm_type', '113') and is_state('sensor.front_door_db_alarm_level', '0') %}
Master Code Duplicate
{% elif is_state('sensor.front_door_db_alarm_type', '33') and is_state('sensor.front_door_db_alarm_level', '0') %}
Master Code Deleted
{% elif is_state('sensor.front_door_db_alarm_type', '112') and states('sensor.front_door_db_alarm_level')|int >=1 and states('sensor.front_door_db_alarm_level')|int <=18 %}
User {{states('sensor.front_door_db_alarm_level')}} Code Changed
{% elif is_state('sensor.front_door_db_alarm_type', '113') and states('sensor.front_door_db_alarm_level')|int >=1 and states('sensor.front_door_db_alarm_level')|int <=18 %}
User {{states('sensor.front_door_db_alarm_level')}} Code Duplicate
{% elif is_state('sensor.front_door_db_alarm_type', '33') and states('sensor.front_door_db_alarm_level')|int >=1 and states('sensor.front_door_db_alarm_level')|int <=18 %}
User {{states('sensor.front_door_db_alarm_level')}} Code Deleted
{% else %}
N/A
{% endif %}
Last Edit: What is “Front Door Attempt”? I’m guessing it would be is the door was set not to allow any codes (vacation mode maybe), but a valid code was used to try to open the door? I think that makes sense, but wanted to verify
Why did you choose to use different wording for code changed and code added for slots 1-6 and 7-15? I’m guessing it’s just because you only use 6 slots, so if anything was done with those slots it would be an “add”? I may just use changed across the board if that’s the case, but it’s just a preference.
You are correct, I have 6 main users and if any of those slots get changed, it’s a change. 7-15 is for temp or future users. I will mature this in the future and explore how this can be more dynamic. But for now, it works.
For the zwave config parameters, the two selects are not tied to each other right? So if you were not familiar with the options you “could” select two options that were not related? Wonder if you can have a input select that depends on the value of a different input select?
This is a valid point. They are not tied together currently and I thought about this when I first started to test it out. Fortunately I am aware of what each value and parameter represents but just for best practices I should tie them together. Can be easily done with some if, elif, end type stuff. I plan on updating that soon.
Edit: Also, what is the purpose of the lock it up, and unlocks scripts. I mean I understand what they do, but since you can call lock/unlock from automations easy enough, what would be the goal for this? Just trying to understand the logic, so maybe I can streamline some things as well, thanks
Google Assistant integration 
Edit2: good job on the additional alarm types “sensor.front_door_db_alarm_type”, I see they came from the kwickset manual, I looked and looked for a similar manual for schlage, but could not find one. Do you happen to know if schlage will report those values (low battery etc?) No worries either way, I’m definitely going to add them to my lock package since I want the package to work with as many zwave locks as possible.
I did not test the battery stuff (yet) but I found other zwave docs other than the kwikset one and they are all pretty much the same. Some have more, some have less. But all pretty standard. I also found something for Schlage as well in a pdf laying around and I can send that to you as well when I get home from work.
Edit3: figure just adding as I go along is better than 50 posts. Once someone replys then I’ll do a new post. So… I asked for help with how to optimize a large sensor template, and I’ve think this would work. The wording is a little bit changed for my package, but still, pretty nice.
I am personally not happy with how I wrote my template on that large one as I was doing this off the cuff but I think there is a much cleaner way to do this. I just need some more time to test it out.
Last Edit: What is “Front Door Attempt”? I’m guessing it would be is the door was set not to allow any codes (vacation mode maybe), but a valid code was used to try to open the door? I think that makes sense, but wanted to verify
Correctamundo! You will notice the alarm_type and _level correspond accordingly. I just need to add some of these template values to the “action” automation to get notified. Didn’t have enough time yesterday
1 Like