Fair winter: is your heating getting better?

What it needs

• An energy meter: a tag of type Counter. Make your energy sensor one under Tags, in its Meter section. A Home Assistant sensor becomes one by itself only once its state class arrives with its readings, as Home Assistant's built-in InfluxDB integration sends it and the Tag Historian integration does from version 2026.12.0, or once its hourly statistics are imported as a total_increasing sensor's (see Meters in the Home Assistant guide). Its use per day is the same figure Trends draws as daily bars.
• The outdoor temperature: SMHI's hourly temperature at the station nearest the account's place (see the outdoor weather), or one of your own tags. An Admin chooses under Settings, Account Information, Outdoor temperature for Fair winter: a tag in °C, or with no unit, that is not a meter. Your own thermometer is read instead of SMHI's for every day once it is chosen: days from before its first reading (or the earliest hours imported for it) then have no temperature, so the winters before it lack their weather and say Too few whole days, and a measure needs the thermometer's heating days before it. Choose it once it has measured the winters you want to compare, or keep SMHI's station until then. When the place is first set, SMHI's ten years at the station take a few minutes to fetch: until then the page says so, and the winters lack most of their weather.
• Some cold days: at least 30 days of heating, with 100 degree-days between them, before the house can be told apart from its weather.

Days and months are the account's own, in its time zone (Settings, Account Information). Open Fair winter in the Explorer's menu and choose the meter. It looks at whole days up to yesterday, from the meter's first day, at most ten years back.

Degree-days (graddagar)

A day's degree-days are how far its mean outdoor temperature lies below a base temperature: a day averaging -3 °C has 20 degree-days below 17 °C, a day at 17 °C or warmer has none. Every day of the year is counted the same way. Counted below 17 °C, they are shown for reference as degree-days below 17 °C; the heating part is divided by degree-days below the house's own balance point instead.

These are not SMHI's Graddagar. SMHI's product adds a heating limit (eldningsgräns) that varies by month through spring, summer and autumn, to allow for the sun's warmth. Fair winter instead finds your own house's heating limit from its meter - its balance point, below.

A day's mean temperature is the mean of SMHI's hourly readings, or your thermometer's mean over the day. It needs all but four of the day's hours: 20 of 24, and 19 of 23 or 21 of 25 on the days the clocks change. A day short of that has no temperature, and is left out.

The house: its balance point and baseload

On a day that needs heating, a house uses a fixed amount for everything that is not heating - hot water, lights, the fridge: its baseload - and an amount for every degree-day below its balance point, the outdoor temperature below which it heats. Fair winter finds both from your own days, as the straight line that fits them best (least squares): it tries every balance point from 10 to 20 °C in half degrees and keeps the one whose line fits the heating days best. That is the house's energy signature, said in one sentence on the page:

Every amount is in your meter's own unit: kWh here, MWh or m³ for a meter that counts in those.

The line is fitted through the last 365 days up to the last day it can use - those of them that have both a whole day of the meter and of the temperature - or through every such day in the window, when that year has too few cold days; and only through the days that need heating: a July spent away does not pull the baseload down. Every month, the winters before too, is worked out with this line: today's baseload and balance point are taken off a January five years ago as well. A day whose energy is partly worked out - the meter reset or was replaced, or readings are missing before it - is shown but never fitted.

The heating part per degree-day

A month's heating part (uppvärmningsdel) is its energy less the baseload of its days. Taken over its whole days alone - those with both the meter and the temperature, and an energy that was read rather than worked out - and divided by their degree-days below the balance point, it is the heating part per degree-day: what the house needed for each degree of cold. That is the figure to compare.

Energy divided by degree-days, without taking the baseload out first, is not: the baseload is the same in a mild month and a cold one, but divided by fewer degree-days in the mild one, so a mild January looks worse than a cold one for the same house.

Under each month's bar the page shows the figure, or why there is none:

• Too little heating: a month in which heating is less than half the energy, or a whole month with fewer than 100 degree-days below the balance point - too little heating to compare: summer, often May and September too, and a summer month still under way.
• Too few whole days: fewer than four in five of the month's days have a whole day of both the meter and the temperature, with the meter's use read rather than worked out (a reset, a replacement or a gap). A month that has only just started, whose days heat but have had fewer than 100 degree-days so far, says Too few days so far.
• Needs more cold days: no energy signature yet. Energy and degree-days are shown side by side until there is one, and a month's bar is its energy in one colour, not yet split into heating and baseload. Without any outdoor temperature the month says No outdoor temperatureinstead, and while SMHI's years are being fetched Waiting for SMHI: more cold days would not help with either.

A month without the figure shows its degree-days below 17 °C under the reason, marked DD, beside the energy its bar draws.

January against January

Every January in the meter's history, with its energy, its degree-days below 17 °C and its heating part per degree-day, and the change from the last January before it that had one. For a house that has not changed, the change is close to zero whether the January was mild or cold. A lower figure means the house needed less heat per degree of cold. After a change to the baseload itself - a heat pump that also makes the hot water - the earlier Januaries still have today's baseload taken off, so part of their change is that.

Did it work?

Note what you did as a Measure taken - on the meter's chart in Trends, or with Add a measure on the Fair winter page - about the meter or the whole account. Fair winter then compares the heating days since with what the house would have used for the same weather:

1. The line is fitted through the 365 days before the measure (or since the measure before it, if that is later). It needs at least 30 heating days, with 100 degree-days between them, of whole readings there.
2. For every heating day since (up to 365, or up to the next measure), it predicts what the house would have used then, and adds up how much less - or more - it did.
3. It needs at least 14 heating days, with 100 degree-days between them, before it says anything.

The answer is Saved about 10% or Used about 5% more, each with a margin, or Not sure yet. The margin is two standard errors of the difference, widened because the house's ups and downs come in runs - a cold spell is several cold days - so the days are fewer independent facts than there are days. It says Not sure yet when the difference is within that margin; more cold days since may tell, until the year since the measure (or the days up to the next one) is over. When the line through the year before misses its heating days by more than 25% of the house's mean use on them (CV(RMSE)), that year is too uneven to judge by: the card says Can't tell from the year before, and more days since will not change that. Before enough cold days have passed it says Waiting for cold days, and without enough of them in the year before, Nothing to compare with. Days of a measure that took a while (a note that lasted) are in neither period.

An approximation

Fair winter describes the house by a straight line: a baseload plus an amount per degree-day. Wind, sun, how many people are home and how warm you keep it are not in it, and they move the figures too. That is why a verdict comes with a margin, and why a change of a few percent in one month is not a finding.

It is not normal-year corrected yet: it does not say what a year would have used in a normal year's weather (normalårskorrigering). Comparing the heating part per degree-day already takes this year's weather out; normal-year correction is planned for a later release.

Plans and limits

Fair winter is on every plan. It is worked out when you open it, from up to ten years of hourly history, so an account can have it worked out 30 times an hour, in at most 5 minutes of the service's time together: a new one starts only while a whole minute of them is left, the longest one may take. Opening the same meter again within the hour is usually answered from what was just worked out, and then does not count; a new note, earlier hours imported or the next whole day works it out anew. It stores no new readings and uses none of your tags.

SMHI's data

The temperature is SMHI's open data under the CC BY 4.0 licence. The page credits it as Source: SMHI (CC BY 4.0), station X, values placed on the UTC hour, naming the station. Neither your meter nor anything else about your account is sent to SMHI.

Through the API

GET /api/winter/{tag}, with any key that may read measurements, answers the days, the months, the Januaries, the signature and the measures with their verdicts, in the account's time zone. from and to narrow it to whole days (2026-01-01, the end not included), at most ten years; an earlier from is refused with 400. A tag that is not a meter is refused with not_a_meter. Past the hourly limits the answer is 429; while the service is busy (readings coming in, other requests being worked out, or the same answer still being worked out for an earlier request), when a window took too long to read a moment ago, or when the hours cannot be read just now, it is 503 with code busy. Both carry Retry-After. A request whose client leaves once its reading has begun is still worked out and kept, unless the account asks for another meter or window meanwhile and nobody asks for this one, so asking again once it is done is answered from it. Asked again while it is still being worked out, it is waited for, up to half a minute, rather than refused for the hourly limits.