This is the way the lock is supposed to work. In the old integration the user code and access control was still there but was hacked to show alarm type and alarm level, and the codes mapped. One big hack, this is no longer the case and you’re seeing your proper values populate.
Alarm type and alarm level were v1 notifications for the old locks.
Access control and user code are v4 (i think) notifications for newer locks.
Notifications can expire automatically or forced to be cleared.
Specifically I mean the user code and access control, do not keep thier values. After 2-3 seconds they automatically reset to 0. I’m “ok” with this, if its normal behavior, I’m sure that can be taken into account, if I want a static value of who unlocked the door last, etc. Just want to make sure my lock is working correctly. Thanks for replying so quickly. I’ve gotten fairly far with this package, and gotta say, WOW, lots of work here. Really great. Just trying to figure out the lovelace now. 
I recall someone showing me their config options for the schlage, I recall seeing an option along the lines of “auto clear notifications” and it was a value in seconds. I’d assume setting that to 0 would persist the access control and user code data.
Now I’m gonna ask the same general questions that everyone else probably already has.
frontdoor_statusreport:
friendly_name: 'frontdoor Status Report'
value_template: >
{% set UC = 'sensor.be469_touchscreen_deadbolt_user_code_frontdoor' %}
{% set AC = 'sensor.be469_touchscreen_deadbolt_access_control_frontdoor' %}
Status report. This is my packge lines above
I have verified that my sensors are named accordingly. I see them change (even if it is currently clearing after a couple seconds) it shows as unavailable
I’d expect it to maybe not show what I want, but confused on why it is unavailable.
EDIT: when putting into the template test I get this
Error rendering template: str: Invalid domain name ‘UC’
Playing around with the template trying to figure things out a bit
frontdoor_statusreport:
friendly_name: 'frontdoor Status Report'
value_template: >
0
2
This was me manually locking the door
frontdoor_statusreport:
friendly_name: 'frontdoor Status Report'
value_template: >
{% set UC = 'sensor.be469_touchscreen_deadbolt_user_code_frontdoor' %}
{% set AC = 'sensor.be469_touchscreen_deadbolt_access_control_frontdoor' %}
{{ states.sensor.be469_touchscreen_deadbolt_user_code_frontdoor.state }}
{{ states.sensor.be469_touchscreen_deadbolt_access_control_frontdoor.state }}
{% if (((as_timestamp(now()) - as_timestamp(states.sensor.be469_touchscreen_deadbolt_user_code_frontdoor.last_changed)) < 15) and ((as_timestamp(now()) - as_timestamp(states.AC.last_changed)) < 15)) %}
{% set usercode_value = states('sensor.be469_touchscreen_deadbolt_user_code_frontdoor') %}
{% set alarm_type_value = states('sensor.be469_touchscreen_deadbolt_access_control_frontdoor') %}
{% if 'alarm_type' in 'sensor.be469_touchscreen_deadbolt_access_control_frontdoor' %}
{% set alarm_type_general_actions = {
'0':'No Status Reported',
'9':'Lock Jammed',
'17':'Keypad Lock Jammed',
'21':'Manual Lock',
'22':'Manual Unlock',
'23':'HA Lock Jammed',
'24':'HA Lock',
'25':'HA Unlock',
'26':'Auto Lock Jammed',
'27':'Auto Lock',
'32':'All Codes Deleted',
'161':'Bad Code Entered',
'167':'Battery Low',
'168':'Battery Critical',
'169':'Battery Too Low To Operate Lock' } %}
{% set alarm_type_lock_actions = {
'18':'Keypad Lock',
'19':'Keypad Unlock',
'162':'Lock Code Attempt Outside of Schedule' } %}
{% set alarm_type_code_actions = {
'33':'Code Deleted',
'112':'Code Changed',
'113':'Duplicate Code' } %}
{% elif 'access_control' in 'sensor.be469_touchscreen_deadbolt_access_control_frontdoor' %}
{% set alarm_type_general_actions = {
'1':'Manual Lock',
'2':'Manual Unlock',
'3':'RF Lock',
'4':'RF Unlock',
'7':'Manual not fully locked',
'8':'RF not fully locked',
'9':'Auto Lock locked',
'10':'Auto Lock not fully locked',
'11':'Lock Jammed',
'16':'Keypad temporary disabled',
'17':'Keypad busy' } %}
{% set alarm_type_lock_actions = {
'5':'Keypad Lock',
'6':'Keypad Unlock' } %}
{% set alarm_type_code_actions = {
'12':'All User Codes Deleted',
'13':'Single Code Deleted',
'14':'New User Code Added',
'15':'Duplicate Code' } %}
{% endif %}
{% if alarm_type_value in alarm_type_code_actions %}
{{alarm_type_value}};{{ alarm_type_code_actions[alarm_type_value] }};{{usercode_value}}
{% elif alarm_type_value in alarm_type_lock_actions %}
{{alarm_type_value}};{{ alarm_type_lock_actions[alarm_type_value] }};{{usercode_value}}
{% elif alarm_type_value in alarm_type_general_actions %}
{{alarm_type_value}};{{ alarm_type_general_actions[alarm_type_value] }}
{% else %}
{{-1}};Unknown Alarm Type Value {{ states(AC) }}
{% endif %}
{% else %}
{% endif %}
I found the setting about clearing events. The default was 5000. I imagine that was 5000 ms, or 5 seconds. I set it to 0 as suggested and I’m now good. I did this through the ozw control panel
There’s a rework in progress for the template sensors.
Did you do this through the standalone UI for the control panel or through the integration by opening the webui? I would like to make this change also however I seem to be having a problem with zwave shutting down when trying to do it through the integration. Are there instructions on how to load the standalone UI?
**Edit - I figured out my issue with running the integrated OZW Admin panel. I had to increase the cache size for it to load and open.
Try dropping this file into the custom component directory and issue the service call lock-manager.generate_package then restart HA.
My advice would be to manually unlock and lock the door. Then, take a look at the states for those entities and see which one is reporting the usercode_values. My assumption is it is one of the sensors listed, they just are not named intuitively. I think you’ll continue to get that error until you give the config form a sensor to use.
Would I then need to rename that sensor? I don’t get any options from the dropdown for usercode_values
Looks like it’s now using - input_text.frontdoor_status_report to store the value. Good news, it’s updating, bad news, it seems to be one action behind. haha. When I unlock the door, it shows what I did previously
Examples
UNlock deadbolt
lock deadbolt - Shows unlocked
use keypad unlock - Shows locked manually
Manually lock - shows - 5;Keypad Lock;1
All of the items above do show the proper values too, just did not have them hand to copy/paste
interesting, mine update immediately.
I’m getting the same results. Curious if your user notifications are reporting the same, mine are.
Adding a 3 second delay to the automation solves the issue. I’ll try setting to .5 seconds and see if that still works
EDIT: 500 miliseconds works for me and seems to work all the time
On a side note (of course I manually entered all sensors directly
This seems to work (at least in the template area)
front_door_report:
friendly_name: 'Front Door'
value_template: >
{% set number = states('sensor.be469_touchscreen_deadbolt_user_code_frontdoor') %}
{% set alarm_type_value = states('sensor.be469_touchscreen_deadbolt_access_control_frontdoor') %}
{% set entity_id = 'input_text.door_keypad_' + number + '_name' %}
{% set user = 'Master' if number == '0' else states(entity_id) %}
{% set alarm_type_value = '24' if (as_timestamp(now())-as_timestamp(states.lock.be469_touchscreen_deadbolt_locked_frontdoor.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.be469_touchscreen_deadbolt_access_control_frontdoor.last_changed)) > 15 and (states.lock.be469_touchscreen_deadbolt_locked_frontdoor.state) == 'locked' else alarm_type_value %}
{% set alarm_type_value = '25' if (as_timestamp(now())-as_timestamp(states.lock.be469_touchscreen_deadbolt_locked_frontdoor.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.be469_touchscreen_deadbolt_access_control_frontdoor.last_changed)) > 15 and (states.lock.be469_touchscreen_deadbolt_locked_frontdoor.state) == 'unlocked' else alarm_type_value %}
{% set alarm_type_general_actions = {
'1':'Manual Lock',
'2':'Manual Unlock',
'3':'RF Lock',
'4':'RF Unlock',
'7':'Manual not fully locked',
'8':'RF not fully locked',
'9':'Auto Lock locked',
'10':'Auto Lock not fully locked',
'11':'Lock Jammed',
'16':'Keypad temporary disabled',
'17':'Keypad busy' } %}
{% set alarm_type_lock_actions = {
'5':'Keypad Lock',
'6':'Keypad Unlock' } %}
{% set alarm_type_code_actions = {
'12':'All User Codes Deleted',
'13':'Single Code Deleted',
'14':'New User Code Added',
'15':'Duplicate Code' } %}
{% if alarm_type_value in alarm_type_code_actions %}
{{ alarm_type_code_actions[alarm_type_value] }} (Code {{ number}})
{% elif alarm_type_value in alarm_type_lock_actions and number == '0' %}
{{ alarm_type_lock_actions[alarm_type_value] }} with Schlage Button
{% elif alarm_type_value in alarm_type_lock_actions %}
{{ alarm_type_lock_actions[alarm_type_value] }} with Code {{ number }} ({{ user }})
{% elif alarm_type_value in alarm_type_general_actions %}
{{ alarm_type_general_actions[alarm_type_value] }}
{% else %}
Unknown Alarm Type Value {{ states('sensor.be469_touchscreen_deadbolt_access_control_frontdoor') }}
{% endif %}
Edit works as a sensor in the package as well. No delay/automation needed
Just a heads up for everyone. The “status report” only generates when something occurs on the lock itself. For example, a user enters their PIN to open/close the deadbolt. Or the user presses the “close” button. Or the deadbolt is manually turned. However when a “lock/unlock” command is sent to the lock, that does NOT generate a report. But I’m looking into making this happen.
I have a dumb question. I was working on seeing if I could get my lockpackge updated as well, and ran into issues with the clear code. It works perfectly with your code, but not even with the services for me. What I am I doing wrong
This does not work
This work great
- alias: frontdoor Clear Code
condition:
- condition: state
entity_id: 'binary_sensor.allow_automation'
state: 'on'
trigger:
entity_id: binary_sensor.active_frontdoor_1
platform: state
to: 'off'
action:
- service: ozw.clear_usercode
data_template:
entity_id: lock.be469_touchscreen_deadbolt_locked_frontdoor
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set index = object_id.rfind('_') + 1 %}
{% set code_slot = object_id[index:] %}
{{ code_slot }}
And this was my code (lock was named differently at the time)
- alias: Keypad switch turned off (Front Door)
initial_state: true
trigger:
- platform: state
to: 'off'
entity_id:
- input_boolean.door_keypad_1_front_switch
condition:
- condition: state
entity_id: 'input_boolean.allow_zwave_automation_execution'
state: 'on'
- condition: template
value_template: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = "_".join(object_id.split("_")[2:-2]) %}
{% set select_id = 'door_keypad_' ~ code_slot ~ '_front_slot' %}
{{ (states['input_boolean'][select_id].state == 'on')}}
action:
- service: ozw.clear_usercode
data_template:
entity_id: lock.front_door
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = "_".join(object_id.split("_")[2:-2]) %}
{{ code_slot }}
I verifed the conditions were good, it just did not clear, so then I tried to clear via services and nothing, then back to your package and it cleared the code as expected. Is there a trick I’m missing?
Actually after a lot of HA restarts, Docker restarts, OZW restarts, I’ve realized that the ozw.clear_usercode does not work consistantly for me. After the right reboot order it seems to work one or two times. I thought maybe it was because I renamed the entity. But I’ve tried quite a few possiblee scenarios and believe it’s the ozw.clear_usercode. I downloaded and connected MQTT explorer and watched commands get sent to the lock. Set user code shows a command sent 100% of the time. clear user code works once or twice and then the lock stops getting the commands. No messages at all. If I clear codes on different slots, it starts working (sometimes) again. Bottom line, for me I am not confident enough in the clear code for schlage locks enough to use that command. I think I’l go back to the less preferd setting a random (or specific code) for clearing, for a while.
Anyone else confirm this. Try setting and clearing the same slot multiple times. like 1 minute or so apart between actions.
EDIT: What I am noticing is that if I send clear user code to the same slot, even if I’ve loaded a code, that the clear command does not get sent. If I clear slot 1 and then clear slot 2, I can then clear slot 1 again. It seems as if OZW of HA will not send the command to the same slot twice, maybe a bug