Heating and cooling degree days

Who it’s for

Anyone who has to explain a consumption number to somebody who was not there for the weather. An energy manager whose January bill doubled, a facility team asked whether the new controls actually saved anything, an ESG report that compares this year with last, a landlord recharging heat across a portfolio. They all need the same thing first: a number for how hard the weather pushed, so the rest of the change can be attributed to something else.

What it does

A September on one site, read from an outdoor probe: the month comes to 139 heating degree days and 9.0 cooling degree days against bases of 15.5 and 22 °C. Underneath each total the card says what that means per day — the outside air sat 4.6 °C below the heating base on an average day — and the strip shows where it happened: a cold first week, a warm spell around the 12th that pushes red bars below the line, then cooling off again.

• Turns a temperature series into the one number that makes two periods comparable, so consumption can be divided by it rather than argued about.
• Counts every reading rather than only the daily high and low. A day that sits at 10 °C until noon and 21 °C after it comes to 2.5 heating degree days by the readings and exactly zero by the high and low method, because the midpoint of 10 and 21 is the base itself.
• Keeps heating and cooling apart, each against its own base, because the same mild week helps one bill and not the other.
• Shows the shape of the period, not just its total, with a bar per day above and below the line and the exact values on hover.
• Says how much of the period it actually counted, and never invents weather across a gap: when the probe goes quiet for longer than it normally waits between readings, that time is left out rather than held at the last value.
• Produces the denominator only. Dividing consumption by degree days is the next step and belongs in a calculated field or a widget of its own, and nothing here fetches weather — it reads the key you point it at.

How to set up

The widget takes one entity and one temperature key, and everything else is the two base temperatures your contract or your benchmark uses.

Data keys

• One outdoor temperature key — Timeseries. The air temperature outside the building, from a probe on the site or a weather feed written into ThingsBoard as telemetry. Its units are what every base and every total is expressed in, so set °C or °F on the key and the card labels itself; a key with no units reads as plain degree days. Indoor temperature does not work here: it is held near a setpoint by the very system being measured, so it carries no weather. With fewer than two readings in the window the card shows its no-data message.

Degree days

• What to count — Both by default. Heating counts how far the air stayed below the heating base, cooling how far above the cooling one. A site that only heats can drop the half it does not use, and the strip then draws in one direction.
• Heating base — 15.5 by default, and only shown when heating is counted. The outside temperature below which the building starts heating, in the unit of the key. 15.5 °C is the usual European value and 65 °F the American one; a well insulated building sits lower.
• Cooling base — 22 by default, and only shown when cooling is counted. The temperature above which the building starts cooling. The gap between the two bases is the weather the building rides out on its own.
• How a day is measured — From every reading by default, which uses the area between the base and the curve and is the accurate answer whenever the probe reports through the day. From the daily high and low is the classic method that published tables are built on, so choose it when the total has to line up with an external dataset; it needs at least two readings in a day and skips days that have fewer.

How to customize

• To drop the strip and keep only the totals — turn off Show the day by day strip, which suits a small tile in a row of cards.
• To stop the card reacting to the mouse — turn off Show values on hover. Worth doing on a wall display, where nobody is holding a mouse.
• To match the bars to your palette — set Heating bars and Cooling bars. Each direction is scaled to its own peak, so a mild cooling season stays visible next to a cold snap and the colors tell the two apart.
• To keep one size at any card size — turn off Scale to fit the card. It is on by default and grows or shrinks the totals, the strip and the caption together so the same widget reads on a phone and on a wall display.
• To stop the card naming its own weather station — turn off Show the key label, worth doing when the widget title already says it.
• To match the card to the dashboard — set Total font and Total color.

Tips

• Compare like with like: divide the period’s consumption by the heating total and the result is kWh per degree day, which is the number that actually says whether efficiency moved. A month that used more energy at a lower kWh per degree day was a colder month, not a worse one.
• Pick the base your benchmark uses, not the one that looks right. Degree days at 15.5 and at 18 are different numbers, and comparing a site against a published dataset only works when both sides use the same base.
• Widen the time window and the strip regroups itself: a bar per day up to about six weeks, then a bar per week, then a bar per month past two hundred days. The totals never change, only the resolution of the picture, and the caption says which one is on screen.
• Hover a bar to read the day out exactly. On a long window that is how you find which week carried the cold, without reading the underlying chart.
• Keep the hourly resolution if you have it. The reading by reading method is what separates a day that crossed the base at noon from a day that sat on it, and aggregating to one point per day throws exactly that away.