Solstice Season – Accurate Seasonal & Daylight Data for Home Assistant

moerk-o · December 10, 2025, 7:51pm

I’d like to introduce my new custom integration Solstice Season.
It’s inspired by the built-in Season integration, but I wanted something more detailed — precise timestamps, daylight trends, and information that actually reflects how the year progresses. So I built it.

GitHub: GitHub - moerk-o/ha-solstice_season: Home Assistant integration providing sensors for current season, start of the next four seasons, and daylight trend. Supports astronomical and meteorological calculation modes for both hemispheres.

What Solstice Season does

Calculates precise solstice and equinox times
Shows how many days remain until the next seasonal change
Detects whether the days are currently getting longer or shorter
Indicates when that trend will shift
Supports astronomical and meteorological seasons
Runs fully offline, no APIs or cloud required

Why it’s interesting

Solstice Season gives Home Assistant a more detailed picture of the yearly cycle, making it easier to create automations and visualizations that respond to real seasonal changes — from lighting moods to ambient displays, small status indicators, garden logic, and anything else that benefits from knowing how the season is actually progressing.

HappyCadaver · December 11, 2025, 3:04am

Environmental information and details are always interesting to me, thanks for making this available. It’s amazing to me how much folk don’t realise how much this kind of information (read: data) affects their lives day over day, month over nonth, year over year.

Now to figure out how to combine this with the HACS Moon Astro integration to get a full picture.

MattB314 · December 11, 2025, 11:47am

Nice! I love this kind of data.

moerk-o · December 17, 2025, 8:57am

Thanks Guys, I’m happy you like it!

duceduc · December 20, 2025, 4:26am

Hi. I have installed the integration a few days ago; I am monitoring the accuracy.

Today is Sat, Dec 20. The integration is saying season change will be in 2 days on Sun, Dec 21. The days remaining should read 1 day. My initial setup is for the Northern Hemisphere and I set the mode to astronomical as you can see in the 2nd screenshot.

iamjosh · December 20, 2025, 5:11am

I’ll bet the sensors update infrequently since there really isn’t a reason to have them constantly updating. Maybe once or twice a day?

The sensors probably haven’t updated since your date rolled over.

Edit: looks like they update once per day.

UPDATE_INTERVAL = timedelta(days=1)

github.com/moerk-o/ha-solstice_season

custom_components/solstice_season/coordinator.py

f262fffb5

"""DataUpdateCoordinator for Solstice Season integration."""

from __future__ import annotations

import logging
from datetime import timedelta

from homeassistant.config_entries import ConfigEntry
from homeassistant.core import HomeAssistant
from homeassistant.helpers.update_coordinator import DataUpdateCoordinator
from homeassistant.util import dt as dt_util

from .calculations import SeasonData, calculate_season_data
from .const import CONF_HEMISPHERE, CONF_MODE, DOMAIN

_LOGGER = logging.getLogger(__name__)

# Update once per day
UPDATE_INTERVAL = timedelta(days=1)

This file has been truncated. show original

moerk-o · December 20, 2025, 7:17pm

Hi @duceduc,

@iamjosh is right - the 24h update interval starts from when Home Assistant (or the integration) boots, not from midnight. That’s why the value can be “off” for part of the day.

As a workaround, you can reload the integration (Settings → Devices & Services → Solstice Season → ⋮ → Reload) and the values should update immediately.

I’ve already created an issue for this: #6 - Update at midnight instead of 24h interval

Not sure yet when exactly the fix will land, but it will be included in the next release. The plan is to refresh shortly after midnight so the values are always accurate for the current day.

moerk-o · December 20, 2025, 7:46pm

Your Feedback wanted: Are the *_start attributes redundant?

I started a discussion on GitHub about this, but realized that’s probably not the best place to reach actual users. So here we go:

I’m reviewing some design decisions and would love your input.

Background

The current_season sensor currently has these attributes:

spring_start, summer_start, autumn_start, winter_start - showing the start date of each season in the current calendar year

There are also dedicated timestamp sensors for each event:

spring_equinox, summer_solstice, autumn_equinox, winter_solstice - showing the next occurrence of each event

The Question

Are the *_start attributes redundant?

At first glance they seem to serve different purposes:

Sensors: “When is the next spring equinox?” → shows next occurrence, jumps to next year after the event
Attributes: “When is spring this year?” → always shows current calendar year

But what’s the actual use case for “season dates of the current calendar year”?

The Problem That Revealed This

A user requested a way to calculate season progress. They discovered that winter_start becomes useless in January - it shows December 2025 when you’re actually in the winter that started December 2024. The attribute jumps to the next calendar year’s value.

This means the attributes don’t answer the question “when did the current season start?” - they answer “when does this season start in this calendar year?” which is a subtle but important difference.

Options to Consider

Keep as-is - Accept that attributes show “this calendar year” and sensors show “next occurrence”. The new season_age attribute fills the gap for the “current running season” use case.
Remove the attributes - They’re arguably redundant since you can get the same info from the timestamp sensors (just formatted differently). Would be a breaking change.
Change attribute behavior - Make them show “most recent occurrence” instead of “current calendar year”. This would be more useful but also a breaking change in behavior.

Current Decision

For now, I added the season_age attribute which solves the immediate use case (season progress calculation) without changing existing behavior.

This is to track the broader question of whether the *_start attributes need rethinking in a future version.

What do you think? Any feedback appreciated - even “I don’t use these” or “please don’t change anything” is helpful.

The GitHub issue for tracking: #4 - Review: Are *_start attributes redundant?

duceduc · December 20, 2025, 11:39pm

Hello. Today is Sun, Dec 21. The season should have changed and the countdown for Spring should appears.

Reloading the integration does nothing to change the values. I can see all the values have been updated because all the sensors says updated in seconds ago. However, the 16 hours still remains as 16 hours. I also, reloaded the integration yesterday when it was reading as 2 days. It always shows 2 days. Perhaps we need to reboot HA instead??

Additional observations:

I’ve done a reboot of HA. Not restart. No changes.
Since it is showing hours and not days remaining. The hour countdown start 30 min past the hour and not on the hour.

iamjosh · December 21, 2025, 3:00am

I think the time until the season change is correct. The change happens at the same moment around the world, so whatever your local time is at that moment.

The winter solstice is at 15:03 UTC on December 21. That’s officially when the season changes to winter, as well. The season does not change at midnight local time.

iamjosh · December 21, 2025, 3:08am

You could have attributes for both “most recent occurrence” and “next occurrence”.

duceduc · December 21, 2025, 3:54am

I’ve believe you are correct. So from my calculation, the season change will happen at 12:03am local time for me.

I also do believe the default HA season integration will change at the same time as well. Will know when I am woken up from all my air conditioning devices and toilet are set to do its self cleaning with every season change.