A hopefully easy automation trigger question

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.

1 Like

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.

1 Like

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. :slight_smile: 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. :innocent: Each solution has its pros and cons. You choose what works for you. :wink:

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. :slight_smile:

1 Like

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).

1 Like