@nalipaz, after upgrading to latest HA version of 0.61.0, I get the following error:
The ‘entity_id’ option (with value ‘sensor.date__time’) is deprecated, please remove it from your configuration.
Any idea?
@shmookles I have yet to do that upgrade so have not looked into it. Will look into that beforehand, let me know if you figure anything out.
After further investigation, namely looking through the release notes I don’t see any breaking changes for date time. Perhaps you have another breaking change that is cascading down into this?
Just remove the entity_id from your template sensor. It’s redundant because the id is in the template itself.
It’s in the release notes but not as a breaking change because nothing broke (yet).
3 Likes
Hello, I cam across this and it looks perfect for me. I have three locks two BE469 and an FE599. all schalage. I see that it looks like you have 4 locks. Did you create input Boolean for each of these items?
I only have 10 codes (or less), so I assume I have to create switches?
Like these
- input_boolean.door_keypad_1_front_switch
- input_boolean.door_keypad_2_front_switch
- input_boolean.door_keypad_3_front_switch
- input_boolean.door_keypad_4_front_switch
- input_boolean.door_keypad_5_front_switch
- input_boolean.door_keypad_6_front_switch
- input_boolean.door_keypad_7_front_switch
- input_boolean.door_keypad_8_front_switch
- input_boolean.door_keypad_9_front_switch
- input_boolean.door_keypad_10_front_switch
This looks pretty great, Do you have any walkthrough or tips for getting it working?
Thanks in advance, it looks exactly what I have been looking for
@nalipaz I am trying to set this up as well I removed a bunch of the code as I only have 1 lock and only need 5 slots. My question is what exactly do I have to change to make this work? I have my lock entity as zwave.front_door and the node id is 7. I assume I have to rename it to zwave.lock_front_door which should be fairly easy but where do I set the node_id or if you can tell me what node_id you have for front door and I can just find and replace?
UPDATE:
So, i just added the info into my config and I’m not home so can’t check it yet. I did notice that the entities appear to be in the format of zwave.lock.front_door in the groups section, shouldn’t the naming convention be zwave.lock_front_door
I only mention it because if you put a “.” in the name in the zwave panel it doesn’t display correctly and I’m not sure if this causes problems. Also, I noticed that it is commented out in your yaml but it threw me off a bit…
2nd update:
Hmmmm…doesn’t work. I noticed that you mention issues in another thread with clearing user codes and realized that I can’t clear them from the ozw panel. Any recommendation on how to clear user codes? Is this working for you? I have BE469NXCEN…
Quick question, for anyone who has this working, I think I’m mostly, there, I have three locks, and have got most of the scripts and sensors working, but not actually changing the codes. I think I have my lock names wrong.
This is an example of what I have
node_id: >-
{{ states['lock']['zwave_821381531664'].attributes.node_id }}
‘zwave_821381531664’ is the name of my lock (I got tired of having to rename entitiy id’s after refreshing nodes, etc so decided to just live with the names)
Here is an example from the source
node_id: >-
{{ states['lock']['lock_front_door_locked'].attributes.node_id }}
Should I add _locked to the end of my lock, or is that actually the name of the lock?
I “think” I have everthing else changed correctly,
fyi you can rename them via entity_registry.yaml 
(edit while HA is not running)
example:
lock.lock_front_door_locked:
name: Front Door Lock
platform: zwave
unique_id: 14-72057594278608896
so you’ll want to fine the node_id and that’ll be the first bit of your unique_id. My lock is node 14 hence 14-xxxxxxxxxxxx
I’ve done that several times. Works for a while but as I’ve been working in getting other things to work I’ve found it overwritten. Which breaks all my automations. Until I’m mostly stable I’ll just deal write the names
So… is my yaml correct or do i need to add locked to the end
If your entity_id does not have locked at the end of the name, you do not need it. My lock does have _locked at the end of its name, and I’m guessing @nalipaz’s does as well.
Have you checked your code using the templates tool under dev tools on the front end? I assume you’re calling these in a data_template? Share your whole snippet!
Thanks, I figured as much, I’ll share soon, but wanted to just verify first. I wanted to try to figure this out, its a lot of lines, and I’ve cut out quite a bit to tailor for my needs. I also broke it up vs a project, vs project.
Once I get a bit further along, I’ll post what I have, thanks again!
ok, I believe I found my problem and I think it’s pretty easy to solve
- alias: Keypad switch turned on
trigger:
- platform: state
to: 'on'
entity_id:
- input_boolean.door_keypad_1_front_switch
- input_boolean.door_keypad_2_front_switch
- input_boolean.door_keypad_3_front_switch
- input_boolean.door_keypad_4_front_switch
- input_boolean.door_keypad_5_front_switch
- input_boolean.door_keypad_6_front_switch
- input_boolean.door_keypad_7_front_switch
- input_boolean.door_keypad_8_front_switch
- input_boolean.door_keypad_9_front_switch
- input_boolean.door_keypad_10_front_switch
- input_boolean.door_keypad_1_back_switch
- input_boolean.door_keypad_2_back_switch
- input_boolean.door_keypad_3_back_switch
- input_boolean.door_keypad_4_back_switch
- input_boolean.door_keypad_5_back_switch
- input_boolean.door_keypad_6_back_switch
- input_boolean.door_keypad_7_back_switch
- input_boolean.door_keypad_8_back_switch
- input_boolean.door_keypad_9_back_switch
- input_boolean.door_keypad_10_back_switch
- input_boolean.door_keypad_1_garage_switch
- input_boolean.door_keypad_2_garage_switch
- input_boolean.door_keypad_3_garage_switch
- input_boolean.door_keypad_4_garage_switch
- input_boolean.door_keypad_5_garage_switch
- input_boolean.door_keypad_6_garage_switch
- input_boolean.door_keypad_7_garage_switch
- input_boolean.door_keypad_8_garage_switch
- input_boolean.door_keypad_9_garage_switch
- input_boolean.door_keypad_10_garage_switch
condition:
- condition: and
conditions:
- 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 ~ '_access_schedule' %}
{{ states['input_select'][select_id].state == 'Always' }}
action:
- 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_locked' %}
{{ states['lock'][lock_id].attributes.node_id }}
The issue is me and this section
{% set lock_id = 'lock_' ~ lock_name ~ '_door_locked' %}
If i’m understanding correctly, it’s pulling the entitiy id based on the name of the boolean switches.
So in my case lock_id would be
either
lock_front_door_locked
lock_back_door_locked
lock_garage_door_locked
which of course are not my door locks. 
So I either need to rename my input Boolean, or change the logic and just hard code the names of my locks
which are
door_to_the_garage_lock
zwave_811364754448
zwave_821381531664
into some nested if or something. Probably easiest just to rename input booleans
I use this package on my Kwikset lock, i found it easier to rename my lock 
1 Like
I believe I got it working, I also deciced to rename my lock. I made the change as I walked out the door this morning and have not been able to verify that it is truely working, but… I’m not getting entiriy id naming errors any more.
I will say I have the work LOCK a lot in my name, haha
lock.lock_back_door_lock
Thanks everyone for the help. Quick question not directly related to this. Would it be possible to hide this tab unless locally connected? Maybe hide states dev tools too. Just a thought, I’m not too worried, but might be cool. thanks
I suspect that the user structure that Paulus is working on will allow you to do some or all of this. So, soon!
Have had this working for a week or more now, Works Great. Scheduled codes works great as well. Reoccurring codes seems to be a WIP, but I have a thought/hack for this. Like for me I want to be able to have a code only on M-F 8am- 5pm. With the ability to turn it off all together.
I only have one code that needs this ability, and honestly it’s more “because I can”, than a real security concern. If the doors are unlocked while I’m away I’ll know anyway.
Anyway. my “hack” will be to set the code for always, and then set up another automation to turn on/off the switch for the door for that slot on the schedule I set. Turning off the switch will remove the code from the door, turning it on will add it back.
1 Like
Recurring is something I had planned to do and the idea you outlined was also some I thought about, I just never got around to it since I don’t really have a use for it at the moment.
1 Like
I just wanted to thank you for your work on this. This kind of thing was one of the main things I was missing from moving from Smartthings.