Why does my sunset automation fire at the wrong time after 2026.11?
- YAML trigger with an offset but no
offset_type(most likely): the 2026.11 release notes say sun triggers and thecalendar.event_startedandcalendar.event_endedtriggers used to default tooffset_type: before, so a positive offset fired before the event. Now the sign decides: negative fires before, positive fires after. - Calendar triggers written the same way: the change covers calendar event triggers as well as sun triggers, so a "10 minutes before the meeting" automation can shift too.
- A different cause altogether: a wrong time zone, a changed home location, or a template condition can also move a sunset trigger. Rule these out if the sign flip does not help.
The release notes call this an edge case, because the UI editor always wrote offset_type. Automations you built by clicking through the editor are not affected. It bites hand-written YAML, and blueprints or snippets copied from forums years ago.
Fix 1: Flip the sign of the offset
This is the fix the release notes give: if you wrote one of these triggers in YAML with an offset but without offset_type, flip the sign of the offset. Open Settings → Automations & scenes, choose the automation, then the three-dot menu and Edit in YAML. Find any platform: sun (or trigger: sun) block that has offset and no offset_type.
The rule of thumb under the new behaviour: you want the light on 30 minutes before sunset, use offset: "-00:30:00". You want it 30 minutes after sunset, use offset: "00:30:00". Under the old default the maths was the other way round, which is why a plain sign flip restores your original timing. Save the automation.
How to tell it worked: open the automation's Traces page the next evening and compare the trigger time with the sunset time shown on the sun.sun entity's next_setting attribute in Developer tools → States.
Fix 2: Check calendar triggers too
Search your configuration for calendar triggers. If a calendar.event_started or calendar.event_ended trigger has an offset and no offset_type, apply the same sign flip. Typical casualties are bin-day reminders and "get the heating on before guests arrive" automations that key off a calendar event.
How to tell it worked: create a test calendar event a few minutes ahead and watch whether the automation fires on the side of the event you expect. If you want a reminder routine to build on, see our bin collection reminders guide.
Fix 3: Find every affected automation in one pass
If you have more than a handful of automations, do not hunt by eye. Open the File editor or Studio Code Server app and search automations.yaml, any packages/ folder and your blueprints for offset. Every hit that sits under a sun or calendar trigger and has no offset_type beside it needs checking. Hits under a condition or inside a for or delay are unrelated.
It is worth adding an explicit offset_type while you are there so the intent is written down. Neither the release notes nor this guide's sources document every valid value, so check the current automation trigger documentation for the exact spelling before you rely on it.
How to tell it worked: after editing, run Developer tools → YAML → Check configuration, then reload automations.
Fix 4: Rule out time zone and location
If flipping the sign made no difference, the trigger itself may be fine. Check Settings → System → General for the time zone and the home location, because sunset is calculated from them. A wrong time zone shifts every sun-based trigger by an hour, which is easy to confuse with an offset problem. Our Christmas lights automation guide and the motion night light guide both lean on sun triggers, so they are good places to sanity-check a corrected automation.
How do you stop it coming back?
Three habits help. First, take a backup before every major release, so a surprise is reversible. Second, read the "Backward-incompatible changes" section of the release notes before updating, not after. Third, when you write sun or calendar triggers in YAML, always include offset_type so the behaviour does not depend on a default. While you are tidying after this update, the entity naming change deserves a check too.
What if the automation still misfires?
Open the trace for a run that fired at the wrong time. The trace shows the trigger that matched and the exact timestamp, which tells you whether the sun trigger, a second trigger in the same automation, or a condition is responsible. Many sunset automations carry two triggers, such as a sun trigger plus a time fallback, and the fallback can be the one firing at the odd hour.







