Everything seems to be running , it was working previously I just updated to the latest version of HASS and those time changed .
When I schedule a code it works and get the notify that changed but when it gets time to erase it I get the notification but it actually doesn’t erase the code.
Does it clear all the input_texts and reset the dates, but not clear the code, or, you get a notification, but all of the data for that slot remain?
It doesn’t clear the input_text and does not reset the dates neither the created code. But I do get a notification that the code has been erased from all the doors
Well if you’re getting the notification, then the automation is triggering. But if it’s not clearing anything out then the delete script is not running, which is called from the same automation
Here’s the code that you should look closer at
- service: notify.pushover
data_template:
message: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{% set usercode_input = 'door_keypad_' ~ code_slot ~ '_code' %}
{% set usercode = states['input_text'][usercode_input].state %}
{% set name_input = 'door_keypad_' ~ code_slot ~ '_name' %}
{% set name = states['input_text'][name_input].state %}
The pin code {{ usercode }} for {{ name }} has now been removed from all doors.
title: "Beach House: Temporary code disabled on all doors"
target:
- Paul
- Tracy
- condition: and
conditions:
- condition: template
value_template: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{% set input = 'door_keypad_' ~ code_slot ~ '_access_schedule' %}
{% set input_value = states['input_select'][input].state %}
{{ input_value == 'Temporary' }}
- service: script.turn_on
data_template:
entity_id: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{{ 'script.door_keypad_' ~ code_slot ~ '_delete' }}
The full automation should be named “Keypad temporary code end”
The last step of the automation is the “delete script” All it really does is clear out the inputs. The actual clearing of the code from the door actually happens before the notification, so I suspect you’ll find the codes have been removed from the door, now just to figure out why your script it not running
Also, looking at the screen shot you’ve sent.
Access Schedule of “always” wont delete the inputs (name or code), the times are actually not even used. I’m surprised you got a notification, the front and back door switches are off, so the codes should be removed from the door.
I guess what I’m saying is the screen shot does not fit with what you’re describing.
Sorry I’m not communicating effectively. I dont want to waste your time. So let me start over.
So on slot #1 when you started
You had a name, and a code (0217)entered for slot 1. Then you selected Temporary as your access schedule, then you entered your start and end time, then lastly you turned on your front and back door switch.
you then verified that the code you entered is working on the door.
Then the access end time passed, you got your alerts, the name and code were cleared, and the front and back door switches turned off.
You then waited for a short time (less than a min should be fine), and verified that your code (0217) still unlocked the door.
That that basically what has happned so far?
If so, is it possible that you ever assigned that same code to a different slot? schlage will actually let you set the same code to multiple slots.
Try this, pick a code that you’ve never used before. Before even setting it in HA, go to the door, and try that new 4 digit code. Verify that it does not work.
Then go through the process again with the new code. Verify that it now works, and when the end time hits, verify that it is not working.
One other possibility. If you replaced or removed and re-added your lock any time soon, the zwave node ID would have changed, and the node id is what gets used to clear the code slot
# Front Door Deadbolt. You must put in the zwave node id's here
node_id: 104
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{{ code_slot }}
- service: lock.set_usercode
data_template:
usercode: >-
{{ range(1000, 9999) | random }}
Well that’s what actually what happened I did tested the 0217 just to make sure it did not work then did the temporary access code and worked no problem got the pushbullet alert then after the access end time based I got the alert again tested 0217 still worked
So there was not possibility that the code was used before
I replaced the nodes with my node ID
Thanks
It looks like you’re having a zwave issue then. You’ll have to look through your zwave logs to figure out why it’s not sending the random code from this part of the automation
action:
- service: lock.set_usercode
data_template:
usercode: >-
{{ range(1000, 9999) | random }}
# Front Door Deadbolt. You must put in the zwave node id's here
node_id: 104
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{{ code_slot }}
- service: lock.set_usercode
data_template:
usercode: >-
{{ range(1000, 9999) | random }}
it sounds to me like the yaml is working, the alerts are being sent, the inputs are clearing, and the switches are turning offf. It looks like the only thing failing is the zwave part.
What if you set it to always, set a code, then turn on the lock. Verify that code works, then turn off the lock switch. It should clear the code. Does that work?
Well that part its commented
# this is where usercodes get deleted, for the Schlage locks there seems to be an issue with
# clear usercode, setting to 0000 works for some locks, but for the schalge it sets 0000 as a
# valid code, so this sets a random code, of course that means there is an unknown code in the cleared
# slots. If you dont like that set a specific code that only you know
# Update 9/4/18 - I have updated my openzwave for the locks and the clear usercode now works. I have commented
# out the section with the random number. If you are are using the release version you can uncommoment that section
# and comment out the clear user code sections
action:
# - service: lock.set_usercode
# data_template:
# usercode: >-
# {{ range(1000, 9999) | random }}
## Front Door Deadbolt. You must put in the zwave node id's here
# node_id: 82
# code_slot: >-
# {% set object_id = trigger.to_state.object_id %}
# {% set code_slot = object_id[7:-19] %}
# {{ code_slot }}
#
# - service: lock.set_usercode
# data_template:
# usercode: >-
# {{ range(1000, 9999) | random }}
## Back Door Deadbolt. You must put in the zwave node id's here
# node_id: 99
# code_slot: >-
# {% set object_id = trigger.to_state.object_id %}
# {% set code_slot = object_id[7:-19] %}
# {{ code_slot }}
- service: lock.clear_usercode
data_template:
# Front Door Deadbolt. You must put in the zwave node id's here
node_id: 22
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{{ code_slot }}
- service: lock.clear_usercode
data_template:
# Back Door Deadbolt. You must put in the zwave node id's here
node_id: 25
code_slot: >-
{% set object_id = trigger.to_state.object_id %}
{% set code_slot = object_id[7:-19] %}
{{ code_slot }}
We do suppose to uncomment that part ?
So, my understanding from your earlier comments is that this was working for you before. So my comments to you were based on that. If you have not done your own zwave fork and updated the usercode.cpp file to handle properly clearing user codes then it likely was not working, you may have not noticed. I had updated my Zwave for this and used it for a while until it became too much of a pain to keep updated. Anyway, “lock.clear_usercode” does not work for many locks. Schlage for sure, and I think Yale locks also dont work with the clear usercode. I tried to provide clear comments about that, but have gone back and forth over the past year.
Bottom line, unless you’ve updated your OWZ or have a lock that supports the clear user code,should uncomment the section where a random code is set, and comment out the clear user code section
That did the trick , sorry it was a confusion I thought you fixed the Schlage Problem to clear user code and we don’t need to uncomment that part.
Tested and everything is working fine now I really appreciate the help @ptdalen !!!
No problem. I had fixed it for my personal install of HA by forking OWZ and adding the updates, but figured most people would not be doing that. Even I stopped doing it after a while. But I wanted to leave the code in the yaml for either option. Glad it’s working now.
Kiwkset also does not work.
Maybe i’m just missing something. I added the package but I don’t know what lovelace cards to use to get everything to show up. Is this documented somewhere?
This is a bit old but this should give you the general idea
Thank you! I have the UI showing now, but the new lock codes aren’t making it to the lock and notifications arent being sent.
I replaced the lock variable names in the yaml and replaced the notify service with pushover. I tested pushover on its own and it seems to be working.
Is there a simple way to debug where this is failing?
Did you also change the node_id in the yaml?
Yep! I’m getting this error in the zwave logs
2019-09-09 13:35:28.758 Error, Node008, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack