Reliability Issue with Time Trigger based on Template Sensor (Sun Adjusted)

[viral pebble]

Hello everyone,

I'm seeking advice on a persistent automation trigger issue related to the dynamic nature of time-based template sensors. I want to understand how the internal Sun component manages its events, and how to replicate that reliability when using adjusted times.

I defined these template sensors to calculate the adjusted time once and use that single entity everywhere (automations, conditions, dashboards, etc.), especially for my customized Day/Night cycle logic.

I am aware of workarounds (like using the standard 'platform: sun' with 'offset', or updating an 'input_datetime' via automation every night), but I am specifically looking for a cleaner, robust solution that allows a time trigger to reliably fire based on the value of a dynamic template sensor.

Time Trigger Reliability

I have an automation designed to switch an 'input_boolean.jour_nuit' based on adjusted sunrise/sunset times, which are calculated using template sensors. The time trigger fails because the sensor's state updates before the time stored in its state is reached, causing the trigger to disarm.

This is a race condition between the time trigger arming and the sensor state updating for the next day. Because the underlying sensor value changes for the next day often before the programmed time is reached, no standard time or template trigger can reliably fire on the current day's value.

My Question

The built-in 'platform: sun' trigger works perfectly using the 'offset:' feature.

How does the internal Home Assistant Sun component handle these time events to avoid the race condition? Is there a recommended, robust method for using a time trigger with a dynamic template sensor that changes daily and avoids the state update causing a disarm?

Thank you for your insights!

Automation Example (The failing triggers):

triggers:

• alias: When sunrise adjusted is reached
  at: sensor.sun_next_rising_adjusted
  id: LEVER
  trigger: time
  enabled: true

... (and the sunset one)

Template Sensor Definitions:

Here are the templates used for the time calculation:

sensor.sun_next_setting_adjusted (Example for Sunset):
{{ (as_datetime(states('sensor.sun_next_setting')) + timedelta(minutes=15)) | as_timestamp | timestamp_custom('%Y-%m-%dT%H:%M:00%z', false) | default(none) }}

sensor.sun_next_rising_adjusted (Example for Sunrise):
{{ (as_datetime(states('sensor.sun_next_rising')) + timedelta(minutes=10)) | as_local | as_timestamp | timestamp_custom('%Y-%m-%dT%H:%M:00%z', false) | default(none) }}

Log Example Showing the State Change:

The sensor state changed to December 16, 2025 at 8:59 AM at 8:48:51 AM (Dec 15) because the state of Sun Next Rising changed to December 16, 2025 at 8:49 AM.
(The sensor updated its state for the next day before the current day's trigger time was reached, cancelling the planned trigger.)

System Information

• Installation Method: Home Assistant OS
• Core: 2025.12.1
• Supervisor: 2025.12.3
• Operating System: 16.3
• Frontend: 20251203.1

[tawdry sigil]

FYI: https://www.home-assistant.io/docs/automation/trigger/#sensors-of-datetime-device-class-with-offsets see the note

[tawdry sigil]

Can you show us how you set the template, and how you use it in the automation?

[viral pebble]

Hello,
This is exactly what I am asking for, how to have it properly defined and working considering for example that note.

I already shared the value of the sensor template as well as the trigger in the automation, what information would you like in addition to both of them ?

I added some screenshot, just in case it makes it more readable

[timid condor]

@viral pebble To format your text as code, enter three backticks on the first line, press Enter for a new line, paste your code, press Enter again for another new line, and lastly three more backticks.
```yaml
example: here
```
Don't forget you can edit your post rather than repeatedly posting the same thing.

[cedar hill]

Images are the worst, followed very closely by the method used in your first post to show us code.

[lone iris]

Those templates would work fine if you were using a negative offset...

The problem in this case is that you are using state-based Template sensors. And, the states on which they are based are not today's rising or setting, they are the next rising or setting. The values are rolling forward to tomorrow's events before reaching your desired times.

Your options include:

1. Using a Trigger-based template sensor or a combination of an automation and Input Datetime helpers. Set the trigger to fire after midnight and set the value for the day's events with your desired offsets.
2. Use the Sun2 integration, which offers sensors with non-rolling sunrise and sunset times.

[viral pebble]

This is the answer a LLM has generated for me, Yes. Sadly both of them are incorrect 😑

I have workarounds. The problem is that I would like to get the best option, low maintenance and reliable

[lone iris]

The problem is that I would like to get the best option, low maintenance and reliable

IMO, the best option is to install Sun2. Then you have the option to use a template sensor if you want a dynamic offset or just a Time trigger if you need a static offset.

[tawdry sigil]

What if you use just the time and simply trigger to the next time that is in fact the event of next which will be less than a minute off the today's one? If the event happens every day, do you even need full datetime timestamp? Or you could compensate with your offset that depends on the time of the year.

[lone iris]

To do that they would need to use the automation + input datetime helpers option, so it would require more templating than just using the value from the "next_" sensors.

[tawdry sigil]

why? Just a view, but maybe I am completely missing the point. If you create the template sensor that only stores the time of the day, then at the next X event the sun sensor will change, the template time value will change (but not date) and automations that rely on this time will be triggered less than with a minute offset.

The template could also compensate this offset based on the time of year if a simple if statement in a timedelta function, no?

Something like, that. This is dummy written and would actually need to know exact time when the next sun event is timewise earlier than the today, meaning January and June:

Few cases

{% set month = now() | as_timestamp | timestamp_custom('%m') | int %}
{{ month }}
{{ (states('sensor.sun_next_dawn') | as_datetime + timedelta(seconds=50 if month < 7 else -50)) | as_timestamp | timestamp_custom('%H:%M:%S') }}
{{ (states('sensor.sun_next_dawn') | as_datetime) | as_timestamp | timestamp_custom('%H:%M:%S') }}

And this would be the state of the template sensor:

{{ (states('sensor.sun_next_dawn') | as_datetime + timedelta(seconds=50 if month < 7 else -50)) | as_timestamp | timestamp_custom('%H:%M:%S') }}

Here I put 50 seconds but this needs to be carefully validated, that it doesn't put time back in past of the current time of the day or it won't fire.

[tawdry sigil]

Back from the gym, head a bit clearer now, I was wondering, why even bother and not just accept small error in time (less than a minute)?

# Your sun sensor...adjusted
{{ (states('sensor.sun_next_dawn') | as_datetime + timedelta(minutes=15) | as_timestamp | timestamp_custom('%H:%M:%S') }}

And every automation reacts only on time instead of datetime.

[untold ivy]

How will you trigger on this value? You need to use a template trigger then, as you can't use it in a time trigger directly

[tawdry sigil]

hmm, good point. Do the classes of template allow the automation to detect is only "time" and not "datetime" somehow, or time automation only expects full datetime format?

[tawdry sigil]

Why is trigger based option wrong one?

[untold ivy]

There is no time device_class for sensors. So there is also no option to trigger on a sensor which only has time.
A time trigger can have only time as input, and also a input_datetime entity which has only time

[viral pebble]

The value is changed when the sun integration reaches the time of the even, which computes the new value for the _adjusted sensors, and the automation is never triggered. At least when time decreased. This will not be an issue in some days now 😊

Currently my workaround is to define an automation triggered once a day (3 am) that sets datetime inputs from the two sun's next_setting and next_rising values, and also a template sensor that "copies" the values from the datetime input to have a nice sensor with category timestamp that can be properly displayed with badges, used as triggers for automation, be compared ...

But this requires many steps to get it working. It works, but this is not very nice and I was wondering if there is no built-in way to get that shift of some minutes when you already have a datetime sensor in place.

Here are the badges, the current day/night switch, the next setting, the next rising, so that you can quickly get the info.
The other automation can the rely on this global day/night (for lights, shutters ...) or use the correct adjusted datetime for comparisons or any other usages

[untold ivy]

Not sure what you are trying to say with this screenshot:

• yes, it is possible to use a time string
• yes, it is possible to use a time only input_datetime

what I was saying is that it is not possible to use a **sensor ** with a time only value

[tawdry sigil]

ah yes

not sensor.xxx

[untold ivy]

I meant to say this:

There is no time device_class for sensors. So there is also no option to trigger on a sensor which only has time.
A time trigger can have only a time string as input, and also a input_datetime entity which has only time

[tawdry sigil]

this might be a new feature request, have Time class, and possibility for sensor.xxx as a trigger

[untold ivy]

I believe it's already in the works

[lone iris]

But this requires many steps to get it working. It works, but this is not very nice and I was wondering if there is no built-in way to get that shift of some minutes when you already have a datetime sensor in place.

You can reduce the number of "steps" by using a trigger-based template sensor instead of the automation > input_datetime > state-based template sensor process. Or you can use Sun2.

You only need to set the sensors up once, then you can use that in Time triggers with positive or negative offsets.

[lone iris]

You could do a hybrid so that you get the "close enough" time from the "next_" sensors and today's date:

{{today_at((states('sensor.sun_next_rising')|as_datetime|as_local).time())}}

[viral pebble]

For the time being, this is the best I was able to implement. It requires an input datetime and a template sensor timestamp, copying from the input, but this makes possible to have nice integrated badges and a proper computation of the next datetime (if I stick to the full datetime, and not a time only ! )

`alias: Day/Night Toggle
description: Toggles Day/Night mode and updates timestamps
triggers:

• alias: "When the sun rises with an offset"
  trigger: time
  at: sensor.sun_next_rising_adjusted
  id: SUNRISE
• alias: "When the sun sets with an offset"
  trigger: time
  at: sensor.sun_next_setting_adjusted
  id: SUNSET
• trigger: time
  at: "01:00:00"
  id: MAINTENANCE
  `