Home Assistant Sun Offset: Before or After Sunrise and Sunset

The short answer: negative is before, positive is after

The classic sun trigger takes an event, either sunrise or sunset, and an optional offset. The Sun integration documentation states the rule directly: a negative value fires the trigger before the sun event, and a positive value fires it after. The offset can be a number of seconds or an HH:MM:SS string, so the sign carries the direction and the number carries the distance.

Here is that arithmetic for an invented 06:00 sunrise. These are clock sums that show the convention, not a sunrise forecast for any particular place:

Sunset follows the same rule: with an illustrative 18:30 sunset, an offset of -00:45:00 fires at 17:45 and an offset of 00:45:00 fires at 19:15. The sign, not a separate switch, decides whether the automation runs early or late.

The editor and YAML store that direction differently

The dedicated Sunset trigger page walks through the current visual editor, and the steps are worth following exactly because the direction field is easy to miss:

1. Go to Settings > Automations & scenes.
2. Open an existing automation, or select Create automation > Create new automation.
3. In the When section, select Add trigger.
4. From the search box, search for and select Sunset.
5. Under Offset, enter how far from sunset to fire, such as 30 minutes. Under Offset type, select Before or After.
6. Select Save.

Those steps come from the Sunset trigger reference, and the same page notes that before is the default when no offset type is chosen. Sunrise has its own trigger in the same family, and the Sun integration lists the full set, including dawn, dusk, golden hour, and elevation triggers.

Behind the visual editor, the dedicated trigger stores the direction in a separate offset_type field. What follows is a partial trigger example, not a complete automation: it is one list item under triggers:, with the trigger's own settings nested under options exactly as the Sunset page describes.

triggers:
  - trigger: sun.sunset
    options:
      offset:
        minutes: 30
      offset_type: before

The offset there is a plain length of time with no minus sign anywhere; offset_type carries the direction, it accepts before or after, and the page lists before as the default. The trigger itself is referred to as sun.sunset.

The classic sun trigger that the Sun integration still supports is built the other way around. This is again only the trigger portion of an automation, not a complete one:

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

There is no offset_type here. The sign on the offset is the direction, and the value may be seconds or HH:MM:SS. Both forms are documented, and they are simply two different interfaces to the same idea. Mixing them is a common way an offset appears to be ignored: a negative value has no meaning to give a trigger that takes its direction from offset_type, and an offset_type key has nowhere to live in a classic trigger. Before changing the number, confirm which of the two you actually pasted.

A minimal notification automation you can adapt

The automation below is complete and harmless. It writes a persistent notification inside Home Assistant and touches no lock, heater, or other physical device, so it is safe to leave enabled for a day while you watch the timing.

alias: "Sunset offset notification test"
triggers:
  - trigger: sun
    event: sunset
    offset: "-00:45:00"
actions:
  - action: persistent_notification.create
    data:
      title: "Sunset in 45 minutes"
      message: "The sun trigger fired 45 minutes before sunset."

That block is a complete automation: alias, triggers, and actions. It belongs in the YAML editor of one individual automation — open Settings > Automations & scenes, open or create the automation, then switch to YAML editing. If you keep automations in configuration.yaml instead, this becomes one more list item under the existing automation: key: indent it under that key with a leading - and leave the rest of the file alone. Do not write a second automation: line, and do not add a second top-level alias: beside the existing key.

Read it in three parts. event: sunset pins the automation to sunset at your configured home location. offset: "-00:45:00" moves the run 45 minutes before that event. persistent_notification.create produces a dismissible notification in the Home Assistant frontend, which is why the example needs no notify platform or phone app.

To fire 45 minutes after sunset instead, change the offset to 00:45:00. To keep the same direction but shorten the interval, change only the minutes: -00:15:00 is a quarter of an hour before the event, not a quarter of an hour after it.

If you would rather use the dedicated trigger, the equivalent of this example is trigger: sun.sunset with an offset of 45 minutes and offset_type: before, because the notification fires before sunset rather than after it. To fire 45 minutes after sunset instead, keep the same length and change only offset_type to after. Choose one style per trigger and do not mix keys between them.

When the timing still looks wrong

Work through these checks in order. Each one produces the same symptom, an automation that fires at a time you did not expect, so the order matters more than the length of the list.

First, the home location and the time zone. The Sun integration calculates sun times from your configured home location, according to the Sun documentation, so a location left at an old address shifts every event. The time zone is part of the same settings area: as our guide to time conditions across midnight notes, Home Assistant reads it under Settings > System > Home information, and a changed zone changes the local clock time of every sun event. Confirm both before you edit any offset.

Second, the direction the saved trigger actually encodes. An automation that runs early is not by itself a reason to reach for a negative number: a negative value is what causes the earlier run, so the symptom cannot tell you which end of the interval you want. State the direction you intended first — before sunset or after sunset — then read the stored direction and compare the two. In the classic sun trigger, a positive offset encodes an intended after-sunset run and a negative offset encodes an intended before-sunset run, so for an 18:30 sunset, -00:45:00 fires at 17:45 while 00:45:00 fires at 19:15. In the dedicated sun.sunset trigger the direction lives in offset_type, and leaving it out means before. Once intended and stored directions agree, the only open question is whether the length is right.

Third, the UTC attributes. The Sun integration exposes next rising, next setting, next dawn, and next dusk as attributes on sun.sun, and its documentation states that those values are in UTC. A template or a state view that prints them beside your local clock will look hours off in most of the United States, and that difference is not evidence that the trigger is wrong. Interpret the attribute as UTC before you compare it with the time you expect, and keep in mind that the gap between UTC and your own zone changes with daylight saving.

Fourth, the difference between the horizon and the light. Sunset is a horizon event, not a darkness event. The Sunset trigger page also notes that the sun entity can change to below the horizon a few minutes after the trigger fires, so a state change that lags the trigger by minutes is expected. A fixed offset tracks the horizon, not the light level in your kitchen.

If all four checks pass and the run still lands at the wrong minute, look at the automation trace rather than the YAML: the trace shows when the trigger fired and what ran afterwards. Our own guidance in the midnight time-condition guide applies here too, including its caution that the manual Run actions button can skip triggers and top-level conditions, so it never proves that the trigger itself fires on schedule.

When a fixed offset is the wrong tool

A fixed offset is predictable, which is its virtue: the automation is a known number of minutes from an event you can describe. It is also blind to the seasons. The Sun integration's own documentation notes that because the duration of twilight varies through the year, a fixed offset is not always the best way to trigger around dawn or dusk, and it points to the elevation trigger for those cases.

This is another partial trigger example — one trigger only, not a complete automation:

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

The same documentation describes elevation as the angle between the sun and the horizon, mentions that a value between 0 and -6 degrees is often used for twilight, and offers -4 degrees as a point that can be practical for turning on outdoor lights. Two limits matter more than the number itself. First, elevation is an astronomical angle — a proxy for where the sun sits in the sky, not a measurement of how bright your rooms are. Cloud cover, haze, window orientation, trees and neighboring buildings, and the room's own surfaces all sit between that angle and what you see indoors, so an elevation threshold is not a promise that the lights come on exactly when the house feels dark; it is a different proxy that you check against your own conditions and adjust. Second, -4 degrees is illustrative guidance from that page, not a universal correct threshold and not something we tested. Any value you adopt is a starting point rather than an answer.

That makes elevation a trade-off rather than an upgrade. The clock time of an elevation trigger moves through the year, which is the whole point of using it, and it no longer matches a fixed number of minutes. If you need a reminder that always arrives 45 minutes before sunset, keep the fixed offset. If the trigger should follow the sun's position rather than a fixed interval, an elevation threshold or the dedicated dusk trigger, which fires when twilight ends, is the more suitable tool.

Two claims are worth refusing here. A fixed offset is not a promise that the house is dark, and a fixed seasonal offset is not a promise that it tracks twilight. The horizon, the weather, the season, and the room all sit between the sun event and how the room feels.

A completion check before you leave it running

The workflow is complete when four things are true:

1. The trigger you edited is the trigger the saved automation actually uses, and you can name whether it stores direction as a sign or as an offset type.
2. A trace of a real event shows the run starting at the time the table predicts, not at the event time it replaced.
3. The notification text describes the direction correctly, so a future reader of the automation cannot misread 17:45 as 19:15.
4. The home location and time zone are the ones you expect, and either the offset is the right tool for the goal or you have switched to an elevation threshold on purpose.

Until then, keep the test automation limited to notifications. Fire no locks, heaters, or other physical actions while you are still checking arithmetic, and restore your real automation once the timing is confirmed.

What to remember

A negative Home Assistant sun offset always fires before the event and a positive one always fires after it, in seconds or HH:MM:SS. The classic sun trigger and the newer dedicated triggers express that direction differently, so check which shape you are editing. When the clock looks wrong, check the home location and time zone first, then the direction the saved trigger actually encodes, then the UTC attributes, and only then decide whether a fixed offset or an elevation threshold matches the result you actually want.