Thanks for the tip! I ran HA without the fold entity row for a couple of weeks, but when I tried again later it just started magically working. Might’ve been a caching issue of some sort.
It was too messy (for me at least) without the fold entity row. Most of the time I don’t use the “advanced” options because the people I give codes I trust. It’s for contractors, and one offs that i wanted more restrictions for access.
The first post says it expects your lock’s entity_id to be lock.front_door_lock but the lock_manager_common.yaml seems to have it set as lock.schlage_allegion_be469_touchscreen_deadbolt_locked_frontdoor
As soon as I changed the name of the lock entity it worked. Hope this helps, Thank you for putting this together, it’s marvellous and may have won over my wife on the home automation front lol
Would mind telling me how I implement this battery sensor, I have a sensor.yaml but am nit sure what I need to change to make it work
Thanks
Copy everything from the post you quoted (except for the frontdoor_code part) and paste it in your sensor.yaml. Make sure you have sensor: !include sensor.yaml in your configuration.yaml.
After you reboot HA you’ll have a sensor.door_lock_batteries_front_door that’ll report the current battery level of the lock.
Perfect Thank You,
I did try that before but the formatting wasn’t correct. I just re did it and paid close attention to all the lines and it is working now
When I set an access time the code does not get put on the lock. If I change the start time to 00:00 it works, but if I change it to say 08:00 it does not.
I have the time_date sensor installed. Do I need something else?
There’s a bug, I haven’t had time to publish a fix, make both times 00:00 and it will work all day. I’ll publish a fix in a week or so.
Yes. But you can use the included script to set these up.
I pushed an update. Can you take a look at the README compared to the instructions here? I’m looking to make things easier to read for installation.
It’s more consistent and the readme matches up with lock_manager_common.yaml. Personally, I decided to rename the references in the script rather than my entities, but the end result will be the same, obviously.
I’m still very pleased with this lock manager. My next task is to have specific guest codes activate when the guest is connected to my wifi, limiting the, albeit extremely small, risk of someone guessing a code further.
What is more consistent?
As far as the WiFi feature, I don’t know how that would work unless you knew their MAC addresss. But if you did, you just create a new binary sensor (and input boolean to activate it) and “or” the sensor to the other advanced features. The binary sensor would “and” the input boolean and another binary sensor that determines if the MAC address is connected to WiFi. I don’t see any point to this unless you want them to be near the house before their code works. Is it so they can’t share their code?
As for guessing codes, they are just as likely to guess yours as someone else’s. And I’ve got some bad news… when a code is inactive, a random number is written over that slot. There is no way to erase a slot yet. @ptdalen can you confirm this?
It’s more consistent in that the entity_id in the README matches the entity_id in lock_manager_common.yaml; the README and common yaml didn’t match up earlier, which could be confusing during setup.
The WiFi feature would only work after they’ve visited once (and connected to it) and my device tracker (asuswrt) got a hold of their MAC, that is correct. I guess preventing code sharing would be the use case but that’s not really something I’m worried about. It’s just an excuse to waste some time fiddling with automations.
I hadn’t actually read through the config on deactivating the code, but I’m OK with it being randomized upon deactivation.
Yes the zwave code for clearing lock codes is still broken. You can update your openzwave to include the “fix”, but it becomes a hassle over time (at least it did for me). I do set a random number, but another very valid option would be to set to a specific number. Schalge does allow you to set the same code to multiple slots. So If you have one code that you never change, you could use that as the “clear code” code. Only thing you’d have to watch out for is publishing to github, haha.
So it matches now, or do I need to still clean it up?
Yes, it matches now.
I spent a bunch of time getting this setup and made a few tweaks, thought I’d share so you can incorporate what you want. Note that I use nodered, so some of this may be because I had 0 homeassistant automations going into this. Thanks so much for putting this together! it’s great!
Outside our control; is schlage working on the code clearing issue? It’s really irritating. Especially since it won’t let you set the same code for multiple users…I was going to work around that by setting inactive codes to my default family code.
Anyways…things I changed:
-
I commented out binary_sensor.allow_automation conditions. Those don’t exist in my HA instance afaik?
-
I added date_time sensor. These are used and undocumented. I’d suggest adding that to the documentation, took me awhile to figure out what wasn’t working.
-
input_boolean.lock_notifications is currently used to deliver all unlock/lock notifications. This means if I just want notifications when a temporary code is used, I have to also get manual/lock unlock notifications.
I added two new input booleans and used them as follows.
manual_lock_notifications - Used to configure whether or not to get manual lock notifications separately from general lock notifications. The new automation for lock notifications is:
- alias: Lock Notifications
trigger:
platform: state
entity_id: sensor.frontdoor_statusreport
condition:
#- condition: state
# entity_id: 'binary_sensor.allow_automation'
# state: 'on'
- condition: template
value_template: >-
{% set report = states.sensor.frontdoor_statusreport.state %}
{% set a = report.split(';') %}
{% if ((a|length) != 3 or (a[2] == "0")) and ((a[0] != "21") and ((a[0] != "22"))) %}
{{ true }}
{% else %}
{{ false }}
{% endif %}
action:
- service: script.conditional_notify
data_template:
boolean: input_boolean.lock_notifications
title: "Sensor Status Report"
message: >-
{% set report = states.sensor.frontdoor_statusreport.state %}
{% set a = report.split(';') %}
{% set msg = "ID:" + a[0] + " MSG:" + a[1] %}
{% if (a|length) == 3 %}
{% set msg = msg + " SLOT:" + a[2] %}
{% endif %}
{{ a[1] }}
The manual lock notification is:
- alias: Manual Lock Notifications
trigger:
platform: state
entity_id: sensor.frontdoor_statusreport
condition:
#- condition: state
# entity_id: 'binary_sensor.allow_automation'
# state: 'on'
- condition: template
value_template: >-
{% set report = states.sensor.frontdoor_statusreport.state %}
{% set a = report.split(';') %}
{% if (a|length) != 3 and ((a[0] == "21") or ((a[0] == "22"))) %}
{{ true }}
{% else %}
{{ false }}
{% endif %}
action:
- service: script.conditional_notify
data_template:
boolean: input_boolean.manual_lock_notifications
title: "Sensor Status Report"
message: >-
{% set report = states.sensor.frontdoor_statusreport.state %}
{% set a = report.split(';') %}
{% set msg = "ID:" + a[0] + " MSG:" + a[1] %}
{% if (a|length) == 3 %}
{% set msg = msg + " SLOT:" + a[2] %}
{% endif %}
{{ a[1] }}
code_lock_notifications - Initializes (and stays true). Per code settings control whether the automation triggers to send the notification in the first place. This is just a change to the boolean in the data template of the automation to input_boolean.code_lock_notifications.
You might want to restore that and create the sensor. I use it to disable annoying messages when the system boots up. I’ll have to publish the related boot code though for it to make sense.
Any chance of getting that boot code? I’d love to not have all of the annoying pop ups on start up.
Use these scripts and automations to wait until Zwave objects are finished loading, along with the input boolean as a condition so automations won’t run until Zwave initialization is finished.
# condition example
condition:
- condition: state
entity_id: 'binary_sensor.allow_automation'
state: 'on'
Create this automation:
- alias: homeassistant start-up
initial_state: true
trigger:
platform: homeassistant
event: start
action:
- service: script.turn_on
entity_id: script.customstartup
And this script. (And create the input boolean). Then add the input boolean to every automation as a condition. This will prevent those automations from running until you set this input boolean to true.
customstartup:
- service: input_boolean.turn_off
data:
entity_id: 'input_boolean.allow_automation_execution'
- service: automation.turn_on
entity_id: automation.Zwave_loaded_Start_System
- service: timer.cancel
entity_id:
# list all of your timers that you don’t want running here
- timer.frontdoor
- timer.fireplace
- service: script.turn_on
entity_id: script.XXXX #run other stuff here
And this automation:
- alias: Zwave_loaded_Start_System
initial_state: true
trigger:
- platform: event
event_type: zwave.network_ready
- platform: event
event_type: zwave.network_complete
- platform: event
event_type: zwave.network_complete_some_dead
action:
- service: script.turn_on
entity_id: script.system_cleanup
and this script:
system_cleanup:
sequence:
- service: homekit.start
# add whatever stuff you want to run here
- service: input_boolean.turn_on # enable automations again
data:
entity_id: 'input_boolean.allow_automation_execution'
2 Likes