Sun Elevation Triggers Instead of Clock Triggers: Automations That Track Twilight, Not the Calendar

Eli Marquette here. The failure mode I keep running into is not a broken sensor or a dead battery. It is a dusk lighting automation that was tuned in one season and quietly fires at the wrong light level months later. The trigger still fires. The trace looks clean. The porch light just comes on while the sky is still bright, or the kitchen lights stay dark through the first ten minutes of real dusk.

The usual suspect is a clock trigger or a fixed offset from sunrise/sunset. Both encode a decision made on one particular day of the year. Neither tracks how long twilight actually lasts. The fix is to choose the moment by solar angle instead of wall-clock time, and then verify the change by reading automation traces rather than trusting the clock.

Why a clock trigger drifts

Home Assistant’s own documentation is direct about this: a trigger reacts at a specific moment, not while something is true. That distinction matters. A clock trigger fires at 18:30 because you decided 18:30 was dusk when you set it up. If the actual light level at 18:30 has moved by twenty or thirty minutes since then, the automation still fires at 18:30. It has no way to know the sky changed.

The same problem applies to a fixed offset from sunrise or sunset. The documentation notes that because the duration of twilight varies throughout the year, a fixed offset is not always the best way to trigger automations around dawn or dusk. A 45-minute offset before sunset is a reasonable guess in one month and a poor one in another. The offset is constant; the twilight is not.

This is not a daylight saving problem in the sense of the clock jumping by an hour. The retrieved Home Assistant documentation does not claim that DST changes sun elevation or sunrise/sunset times, and I am not going to assert that it does. The drift I am describing is seasonal, not legislative. It happens whether or not your region observes DST. The DST transition is just the moment when a lot of people notice their clock-based automations behaving differently, because the wall-clock time of sunset has shifted by an hour relative to their trigger.

What the sun integration actually gives you

The Sun integration is configured and installed by default in Home Assistant unless you have disabled or removed the default_config: line. It calculates sun-related times such as sunrise, sunset, dawn, and dusk based on your configured home location. That last part is important and I will come back to it.

The integration exposes the sun’s elevation as an attribute on the sun.sun entity. Elevation is the angle between the sun and the horizon. Negative values mean the sun is below the horizon. The documentation describes the twilight bands as:

Civil twilight: 0° to -6°
Nautical twilight: -6° to -12°
Astronomical twilight: -12° to -18°

For most automations intended to run during dusk or dawn, the documentation suggests a number between 0° and -6°, with -4° used in its example. That is a starting point, not a prescription. The right angle for your site depends on your fixtures, your windows, your tree cover, and what you actually want the automation to accomplish.

Two trigger shapes, and when to use each

Home Assistant supports two relevant trigger forms. They are not interchangeable, and the difference matters for maintenance.

The classic sun trigger

This fires when the sun is setting or rising, which the documentation defines as when the sun elevation reaches 0°. It accepts an optional offset in seconds or HH:MM:SS format. A negative offset fires before the event; a positive offset fires after.

triggers:
  - trigger: sun
    event: sunset
    offset: "-00:45:00"

This is the middle ground. It tracks the actual sunset time for your location, so it does not drift the way a fixed clock time does. But the offset is still constant, and the documentation explicitly warns that a fixed offset is not always the best way to trigger around dawn or dusk because twilight duration varies. Use this when the offset is small relative to the seasonal swing you can tolerate, or when you genuinely want to fire relative to the sunset event rather than a light level.

The sun elevation crossed threshold trigger

This is the one that tracks the light condition you actually cared about. It fires when the sun’s elevation crosses a threshold you set.

triggers:
  - trigger: sun.elevation_crossed_threshold
    options:
      threshold:
        type: below
        value:
          number: -4

The documentation recommends this over sunset or sunrise with a time offset for automations during dusk or dawn, precisely because the duration of twilight changes throughout the year. The trigger fires when the angle crosses your threshold, regardless of what the clock says. That is the behavior you want for exterior lighting, interior scene transitions, or anything else that should respond to actual light level.

There is also a sun.elevation_changed trigger that fires on every elevation update, optionally limited to a threshold or range. That is useful for continuous tracking, but it is not what you want for a simple dusk lighting automation. It will fire far more often than you need.

The conversion procedure

Here is the sequence I use. It is deliberately conservative: you keep the old automation around, disabled, until you have compared traces over several days.

Pick a target angle. Start between 0° and -6° for twilight. The documentation’s example uses -4°. If you are not sure, -4° is a reasonable first guess for exterior lighting. Write down why you chose it.
Create the new automation with the elevation trigger. Use sun.elevation_crossed_threshold with type: below and your chosen value. Do not delete the old clock automation yet.
Disable the old automation. Do not delete it. You want it available for comparison and for rollback if the new trigger behaves unexpectedly.
Watch the traces for several days. Home Assistant records each automation run in a trace, which shows which trigger started it. Compare the new automation’s firing time against the old one’s historical firing time. If the new one fires noticeably earlier or later than you expected, adjust the angle.
Check the seasonal extremes. A threshold that looks right in spring may fire noticeably early or late in midwinter. Re-examine the threshold at the seasonal extremes, not just at install time.
Remove the old automation once you are satisfied. Or keep it disabled as documentation of what you used to do. Either is fine.

The trace record is the only cheap way to see which trigger fired and whether the resulting action matched the light level you wanted. Without it, you are guessing.

The location dependency you should check first

Because the Sun integration derives everything from your configured home location, a wrong or stale home location is a silent failure mode that affects every sun-based automation at once. If you moved your hub, changed your home coordinates during onboarding, or accepted an IP-based geolocation guess that was slightly off, every sun trigger in your system is shifted.

Home Assistant can detect your location from IP address geolocation during onboarding and automatically selects a unit system and time zone based on that location. That is convenient, but it is also a guess. You can change location and radius later under Settings > System > Home information. If any of those settings are grayed out, they are defined in configuration.yaml and you will need to edit them there.

Before debugging individual automations, verify the home location. It takes thirty seconds and it is the single most common cause of “all my sun automations are off by a few minutes” reports.

Conditions versus triggers

One more distinction that trips people up. A trigger reacts at a specific moment. If you want an automation to act only while something is true, you combine a trigger for the change with a condition for the situation.

The Sun integration provides conditions including Sun is up, Sun is set, and Sun elevation, which tests the sun’s elevation against a threshold you set. Use these when the automation should only proceed if the sun is in a particular state at the moment the trigger fires. Do not try to encode a condition into the trigger itself. They are different tools for different jobs.

For example, if you want a motion-triggered porch light to come on only when it is dark, use a motion trigger and a sun elevation condition. Do not use a sun elevation trigger and hope the motion sensor fires at the right time.

When a clock trigger is still the right choice

I am not going to pretend sun elevation triggers are always better. They are not.

If your automation is genuinely time-based — a weekday morning wake-up routine, a reminder to take medication, a scheduled irrigation cycle that depends on water pressure at a specific hour — a clock trigger is correct. The sun’s position is irrelevant to those use cases.

If you have a mechanical timer that already does what you need, and you do not need it to track the seasons, keep it. A mechanical timer is simpler, has no network dependency, and does not care about your Home Assistant configuration. The tradeoff is that it will drift with the seasons, and you will need to adjust it manually a few times a year. For some people, that is a perfectly acceptable trade.

Sun elevation triggers are for the specific case where you care about the light level, not the clock. That is a narrower case than it first appears, but it is the case where clock triggers fail most visibly.

Maintenance checklist

Verify home location under Settings > System > Home information before debugging any sun-based automation.
Re-check elevation thresholds at the seasonal extremes. A threshold that works in spring may not work in midwinter.
Use sun conditions (is_up, is_set, elevation) when an automation should only act while a state is true, rather than trying to encode that into the trigger.
Keep the old clock automation disabled rather than deleted until you have compared traces over several days.
Read the trace, not the clock. The trace shows which trigger fired and when.

If you are auditing a broader set of small systems that quietly run your week, the same principle applies: find the thing that actually determines behavior, not the thing you assume determines it. The audit guide covers that approach in more detail.

FAQ

Does daylight saving time change sun elevation or sunrise/sunset times?

The retrieved Home Assistant documentation does not state that DST changes sun elevation or sunrise/sunset times, and I am not going to assert that it does. What DST does change is the wall-clock time at which a given sun event occurs. If your automation uses a clock trigger, that shift is visible. If your automation uses a sun elevation trigger, the trigger fires at the same solar angle regardless of what the clock says.

What angle should I use for exterior lighting?

The documentation suggests a number between 0° and -6° for most dusk/dawn automations, with -4° used in its example. That is a starting point. The right angle for your site depends on your fixtures, your windows, your tree cover, and what you want the automation to accomplish. I have not seen a universal answer, and I would be suspicious of anyone who claims one.

Can I use both a clock trigger and a sun elevation trigger in the same automation?

Yes. An automation can have more than one trigger, and any of them can start the automation. If you want a fallback — say, a clock trigger that fires if the sun elevation trigger somehow does not — you can add both. Use a Triggered by condition to distinguish which one fired if the actions should differ. Just be aware that this adds complexity, and complexity is its own failure mode.

What if my home location is wrong?

Every sun-based automation will be shifted. Check Settings > System > Home information. If the location fields are grayed out, they are defined in configuration.yaml and you will need to edit them there. This is worth checking before you debug individual automations.

Does the sun elevation trigger work if my Home Assistant instance is offline?

The Sun integration calculates sun-related times locally based on your configured home location. It does not depend on a vendor cloud. If your instance is offline, the automation will not run, but the sun elevation calculation itself is local. That is consistent with the local-first approach this site covers.