If the solar forecast line in Home Assistant's Energy dashboard always seemed to run an hour behind your panels, it was not your imagination. A fix by Tagliax, change #188790, was merged into Home Assistant's development branch on 26 October 2026, so it is lined up for the 2026.11 release. It moves every Forecast.Solar energy value to the start of the period it describes.
Where the hour went
The Forecast.Solar API keys each watt_hours_period value by the end of its period. Its documentation says the value is always for the period from the previous timestamp to the one in the key. Home Assistant passed those keys on unchanged, and both places that use them read them as the start of the period.
The result:
- the Energy dashboard drew the forecast one hour late;
- the
get_forecastaction returned each value one period late, although its own documentation sayswh_periodis the energy produced during the period that starts at that time.
The author shows it with data from their own installation for 24 October: the key 13:00 UTC holds 965 Wh, the peak of the day, which is the energy produced between 12:00 and 13:00. The dashboard drew it between 13:00 and 14:00. The first key of each day is sunrise with 0 Wh and the last one is sunset with a few Wh, which only makes sense if the values belong to the period that ends there.
How big the error was
The author compared the forecast with the energy calculated from the watts values, the instantaneous power at each key, over two days hour by hour. For Rome the total error dropped from 3762 Wh to 7 Wh. For Sydney it fell from 10537 Wh to 6 Wh with ISO 8601 timestamps, and from 7000 Wh to 1991 Wh with time=utc. The rest of that gap comes from the 23:00 to 00:00 UTC hours, which the API does not return.
After the fix the forecast line in the Energy dashboard drops to zero together with the last production bar, instead of an hour after sunset.
What changes for automations
The get_forecast action changes its output, which matters if a script or template reads it:
- with
rawresolution the last timestamp of the day no longer has awh_periodvalue, because no period starts at sunset; - with
hourlyresolution each hour now holds its own energy, not the energy of the hour before.
The artificial zero that the API puts at UTC midnight is still filtered out. It is not a real period, so the period before it gets no value.
What is not fixed yet
The energy_current_hour and energy_next_hour sensors have the same problem, but it sits in the forecast_solar library. A separate change, home-assistant-libs/forecast_solar #465, opened on 26 October, is meant to fix it and is still open. The Home Assistant fix does not depend on it, and watts values stay as they are.