I would like to create an automation to turn on a device at the later of sunset or a fixed time. I created an automation with both of these as a trigger, but I am not sure that it will behave as desired. Can you please provide an example of that which should be done? Thanks.
That automation will trigger at both times. What you want is to trigger only at whichever time is later.
I know how to do what you requested but before I explain it, does an entity supply the fixed time? In other words, is the fixed time the value of a sensor or input_datetime or it is simply a time string, like 18:15
?
Taras - Thanks for offering to help. A tad more background: The device is the lights over the kitchen sink and I want to be able to see stuff in the kitchen by 7:00 pm. However, if it is not yet sunset, there is enough light. Thus, I would like to turn the lights on at the later of 7:00 pm or sunset.
Create a Template Sensor that compares sunset to 19:00
and reports whichever time is later. The only tricky part here is computing todayâs sunset. After sunset, the datetime reported by next_setting
becomes the next dayâs sunset time. We need to adjust it so that it always represents the current day.
This Template Sensorâs device_class
is timestamp
because it will be used as the trigger time for a the automationâs Time Trigger.
template:
- sensor:
- name: Turn Off Light
device_class: timestamp
state: >
{% set sunset = (state_attr('sun.sun', 'next_setting')|as_datetime|as_local).strftime('%H:%M') | today_at() %}
{{ [sunset, today_at('19:00')] | max }}
The automation is very simple. It uses a Time Trigger that triggers at whatever value is reported by the Template Sensor.
alias: Turn Off Light
trigger:
- platform: time
at: sensor.turn_off_light
condition: []
action:
- service: light.turn_off
target:
entity_id: light.your_sink_light
Thanks - I will âstudyâ this. For the purposes of this automation, the difference between todayâs sunset time and tomorrowâs sunset time are sufficiently insignificant that difference doesnât matterâŚ
Itâs not the time difference, itâs the date difference.
Letâs say sunset today is 18:00
. Thatâs earlier than the fixed time of 19:00
so the automation should trigger at 19:00
.
However, shortly after sunset today, the value of next_rising
will change from todayâs sunset date and time to tomorrowâs sunset date and time. The key point here is it will become tomorrowâs date which is later than 19:00
today and so the Time Trigger wonât trigger today.
The calculation performed in the Template Sensor ensures the date is always todayâs date (not tomorrowâs date).
I think you can do this with just two triggers and two conditions.
A trigger for 7pm and a trigger for sunset.
A condition that it is after 7 (or 6:59pm?) and the sun is below the horizon.
Simple and efficient. Brilliant!
There are always different ways to automate something. A lot of people, including myself, tend to think about sunset but never about the sun elevation. This is great.
If you mean adding a condition to the automation containing two triggers is efficient, itâs not. Hereâs why:
For all the days of the year when sunset is before 19:00
, the automation will always trigger twice a day. It will trigger at sunset, be halted by the condition, and then trigger again at 19:00
. In other words, throughout late fall, all of winter, and early spring (assuming you are in the northern hemisphere), the automation will needlessly trigger twice every day.
In contrast, the Template Sensor computes the exact time when the automation should trigger; it will trigger just once every day all year long. It also has a side-benefit of reporting the remaining time (in the Lovelace UI) until the automation will be triggered.
However, if you donât mind the inefficiency of triggering twice a day, post the condition you used so that others can see how to do it.
Fair point about the efficiency, I didnât look at it that way. I agree with you.
Right now, Iâm having problems with my Home Assistant installation so I need to fix it before I can even try this and provide the details.
It is however an efficient use of mjitkopâs time which is way more precious than the 2 femtowatts of CPU power that the âtwo triggerâ version uses (if it even is indeed less efficient).
Throw in one template sensor breaking change (which will almost certainly never happen with the two triggers version) and youâre kicking yourself. Unless OP plans on using that sensor in other automations, in which case there would be value in defining it in one place.
Thanks all. I tested the two triggers/two conditions approach and it worked fine. Mine is a very simple system, so the efficiency matter is a non-issue for me.
Triggering for no reason at all is an anti-pattern; itâs hardly a recommended practice.
FWIW, it was mjitkop who mistakenly referred to it as being âefficientâ (which itâs not).
As for the argument about potential breaking changes for Template Sensor, thatâs scaremongering; all aspects of Home Assistant may be subject to future breaking changes.
Speaking of precious time, it seems like no one has enough of it to post the condition that is being used.
No need to argue. Each solution has its pros and cons. You choose what works for you.
Anyway, I have finally fixed my HA problem (it failed to update to the latest version due to a known problem).
Here is the Yaml code for the 2 triggers, 2 conditions solution, if you choose to use it:
alias: Latest of fixed time and sunset
description: ''
trigger:
- platform: sun
event: sunset
offset: '0'
- platform: time
at: '19:00'
condition:
- condition: state
entity_id: sun.sun
state: below_horizon
- condition: time
after: '19:00'
action:
- type: turn_on
device_id: (hidden for posting)
entity_id: light.bedroom_light
domain: light
mode: single
I think this is it. Not actually tested because too early in the day right now.
Itâll trigger twice, but itâll work.
It employs a common design pattern where the triggers are duplicated as conditions; any one of multiple events can trigger the automation but all of the events must be true in order to execute the action. However, itâs normally employed with dissimilar triggers and not similar triggers (such as two time-based triggers).