Smart Home Assistant

Home Assistant Sunset Offset Firing Late After 2026.11? The Fix

SepehrBy Sepehr· 9 November 2026· Updated 9 November 2026· 4 min read
✓ Independent — no paid placements✓ UK-tested in real homes✓ Cited sources
Silhouetted rooftops of a row of houses under a deep red sunset sky

Key takeaways

  • After Home Assistant 2026.11, YAML sun triggers with an offset but no offset_type follow the offset's sign, so old sunset automations can fire late.
  • The official fix is to flip the sign of the offset in each affected YAML trigger, then confirm the time in the automation trace.
  • Triggers built in the UI editor are not affected, because the editor always wrote offset_type.
  • Calendar event_started and event_ended triggers changed in the same way, so check those alongside sun triggers.
  • Searching your YAML for the word offset finds every candidate; take a backup before major updates so surprises are reversible.
On this page[tap to expand]

A Home Assistant sunset offset automation firing at the wrong time after 2026.11 is caused by a changed default: YAML sun and calendar triggers with an offset but no offset_type now follow the offset's sign. Flip the sign of the offset and the trigger fires when it used to.

The change landed in the 2026.11 release, and it is easy to miss because nothing errors. Your "lights on before sunset" automation simply starts firing late, and in a UK November that means walking into a dark room. This guide ranks the likely causes and gives a fix for each, most probable first.

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 the calendar.event_started and calendar.event_ended triggers used to default to offset_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.

Buy the picks in this guide

Recommended for Home Automation

See all devices →

Frequently asked questions

Why does my Home Assistant sunset automation fire late after updating to 2026.11?
Your automation is most likely a YAML sun trigger with an offset but no offset_type. According to the 2026.11 release notes, those triggers used to default to offset_type before, so a positive offset fired before sunset. The default has gone and the sign of the offset now decides: negative fires before the event, positive fires after. A trigger such as sunset with an offset of 00:30:00 that used to fire half an hour early therefore now fires half an hour late. The release notes say to flip the sign of the offset in affected YAML. Automations built in the UI editor are not affected because it always wrote offset_type. Check one automation first, confirm in its trace, then work through the rest of your configuration.
Do UI-built automations need fixing after the 2026.11 offset change?
Almost certainly not. The 2026.11 release notes describe the change as an edge case and state that the UI always wrote offset_type, so triggers created in the automation editor are not affected. The problem is limited to automations written by hand in YAML, plus blueprints, packages or forum snippets that include an offset without offset_type. Because nothing shows an error, the sensible approach is a quick search of your YAML files for the word offset, then checking only the hits that sit under a sun or calendar trigger. If your automations were all created with the visual editor you can usually move on, but a glance at the trace of your sunset automation the first evening after updating costs nothing and confirms the timing.
Does the sun offset change also affect calendar triggers in Home Assistant?
Yes. The 2026.11 release notes list the calendar.event_started and calendar.event_ended triggers alongside the sun triggers: they no longer default to offset_type before, and the sign of the offset decides whether they fire before or after the event. If you have a YAML calendar trigger with an offset and no offset_type, such as a reminder set to fire ten minutes ahead of an event, it can now fire on the opposite side of the event. The fix is the same as for sun triggers: flip the sign of the offset, then test with a calendar event a few minutes away. Triggers built in the UI editor include offset_type, so they are unaffected and keep their original timing.

Sources

Sources verified 2026-11-09

  1. Home Assistant — 2026.11 release notes: Backward-incompatible changes (Calendar and Sun)
  2. Home Assistant — Automation trigger documentation
›How we researched this

Claims in this article are checked against primary sources — manufacturer specifications, official documentation, Which? research, Ofgem guidance, or gov.uk — rather than forum threads or video reviews. Where the author has direct hands-on experience with a product (most Home Assistant, Zigbee, and home-networking gear is running in his own homelab), that is stated explicitly in the text.

For categories outside that personal setup — such as boilers, heat pumps, and other areas that are traditionally a heating engineer's domain — verdicts are built from cross-referenced manufacturer data, published lab results, and vetted expert and owner reviews rather than a claim of personal hands-on testing. See the editorial policy for the full methodology.

Sepehr

Written by

Sepehr

10+ years hands-on with Home Assistant & networking · Research-backed elsewhere · No brand deals

Smart home specialist with 10+ years running a self-hosted Home Assistant setup — Zigbee2MQTT, Frigate NVR, and local-first automations. Independent coverage for UK homes, no brand deals.

LinkedIn →

Citing this page? Please use a dofollow link back to the original article — it helps us keep the data on this page accurate and up to date.

Related reading