I’ve been getting a bunch of errors related too template and input booleans. I went through and renamed a lot, basically taking something like “back” replacing with “mudroom” as that’s what we call one of our deadbolts.
It’s still balking at my file. Any idea where I went wrong?
Blockquote
PHA3806-2:.homeassistant aventura$ hass --script check_config
Testing configuration at /Users/aventura/.homeassistant
Failed config
sensor.template:
- Invalid config for [sensor.template]: [Mudroomdoor_action] is an invalid option for [sensor.template]. Check: sensor.template->sensors->Mudroomdoor_action. (See ?, line ?). Please check the docs at Template - Home Assistant
- platform: template
sensors: [source /Users/aventura/.homeassistant/packages/door_locks.yaml:1690]
door_lock_batteries_Front_door: [source /Users/aventura/.homeassistant/packages/door_locks.yaml:2172]
friendly_name: Front Door Deadbolt Battery Level
icon_template: {% set level = ((states[“zwave”][“lock_Front_door_deadbolt”][“attributes”][“battery_level”]*0.1)|round)*10|int %}
mdi:battery
If you only have one lock you can remove all references (or comment out) the others. it looks like the battery level for the front door lock is still being called.
You know what, totally possible. Honestly I built them and only did a few tests, and have not had a reason to use them much, so never went back. Sounds like I need to do a bit of updating. Good find
I have not had the time to test this yet, but… Alarm level is “user code slot”, It can only change to one of those values if the code is used, and the code can only be used to unlock the door. Unless you have lock and leave turned off, in that case the code slot could be used to lock the door as well. I guess it would be an edge case to set the code as one time use, and then the 1st time you used it was to lock the door, then… it would delete the code.
The other possible situations that I can think of would be if you used the slot lets say user code 15, then it deleted, then you set a new code, but never unlocked the door with any other code, then maybe it would not trigger if you used that code again.
The alarm level is also changed when the user code is first set, with alarm type 112 (0x70), confirming the code has been set on the lock. Page 4 of the Yale Developer’s Guide gives a description:
This is what I was observing. I would enable a one-time-use code and it would immediately delete. I checked the OpenZWave logs and noticed alarm type 112 being raised with the alarm level of the one-time-use code I had just created. This triggered the automation and immediately deleted the new code.
Adding the condition to watch for an explicit unlock event fixed things. I’m using Yale YRD110 (B1L) locks.
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.
@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.
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?)
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.
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.
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
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”.
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.
