I never tested that one, only the one I posted (and it works correctly on startup).
I used that version (tinkererâs) on a few automations except I removed the â-1â multiplier since the conditions should prevent the actions from running if the time is past. No reason I can see to set the datetime into the past.
so far everything is working fine with that slight modification.
Itâs a âlittle extraâ to prevent the Time Trigger from firing.
In this case, if the lock is locked prior to the Time Trigger, thereâs no reason for the Time Trigger to occur. By setting the Time Triggerâs value to the past, it will never trigger, effectively disabling it.
Having said that, thereâs no harm in it triggering because the code first checks if the lock is already locked and so it wonât re-lock it. However, disabling the Time Trigger prevents it from even executing that check and is a âlittle extraâ to minimize execution time.
It has one other benefit if one uses Tinkererâs enhancement. Letâs say the Time Trigger fires at 09:10 and moments later Home Assistant restarts. If it starts at 09:11, the Time Trigger is within the enhancementâs 2-minute window and will execute the locking code. Again, it wonât actually lock anything because it first performs a check to determine the lockâs status (and itâs already locked). Setting back the Time Trigger more than 2-minute window ensures it doesnât even get beyond the conditions
in choose
.
So thereâs a reason for it but itâs purely a nicety to minimize execution time.
Thanks all for the assistance on this. One thing I did noticed is that lock would still try to lock if the door itself is open (after the 30mins of course). How would I also add this condition?
"{{ is_state('binary_sensor.front_door', 'off') }}"
Use a state condition. A template is overkill.
In an effort to address at least the for:
limitations I submitted an issue:
feel free to add your vote/information to the thread.
Also just to add a bit more reliability to the above workaroundâŚ
also reloading automations will cause the same effect of canceling the timed functions so that needs to be added to the trigger and conditions as well:
- alias: Automatic Door Lock
id: automatic_door_lock
mode: queued
trigger:
- platform: state
entity_id: lock.door
to: 'unlocked'
- platform: time
at: input_datetime.door_lock
- platform: homeassistant
event: start
- platform: event
event_type: automation_reloaded
condition:
condition: state
entity_id: input_boolean.pause_automations
state: 'off'
action:
- choose:
- conditions: "{{ trigger.platform == 'state' }}"
sequence:
- service: input_datetime.set_datetime
entity_id: input_datetime.door_lock
data:
datetime: >
{{ (now() + timedelta(minutes = 30)).timestamp() | timestamp_local }}
- conditions:
- "{{ trigger.platform == 'homeassistant' or trigger.platform == 'event' }}"
- "{{ as_timestamp(now()) - as_timestamp(states('input_datetime.door_lock')) < 120 }}"
- "{{ is_state('lock.door', 'unlocked') }}"
sequence:
- service: lock.lock
entity_id: lock.door
- conditions:
- "{{ trigger.platform == 'time' }}"
- "{{ is_state('lock.door', 'unlocked') }}"
sequence:
- service: lock.lock
entity_id: lock.door
seems way too complicated just to solve the problem of for:
being broken.
And of course the issue was immediately closed with no discussion of possible alternatives or even recognition of the issue this behavior causes users.
I triedâŚ
Try this custom component GitHub - PiotrMachowski/Home-Assistant-custom-components-Saver: This custom component allows you to save current state of any entity and use its data later to restore it. it did the job for me.