Yeah, this is the special sauce that makes this package work. A code slot is “active” meaning the lock is “hosting” a PIN that will control the lock. A lock has a file for each code slot. For example, frontdoor_lock_manager_1.yaml is for the code slot #1 for the front door. Let’s look at it:
active_frontdoor_1:
friendly_name: "Status"
value_template: >-
{{
is_state('binary_sensor.enabled_frontdoor_1', 'on') and
is_state('binary_sensor.access_count_frontdoor_1', 'on') and
is_state('binary_sensor.daterange_frontdoor_1', 'on') and
is_state('binary_sensor.smtwtfs_frontdoor_1', 'on')
}}
device_class: connectivity
So in order for a slot to be active, four binary sensors need to be true. Let’s look at the first sensor binary_sensor.enabled_frontdoor_1 Search for that sensor definition and you will see:
enabled_frontdoor_1:
value_template: "{{ is_state('input_boolean.enabled_frontdoor_1', 'on') }}"
So “enabled” means that input_boolean is on. I didn’t need to create a sensor to check if the input_boolean was turned on, but I did it for consistency. By creating a lot of binary sensors, I can “add” them together to determine the status of the code slot. Let’s look at the smtwtfs_frontdoor_1 sensor. What does this mean?
smtwtfs_frontdoor_1:
friendly_name: "Status"
value_template: >-
{{
is_state('binary_sensor.sun_frontdoor_1', 'on') or
is_state('binary_sensor.mon_frontdoor_1', 'on') or
is_state('binary_sensor.tue_frontdoor_1', 'on') or
is_state('binary_sensor.wed_frontdoor_1', 'on') or
is_state('binary_sensor.thu_frontdoor_1', 'on') or
is_state('binary_sensor.fri_frontdoor_1', 'on') or
is_state('binary_sensor.sat_frontdoor_1', 'on')
}}
Ok, this is a little different. This is doing an OR operation on that slot’s “day” sensor’s for every day of the week. Once again, what does this mean? Well, go find the code to see:
sun_frontdoor_1:
entity_id:
- sensor.time
- input_datetime.sun_start_date_frontdoor_1
- input_datetime.sun_end_date_frontdoor_1
value_template: "{{ ((is_state('input_boolean.sun_frontdoor_1', 'on'))) and (strptime(states('sensor.date'), '%Y-%m-%d').strftime('%A') == 'Sunday') and ((states.input_datetime.sun_start_date_frontdoor_1.state == states.input_datetime.sun_end_date_frontdoor_1.state) or ((states('sensor.time') >= states('input_datetime.sun_start_date_frontdoor_1')[0:5]) and (states('sensor.time') <= states('input_datetime.sun_end_date_frontdoor_1')[0:5]))) }}"
So the “Sunday” sensor returns true if the Sunday input boolean is turned on AND the current system time falls in between the times specified in the UI. Every Code slot defaults to every day’s boolean being on and the time range being 00:00-00:00, which means every minute of the day of the week is included. So to limit codes from being on, you exclude them from days of the week and/or times as well. The access_count, and date range “exclusion” UI features work in a similar fashion.
So the “active” status is those four “big” sensors added together, and those sensors are comprised of “smaller” sensors, which may be comprised of even smaller sensors, but eventually they are defined by UI elements and/or system states.
Once you understand this concept, it’s not hard to expand upon it. Let’s say you want to use this package so people (code slots) can only access a lock on business days, during business hours. You would disable the Saturday and Sunday input booleans so those codes would be removed whenever the system time changes to either of those days. You would also change the time ranges to 09:00-17:00 for Monday-Friday, so the code (PIN) is added to the lock when the system time changes inside that range and is removed outside that range.
Now let’s say that you want to add a feature that a slot is inactive on Federal holidays. you would need to add an input boolean to turn this feature on/off. You would add this to lovelace.head file and add the sensors to lock_manager.txt file. The setup.sh script takes these files to construct the <lockname>_lock_manager_X.yaml files. (The setup script is also a big part of the “special sauce”, so you don’t have to create many files and modify them by hand).
When you are adding this new “Federal Holiday” feature, you’re going to add new binary sensors to lock_manager.txt file. We already determined we need an input_boolean to determine if this feature will be on/off for a code slot. So this sensor would return “true” if the input_boolean is on (to exclude holidays) and if today is a federal holiday.
You might add something to lockmanager.txt like:
exclude_federal_holiday_LOCKNAME_TEMPLATENUM:
friendly_name: "Exclude Federal Holiday"
entity_id:
- sensor.time
value_template: >-
{{
(is_state('input_boolean.exclude_fedholiday_LOCKNAME_TEMPLATENUM', 'off')) and
( pseudocode to return TRUE if the current system time (as expressed in states('sensor.time') is on the date of a federal holiday)
}}
So now when you enable that slot’s input boolean for Federal Holiday, it will remove the code (or prevent it from being added) if the system time falls on a federal holiday.
