Lock-Manager is now named KeyMaster
NOTE: This thread has been renamed from Simplified Lock Manager.
Please be aware that this package supports both the native Zwave network interface included in Home Assistant and the OpenZWave Beta project, aka ozw. While we are supporting both implementations, if and when HA switches to ozw, we will drop the (current) zwave.
When asking for support, please indicate if you’re using zwave or ozw.
What this package does is fairly simple. It lets you define sensors for when a lock-code should be active. A lock-code is a “user slot” for a specific lock. When a lock-code sensor turns true/false the code should be entered/deleted from the lock. Then through the setup script, it will configure a lock with as many code slots as you define in the .ini file, in addition to generating the lovelace for that lock.
I pushed out a significant update to the first release of this project. It’s still very much a work in progress and this release should still be viewed as a beta.
So what’s different between this release and the prior? Besides bug fixes, it boils down to support for multiple locks and the setup procedure.
For a simple experience, please Install via HACS.
Setup procedure
1. Place the files from github into a directory called packages/lock-manager. From a command prompt, modify the setup.sh script so that it is executable.
chmod +x setup.sh
2. Edit FrontDoor.ini and replace the values in the file to be used to configure your lock. For example, specify the number of PIN slots you want for this lock. Make sure you have modified your lock’s entities so that you have appended _FrontDoor (or whatever you are naming your lock) after every entity for that lock. Also make sure you’ve specified the “base” name for the lock in the ini file.
3. Repeat step 2 for each additional lock you have. So you if you have another lock in the back, copy FrontDoor.ini to BackDoor.ini and modify those values accordingly.
4. Run FrontDoor and the other a lock named BackDoor you will end up with two directories named accordingly. Restart Home Assistant../setup.sh and this will take each ini file in the directory and create a subfolder for each lock. So if you have two ini files and one had a lock named
5. In each subdirectory created in step 4, there will be a lovelace file which contains a new view representing that lock. So for the example in step 4, you should have the following two files:
packages/lock-manager/FrontDoor/FrontDoor_lovelacepackages/lock-manager/BackDoor/BackDoor_lovelace
If you are using the GUI lovelace design, open the “raw source” and paste the contents of each file at the end of the raw source YAML. Save the code and exit the GUI editor and you will see two new views representing the two locks.
Feedback, as always is welcome.
IMPORTANT NOTE
This integration requires you to create an input boolean named input_boolean.allow_automation_execution. This “variable” is used extensively throughout the integration to prevent most code execution from happening unless this value is true. This is because we don’t want the code running when Home Assistant is starting up. So you will need to create some automations to control this input boolean.
Regardless if you are using ozw or the native zwave implementation, you need to make sure the network has started before allowing automations. These automations should handle this.
Add to your automations
# This automation ensures that input_boolean.allow_automation_execution
# is turned off when the system starts loading. You can also use this automation
# to handle other startup functions.
- alias: homeassistant start-up
initial_state: true
trigger:
platform: homeassistant
event: start
action:
- service: input_boolean.turn_off
entity_id: 'input_boolean.allow_automation_execution'
- service: input_boolean.turn_off
entity_id: input_boolean.system_ready
- service: timer.cancel
entity_id:
- timer.litterbox
- timer.fireplace
- service: google_assistant.request_sync
data_template:
agent_user_id: !secret GAagent_user_i
- service: system_startup_cleanup
# When either z-wave network stops, disable the automation boolean
- alias: open_zwave_network_down
initial_state: true
trigger:
- platform: state
entity_id: binary_sensor.ozw_network_status
to: "off"
- platform: event
event_type: zwave.network_stop
action:
- service: homeassistant.turn_off
entity_id: input_boolean.allow_automation_execution
# When either z-wave network starts up, call the cleanup code
- alias: zwave_ozw_network_up
initial_state: true
trigger:
- platform: state
entity_id: binary_sensor.ozw_network_status
to: "on"
- platform: event
event_type: zwave.network_ready
- platform: event
event_type: zwave.network_complete
action:
- service: script.system_startup_cleanup
Add to your binary_sensors
binary_sensor:
- platform: mqtt
name: ozw_network_status
state_topic: OpenZWave/1/status/
value_template: >
{{ "ON" if value_json.Status in ["driverAwakeNodesQueried", "driverAllNodesQueriedSomeDead", "driverAllNodesQueried"] else "OFF" }}
json_attributes_topic: OpenZWave/1/status/
device_class: "connectivity"
Add to your scripts.
# If you are not using HomeKit, you should remove the service call.
# If you are, this ensures it will only start after zwave/ozw Network has started
# Note the last call turns on input_boolean.allow_automation_execution
system_startup_cleanup:
sequence:
- service: homekit.start
- service: input_boolean.turn_on
entity_id: input_boolean.system_ready
- service: input_boolean.turn_on
entity_id: 'input_boolean.allow_automation_execution'
