Quick Summary (TL;DR)
Outdoor temperature is a useful predictor of home heating demand, but it is not a thermostat. A practical Home Assistant forecast starts with measured heating energy, outside temperature, indoor setpoint and a time stamp. Fit a simple heat-loss relationship, test it on days the model has not seen, and account for building thermal inertia before attempting any automated preheating. Keep the original boiler or heat-pump controller responsible for safety, minimum temperatures and equipment protection.
For a first version, use daily heating degree days and daily delivered heat or heating-only electricity. For a more responsive version, estimate the time delay between outdoor conditions and the indoor or heating-system response. Do not confuse electrical consumption with delivered heat on a heat pump, and do not treat a sunny, windy or occupancy-heavy day as identical to an otherwise similar day.
What does a heating-demand forecast actually predict?
There are three distinct outputs: heat loss through the building envelope, heating energy supplied over a period, and electricity or fuel purchased to provide that heat. The three are related, but their numerical values differ. A heat pump might deliver 30 kWh of heat using 10 kWh of electricity at an average COP of 3; a boiler has its own efficiency and measurement uncertainties. A forecast must state which quantity it estimates.
For most smart homes, daily space-heating energy in kWh is the most useful initial target. It supports tariff comparisons, rough next-day budgeting and trend detection. An hourly forecast is possible, but occupancy, sunshine, wind, hot-water reheating, defrost events and thermostat setbacks become proportionally more important.
| Target | Measurement | Best use | Main caveat |
|---|---|---|---|
| Space-heating heat (kWh) | Calibrated heat meter or manufacturer heat estimate | Physical building-load model | Manufacturer estimates may be approximate |
| Heat-pump electricity (kWh) | Dedicated electric meter | Tariff cost forecasting | COP varies with weather and flow temperature |
| Boiler gas input (kWh) | Gas meterAliExpress price with suitable data access | Fuel consumption forecast | Includes efficiency and sometimes hot water |
| Heating runtime (minutes) | Reliable burner/compressor state | Cycle and scheduling patterns | Runtime alone does not measure delivered heat |
The basic physics: heat-loss coefficient and temperature difference
At steady state, heat loss is approximately Q̇ = H × (Tinside − Toutside), where Q̇ is heat loss in watts and H is the whole-building heat-loss coefficient in W/K. H combines transmission through walls, windows, roof and floor with ventilation and infiltration losses. This is a useful engineering simplification, not a substitute for a room-by-room heat-loss assessment when sizing equipment.
Suppose H is 180 W/K, indoor temperature is 20 °C and outdoor temperature is 5 °C. The temperature difference is 15 K, so estimated steady heat loss is 2,700 W. Over 24 hours that is 64.8 kWh of heat before accounting for solar and internal gains, temperature variation, heating setbacks and changes in stored heat. It is not automatically 64.8 kWh of heat-pump electricity.
| Outdoor temperature | Temperature difference at 20 °C inside | Steady heat loss at H = 180 W/K | 24-hour heat at constant conditions |
|---|---|---|---|
| 15 °C | 5 K | 0.90 kW | 21.6 kWh |
| 10 °C | 10 K | 1.80 kW | 43.2 kWh |
| 5 °C | 15 K | 2.70 kW | 64.8 kWh |
| 0 °C | 20 K | 3.60 kW | 86.4 kWh |
| −5 °C | 25 K | 4.50 kW | 108.0 kWh |
The table illustrates the slope of the relationship, not a promise about a particular house. A poorly insulated or draughty building can have a much larger H; a very efficient building can have a substantially smaller one. Solar gains, internal heat and the heating system’s control behaviour explain why measured daily consumption seldom lies exactly on the theoretical line.
Heating degree days: the easiest model to start with
A heating degree day (HDD) represents how far the mean outdoor temperature falls below a chosen base temperature. For a day with mean outdoor temperature Tout, HDD = max(0, Tbase − Tout). Summing daily HDD over a month gives a useful weather-normalisation measure. The base is a balance-point temperature, not necessarily the thermostat setpoint: free heat from people, appliances and sunshine means heating may not be required at an outdoor temperature equal to the indoor target.
For example, at a 15.5 °C base, a day averaging 8 °C contributes 7.5 degree days. At an 18 °C base, the same day contributes 10 degree days. Do not compare slopes from models using different bases without accounting for that change. UK degree-day analyses often use 15.5 °C as a convention, but the best empirical base for an individual home may be different.
Fit a simple model of the form daily heating energy = a + b × HDD. Here b represents sensitivity to weather and a absorbs baseline effects or modelling imperfections. If the result predicts negative heating energy on mild days, clamp it to zero and reconsider the model rather than accepting physically impossible values.
| Day | Mean outdoor temperature | HDD at 15.5 °C base | Measured heating energy |
|---|---|---|---|
| Monday | 12 °C | 3.5 | 19 kWh |
| Tuesday | 9 °C | 6.5 | 29 kWh |
| Wednesday | 6 °C | 9.5 | 40 kWh |
| Thursday | 3 °C | 12.5 | 52 kWh |
| Friday | 10 °C | 5.5 | 25 kWh |
This small example is illustrative, not a statistically adequate training dataset. Real fitting needs weeks or months of representative observations, enough cold and mild days, and separate treatment of unusual events. Do not tune a model until it reproduces five example points perfectly and then assume it will generalise.
Where thermal lag changes the answer
A building stores heat in floors, masonry, plaster, furnishings and water-filled heating circuits. As a result, outdoor temperature may fall immediately while the indoor temperature changes slowly. A wet underfloor-heating slab can respond over several hours; a lightweight radiator-heated room may respond much faster. The relevant lag depends on the house and heating schedule, not simply the radiator or heat-pump brand.
A simple first-order approximation uses a thermal time constant τ. If heating input and outdoor conditions remain fixed, the temperature difference from a new equilibrium tends to shrink approximately as e−t/τ. After one time constant about 37% of the initial difference remains; after three, roughly 5% remains. Actual homes have multiple time constants, intermittent heating and changing gains, so one τ is a compact description rather than a complete simulation.
| Observation | Likely explanation | What to measure | Avoid |
|---|---|---|---|
| Indoor temperature remains stable after outdoor drop | Stored heat and active compensation | Indoor/outdoor trend plus heat input | Assuming sensor is faulty |
| Room overshoots after heating switches off | Residual heat in slab/radiators | Room temperature and valve/heat demand | Rapid repeated setpoint changes |
| Morning warm-up is slow | Emitter temperature or high thermal mass | Heat demand, flow temperature, indoor rise | Aggressive short preheat windows |
| Demand spikes after setback | Recovery of stored heat | Energy during and after recovery | Judging efficiency from one hour |
| Different lag in different rooms | Room mass, solar gain, zoning | Room-specific sensors and demand | One universal offset for all rooms |
Collecting reliable Home Assistant data
Start with the least complicated dependable set of entities: outdoor temperature, representative indoor temperature, heating setpoint, heating on/off or operating mode, and a dedicated heating-energy measurement. Add flow/return temperatures, solar irradiance or weather condition, occupancy and wind only when there is evidence that they improve prediction. More inputs are not inherently better if their history is missing or inaccurate.
Prefer an outdoor sensor shaded from direct sunlight and sheltered appropriately from local heat sources. A weather-service temperature may be sufficient for daily models, but its location and sampling can differ from conditions at your property. Log the source and avoid mixing stations halfway through a training period without recording the change.
Use the Home Assistant Energy Dashboard guide to ensure grid electricity and dedicated heating consumption are not conflated. Our per-appliance energy baselines guide explains why a meter attached to the correct circuit is more valuable than a whole-house total contaminated by cooking, EV charging and other loads.
| Entity | Recommended cadence | Quality check | Purpose |
|---|---|---|---|
| Outdoor air temperature | 5–15 minutes or hourly | No direct sun bias or gaps | Weather driver |
| Indoor temperature | 5–15 minutes | Representative room; calibration | Comfort and thermal response |
| Heating call / run state | Event-driven | Matches equipment operation | Identify heating intervals |
| Heating energy total | Meter native; aggregate hourly/daily | Monotonic total, correct units | Training target |
| Flow/return temperature | 1–5 minutes if available | Correct sensor placement | System response context |
| Tariff price | Supplier interval | Timezone and daylight-saving correct | Cost optimisation |
Prepare the dataset before fitting a model
Aggregate all sources into consistent local-date or UTC intervals and document your choice. For daily forecasts, align the daily outdoor mean and daily energy total to the same 24-hour period. Daylight-saving transitions can create 23-hour or 25-hour local days; a naïve subtraction of midnight totals may still be valid for energy but not for average power. Record missing data explicitly rather than silently replacing it with zero.
Exclude or flag periods with meter resets, sensor dropouts, holiday heating settings, open windows, servicing, hot-water-only operation and unusual solar gain. Where domestic hot water shares a heat pump or boiler, subtract or separately measure it before claiming to predict space heating. If the heat pump provides both functions and no split is available, call the result a combined heating and hot-water consumption model.
A practical modelling workflow: baseline first, sophistication later
Step 1 — Establish a naive benchmark
Predict tomorrow’s heating energy as equal to the mean of the last seven comparable days, or use the most recent day with similar outside temperature. This deliberately simple benchmark is essential: a complex model that cannot beat it on unseen days has little operational value.
Step 2 — Fit a temperature-only or HDD model
Use at least several weeks of varied weather and preferably a substantial heating season. Fit the relationship between HDD and measured space-heating energy. Try a small number of plausible base temperatures and choose the one with the lowest error on a validation period, not on the same observations used for fitting. Keep coefficients and the training period documented.
Step 3 — Add thermal lag only if it improves validation
Try yesterday’s outdoor temperature, a 6–24-hour moving average, or an exponentially weighted outdoor temperature. Alternatively include yesterday’s indoor temperature and heating energy. A weighted average can represent stored heat without requiring a detailed physical simulation. Avoid trying dozens of lags on a tiny dataset: that is a recipe for overfitting.
Step 4 — Test chronologically
Train on earlier weeks and validate on later weeks. Randomly shuffling hourly observations leaks nearly identical neighbouring weather and temperature information into both sets, creating overly optimistic results. Also check performance separately on cold snaps, mild days, weekends and post-setback mornings.
Step 5 — Publish a forecast with uncertainty
Expose predicted heating energy, actual heating energy, forecast error and a confidence range. For example, a prediction of 35 kWh with typical daily absolute error of 6 kWh is more useful than a falsely precise 35.17 kWh. A forecast should state when input data are stale or outside the temperatures seen during training.
| Metric | Meaning | How to use it |
|---|---|---|
| MAE | Mean absolute error in kWh | Typical daily miss in energy units |
| Bias | Mean signed prediction error | Detect systematic over/underprediction |
| MAPE | Percentage error | Use cautiously when actual heat is near zero |
| Cold-day MAE | Error on the coldest days | Safety-relevant forecasting performance |
| Baseline improvement | Error reduction against naive forecast | Proves whether complexity helps |
Worked example: tomorrow’s heating energy and tariff cost
Suppose a validated model gives E = max(0, 2 + 4.0 × HDD) kWh of delivered space heat per day, with HDD computed at a 15.5 °C base. If tomorrow’s forecast mean outdoor temperature is 7 °C, HDD is 8.5 and expected delivered heat is 36 kWh. If the heat pump’s expected daily average COP is 3.0, estimated electrical input is 12 kWh. At a flat 25 p/kWh that would be £3.00. These numbers are illustrative and do not include standing charges.
If a colder day has a lower COP, applying the same value of 3.0 will understate electricity. Likewise, tariff cost is not necessarily 12 kWh multiplied by the cheapest half-hour price: the heating system may not be able to shift all demand into that period without comfort loss or excessive flow temperatures. Model the heating load first, then the achievable schedule and system efficiency.
| Quantity | Example | Calculation |
|---|---|---|
| Mean outdoor temperature | 7 °C | Forecast input |
| Heating degree days | 8.5 | 15.5 − 7 |
| Delivered heat | 36 kWh | 2 + 4 × 8.5 |
| Electricity at COP 3.0 | 12 kWh | 36 ÷ 3 |
| Cost at 25 p/kWh | £3.00 | 12 × £0.25 |
| Cost at 35 p/kWh | £4.20 | 12 × £0.35 |
Home Assistant implementation: sensors, helpers and dashboards
The simplest robust architecture calculates HDD and predicted energy outside the heating control loop, then publishes the forecast to Home Assistant as a sensor. A Python notebook, local script or another analytics process can fit the coefficients; Home Assistant can display them and use them for advisory notifications. Keep the calculation distinct from safety-critical boiler and heat-pump operation.
For a static illustrative model, create a template sensor using a configured outdoor temperature entity. Replace the entity ID and coefficients with measured, validated values; the snippet is not a calibrated forecast for your property. A daily mean temperature is preferable for daily energy forecasting, so an instantaneous sensor is useful mainly for demonstration or a provisional estimate.
template:
- sensor:
- name: "Heating HDD Estimate"
unique_id: heating_hdd_estimate
unit_of_measurement: "°C·day"
state: >
{% set t = states('sensor.outdoor_temperature') | float(none) %}
{{ [0, 15.5 - t] | max | round(2) if t is not none else none }}
- name: "Heating Energy Estimate"
unique_id: heating_energy_estimate
unit_of_measurement: "kWh"
state: >
{% set hdd = states('sensor.heating_hdd_estimate') | float(none) %}
{{ [0, 2 + 4 * hdd] | max | round(1) if hdd is not none else none }}The example intentionally returns unavailable when its source is missing rather than inventing a zero-degree reading. It estimates a day’s energy from the current outside temperature, so label it as a provisional indicator. To make a real next-day forecast, use a forecast daily mean temperature from a weather source whose data-access method and forecast attributes are supported by your installed Home Assistant version, and compute the sensor after that forecast is retrieved.
For zoned systems, aggregate demand from room controllers carefully. An ESP32 multi-zone heating controller can expose zone calls and temperatures, but those are supervisory observations rather than proof of delivered heat. Where a compatible boiler exposes OpenTherm telemetry, our ESP32 OpenTherm gateway guide discusses the data path; do not replace manufacturer protection or commissioning logic with a predictive automation.
Should Home Assistant preheat before a cheap tariff ends?
Only after the model demonstrates repeatable performance. Preheating can shift energy into a cheaper period, but it may raise average indoor temperature, increase heat loss and force a heat pump to run at a higher flow temperature, reducing COP. The right comparison is total cost and comfort over a full day, not merely whether the heating switched on during the cheap period.
Begin with advisory recommendations. If automating, set bounded indoor temperature limits, a maximum preheat duration, minimum equipment run/off times as specified by the manufacturer, and a fallback to the original thermostat schedule whenever weather, occupancy or energy measurements are unavailable. Maintain independent frost protection and hot-water hygiene schedules.
| Control choice | Potential benefit | Risk or limitation | Recommended starting point |
|---|---|---|---|
| Weather-compensated native control | Continuous efficient operation | Manufacturer-specific setup | Prefer when supported |
| Small scheduled preheat | Move some demand to cheaper tariff | Overshoot and higher losses | Pilot with modest limits |
| Deep overnight setback | Reduce heat during absence | Large morning recovery | Test measured daily cost |
| Aggressive half-hour cycling | Apparent tariff optimisation | Cycling and comfort penalties | Avoid |
| Forecast-only dashboard | Visibility without control risk | No automatic savings | Best first deployment |
Common reasons heating predictions fail
Wrong energy boundary: whole-house electricity includes cooking, EV charging and lighting. Hot-water contamination: a cylinder reheating event appears as space-heating demand. Thermostat schedule changes: a new setback policy shifts energy between days. Solar gains: south-facing rooms can need far less heat on bright winter days. Wind and infiltration: cold windy days may exceed the model’s prediction. Defrost and auxiliary heat: heat-pump electrical input can rise without equivalent delivered space heat. Thermal lag: today’s consumption partly reflects yesterday’s weather.
Another frequent mistake is using indoor thermostat temperature as if it were the building-wide average. A sensor next to a radiator, window or sunny wall can distort both the fitted lag and apparent heat-loss coefficient. Consider a representative room sensor and preserve the thermostat’s original control function.
Buying and instrumentation priorities
| Priority | Hardware or data source | Why it matters | Purchase caution |
|---|---|---|---|
| 1 | Dedicated heating energy meterAliExpress price | Reliable target data | Correct circuit and professional installation |
| 2 | Representative outdoor sensor | Consistent weather signal | Shield from direct sun and heat |
| 3 | Indoor temperature sensorAliExpress price | Thermal response and comfort | Placement and calibration |
| 4 | Boiler/heat-pump gateway | Runtime, flow and demand states | Verify model-specific compatibility |
| 5 | Room/zone sensors | Identify uneven response | More data may increase complexity |
| 6 | Tariff feed | Estimate cost-shifting value | Confirm billing interval and timezone |
Before buying a gateway, check whether the heating appliance exposes local data, whether the vendor permits the requested read-only measurements and whether a certified installer is needed. A weather sensor and existing meter history may be sufficient for the first model; purchasing a complete zoning retrofit purely to fit a temperature regression is rarely justified.
Advanced guide: turn a simple forecast into a dependable heating model
A useful heating model is not necessarily the one with the most variables or the lowest training-set error. It is the model whose meaning, measurement boundary, failure modes and future accuracy can be explained to the person paying for and operating the system. This expanded guide develops the original heating-degree-day workflow into a repeatable engineering process: survey the installation, decide what quantity is being predicted, identify heat loss and thermal storage, align time-series data, test unseen periods, and only then make price-aware decisions.
Home Assistant is an excellent place to collect indoor temperatures, energy readings, climate schedules and equipment states. It is not automatically a statistically valid forecasting platform. When the modelling becomes more complex, run it in a local Python notebook, a maintained data service or an equivalent analytics tool, then publish the forecast back to Home Assistant for display. Keep the boiler, heat pump and zone controllers responsible for their own protection and basic heating operation.
1. Specify the prediction target before collecting a year of data
The phrase “heating demand” can refer to several fundamentally different outputs. Peak heat loss is the instantaneous heat that a building must receive at a particular indoor–outdoor temperature difference, useful for equipment sizing. Daily space heat is energy delivered by the heating system to the building over 24 hours. Purchased electrical energy is what a heat pump, pumps, immersion or controls draw from the supply. Heating cost combines that purchased energy with tariff timing and any other relevant costs. One sensor rarely measures all of them.
| Target | Correct typical unit | Preferred measurement | Useful for |
|---|---|---|---|
| Peak building heat loss | kW | Survey plus design conditions; validated heat-loss estimate | Plant and emitter sizing |
| Delivered space-heating energy | kWh of heat | Calibrated hydronic heat meter or dependable manufacturer output | Weather-normalised demand |
| Heating electrical input | kWh electricity | Dedicated heating circuit or equipment meter | Electricity use and cost |
| Heating fuel use | kWh gas or fuel units | Meter with suitable allocation and calorific conversion | Boiler consumption trends |
| Room warm-up time | Minutes or hours | Indoor sensor plus heat-on timestamps | Preheat timing |
| Next-day spending | Currency/day | Time-aligned imported kWh and applicable tariff | Planning a household budget |
For a heat pump, a forecast of 35 kWh/day of delivered heat is not a forecast of 35 kWh/day of grid electricity. At an illustrative average COP of 3.0, it corresponds to about 11.7 kWh/day of electrical input before investigating the metering boundary. A model that was trained on whole-house electricity can mistakenly credit the heater for an EV charging session or kitchen load. Conversely, a heat meter on the space-heating circuit may omit domestic hot water. Label the target sensor and chart in plain language so these quantities cannot quietly be confused.
2. Survey the building and controls: what the thermometer cannot tell you
Before fitting parameters, document the floor area, approximate age and construction, recent insulation upgrades, window types, exposed elevations, occupancy pattern, heating emitters and thermostat schedule. Record whether a heat pump uses weather compensation, whether radiators have TRVs, whether an underfloor manifold closes zones, and whether a buffer tank or hydraulic separator changes the measured energy boundary. None of those observations has to be perfect, but missing them can make a statistically attractive result physically misleading.
| Installation observation | Typical effect on the data | What to record |
|---|---|---|
| Setback or occupancy schedule | The indoor temperature target changes with time | Setpoint or mode history |
| Solar gains on south-facing rooms | Measured heat use falls on bright winter days | Sun/irradiance or daylight indicator |
| Ventilation and opened windows | Short periods of unexpectedly high heat loss | Ventilation mode; optional window events |
| UFH screed or thick masonry | Indoor response is delayed | Emitter type and thermal-mass notes |
| Domestic hot-water priority | Space-heating input temporarily stops | DHW mode and energy boundary |
| Defrost / electric backup | Input spikes do not reflect proportional comfort heat | Compressor, defrost and backup status |
| Multiple zones with TRVs | Flow and demand vary as rooms close | Valve and zone-request histories |
| Weather-compensated flow temperature | Equipment efficiency changes with outdoor temperature | Flow setpoint and system mode |
For homes with multiple heated floors or wings, a single hallway thermometer is not a whole-house indoor average. Give the model a representative weighted indoor temperature or explicitly limit its claims to the monitored zone. The presence of an unheated conservatory, open stairwell or frequently used wood stove can matter more than adding a sophisticated machine-learning algorithm.
3. Separate the balance-point temperature from the comfort setpoint
A basic heating degree day model uses HDD = max(0, Tbase − Tout,mean) for one day. The base temperature represents a condition at which internal and solar gains roughly cover building heat losses, not the number selected on the thermostat. A 20°C indoor setpoint might coexist with a balance point near 14–17°C, depending on insulation, occupants, appliances and sunshine. A conventional 15.5°C base is an initial hypothesis, not a universal building constant.
If an efficient house stays comfortable during mild weather with its heating off, forcing the base temperature to the indoor setpoint overestimates energy use. If the household regularly opens windows or runs mechanical ventilation at high airflow, a fitted low base may be unstable. Fit a small sensible set of bases, validate each on future data, and report the chosen one. For daily models, a simple equation is Eheat ≈ a + b × HDD, optionally clipped at zero; the units of b are kWh of heat per degree-day.
| Daily mean outdoors | HDD at 13°C base | HDD at 15.5°C base | HDD at 18°C base |
|---|---|---|---|
| −2°C | 15.0 | 17.5 | 20.0 |
| 3°C | 10.0 | 12.5 | 15.0 |
| 8°C | 5.0 | 7.5 | 10.0 |
| 13°C | 0 | 2.5 | 5.0 |
| 16°C | 0 | 0 | 2.0 |
| 19°C | 0 | 0 | 0 |
A non-zero fitted intercept may capture a real weather-independent heating requirement, but it may also indicate DHW contamination, meter offsets or improper clipping. A physically interpreted building demand model often behaves better with a piecewise response that approaches zero above the balance point. Never enforce an arbitrary intercept merely because it increases R² on the training weeks.
4. A worked heat-loss coefficient estimate from measured energy
Suppose a house receives an estimated 36 kWh of delivered space heat on a day with a 20°C average indoor temperature and 10°C outdoor mean. Ignore free internal gains for the first demonstration. The mean delivered thermal power is 36 / 24 = 1.5 kW; dividing by the 10 K indoor–outdoor difference gives an apparent heat-loss coefficient of 150 W/K. This describes the measured operating day, not a certified fabric loss and not a heat pump electrical rating.
Now account for a hypothetical 6 kWh of net useful gains from occupants, appliances and sunlight during that day. If the indoor temperature was approximately stable, heat loss from the building was closer to 36 + 6 = 42 kWh. The corresponding H is 42 / (24 × 10) = 0.175 kW/K, or 175 W/K. In real life, gains and energy stored/released by the building vary across the period, so the estimate is only credible across several steady or well-modelled days. It cannot replace a design-temperature, room-by-room heat-loss assessment.
| Interpretation | Formula | Result in this example |
|---|---|---|
| Heating energy supplied | Measured delivered space heat | 36 kWh/day |
| Mean heating power | 36 ÷ 24 | 1.50 kW |
| Apparent H, neglecting gains | 1.50 kW ÷ 10 K | 150 W/K |
| Illustrative total losses with 6 kWh gains | 36 + 6 | 42 kWh/day |
| Indicative H with estimated gains | 42 ÷ (24 × 10) | 175 W/K |
| What cannot be claimed | One day plus uncertain gains | Verified fabric heat-loss coefficient |
To estimate H more credibly, select periods with a relatively stable indoor temperature, no unusual solar or ventilation events, stable control mode and well-metered delivered heat. Fit many days and inspect residuals across cold and mild temperatures. A mechanical heating schedule can also introduce an apparent “thermal lag” even when the physical building lag is different.
5. Thermal mass and the first-order RC model
The thermal resistance–capacitance, or RC, approach adds an explicit storage term to the loss equation. A simple lumped representation is C × dTin/dt = Qheat + Qgains − H × (Tin − Tout). Here H is kW/K, thermal capacitance C is kWh/K, the temperature derivative is K/h and the heat inputs are kW. The units must match. The associated idealised time constant is τ = C/H in hours.
For a purely illustrative model with H = 0.18 kW/K and effective C = 13 kWh/K, τ = 13 / 0.18 ≈ 72 hours. This does not mean that the room takes exactly 72 hours to respond to the heating. It means a one-zone first-order model, with fixed conditions and no additional control effects, approaches approximately 63% of a step change after one time constant. Air temperature may respond substantially faster than the effective whole-building mass, and floors, walls and emitters can introduce additional time constants.
| Parameter | Physical meaning | Common source of error |
|---|---|---|
| H [kW/K] | Overall heat loss per kelvin | Unmodelled infiltration or changing windows |
| C [kWh/K] | Effective heat capacity participating in measured response | Assuming all concrete participates equally |
| Qheat [kW] | Heat actually entering conditioned rooms | Using compressor electricity instead of delivered heat |
| Qgains [kW] | Sun, people, appliances, secondary heaters | Assuming a sunny afternoon is a heating-system improvement |
| Tin and Tout [°C] | Indoor and outdoor conditions | Poor sensor placement or timestamp mismatch |
| τ [h] | Idealised RC time constant | Mistaking it for actual warm-up time |
A single RC model cannot represent both a rapidly responsive air layer and a deep concrete slab accurately across all events. A two-state model—room air plus floor or wall mass—can improve prediction if enough high-quality measurements are available, but is more difficult to identify uniquely. For a normal house, start by estimating indoor cooling and warm-up response under controlled, normal operating conditions; do not turn off essential heating in unsafe weather to collect a textbook decay curve.
6. A one-hour model with explicit storage: the numerical update
At hourly resolution, one approximation is Tnext = Tnow + Δt × [Qheat + Qgains − H(Tnow − Tout)]/C, with Δt measured in hours. The timestep should be short enough relative to the thermal time constants for this explicit numerical method to be stable and accurate. If the building contains slow screed heating but a controller switches several times an hour, use finer time data for identification or aggregate carefully to avoid aliasing the switching events.
Worked hour: H = 0.18 kW/K, C = 13 kWh/K, indoor 20°C, outdoor 5°C, 4 kW delivered heating, 0.5 kW useful gains. Fabric and ventilation loss is 0.18 × 15 = 2.7 kW. Net storage charging is 4 + 0.5 − 2.7 = 1.8 kW. The predicted one-hour temperature increase is 1.8/13 = 0.138°C. That is a small rise despite 4 kW of heating, and it illustrates why slow-mass systems should not be judged solely on immediate indoor temperature change.
The same simplistic model with the heating off and no useful gains has a net loss of 2.7 kW at the starting temperature, suggesting a one-hour fall near 0.208°C. As the interior cools, the loss decreases, so extending that hourly arithmetic for an entire night would exaggerate cooling. In real buildings, infiltration, surfaces, controls and sensor response make observations less smooth. A prediction band is more useful than four decimal places on an individual step.
7. Identify a realistic warm-up rate, rather than assuming a fixed preheat time
A preheat scheduler needs to know how long it takes to reach a comfortable state, not merely how fast an ideal one-node temperature moves. Measure several ordinary warm-up events: initial indoor temperature; outside temperature; equipment mode; flow-temperature setpoint; whether DHW priority occurred; and time at which the occupied room reached its scheduled target. Keep events with sensor outages or manual interventions separate.
| Warm-up event | Outdoor mean during event | Initial room temperature | Rise achieved | Time taken |
|---|---|---|---|---|
| A — mild morning | 10°C | 18.5°C | 1.0°C | 1.4 h |
| B — cool morning | 5°C | 18.5°C | 1.0°C | 1.9 h |
| C — cold morning | 0°C | 18.5°C | 1.0°C | 2.5 h |
| D — sunny afternoon | 6°C | 18.5°C | 1.0°C | 1.3 h |
These are illustrative observations, not manufacturer performance figures. They are clearly not described by outside temperature alone: event D warmed faster than event B despite similar temperatures because solar and occupancy gains changed. Predicting tomorrow’s warm-up from the median of matched historical conditions, with a deliberate safety margin, is often a better starting point than fitting a high-order model from four events.
Define the completion criterion before gathering data—perhaps a selected room sensor reaching the normal occupied setpoint for a short stable interval. Do not use a heat-pump flow-water sensor to declare the living room comfortable. Preserve the unit’s native weather compensation, anti-cycle delays, frost protection and approved temperature boundaries.
8. Why different heating systems need different forecasting models
In a gas boiler and radiator house, heat delivery may be relatively responsive, but cycling, boiler modulation and TRV closures change the relationship between demand signal and actual heat. A heat pump’s electrical input changes with outdoor temperature, water flow setpoint, compressor operation and defrost. A floor-heating system may store hours of energy in screed after the flow valve closes. A model trained for one configuration cannot be assumed to work after swapping the emitter type or rebalancing the system.
| Heating system | Preferred target | Important extra variable | Scheduling caution |
|---|---|---|---|
| Radiators + modulating boiler | Delivered space heat or gas use | Burner state, water temperature, modulation | Do not equate thermostat “on” to continuous burner firing |
| Radiators + heat pump | Delivered space heat plus electricity | Flow setpoint, COP, defrost | Avoid forcing high flow temperature for a cheap-price slot |
| Wet UFH + heat pump | Delivered heat and room comfort | Slab / manifold response, minimum flow | Aggressive setbacks may be counterproductive |
| Direct electric room heating | Circuit electrical kWh | Room thermostat and occupancy | Model thermal load separately from tariff |
| Hybrid heat pump + boiler | Delivered heat by source | Source switching and fuel prices | A single conversion efficiency is misleading |
| District heating | Thermal meter kWh | Supply conditions and network control | Local control may be limited by provider |
For boilers, flow and return-water temperatures can help diagnose modulation and cycling but do not provide delivered energy unless water flow is also measured appropriately. For heat pumps, the system controller may already use weather compensation and load adaptation; a Home Assistant forecast can be useful for monitoring and slow scheduling decisions without trying to replace that closed-loop plant control.
9. Clean timestamped sensor data: the most underrated modelling task
A daily energy model can be defeated by time alignment. Temperature sensors may report only when their reading changes, electricity meters may update at fixed intervals and weather forecasts may be labelled by the beginning of an hourly forecast period. It is not valid to multiply all samples equally if one sensor reports every 20 seconds during change but only once an hour while stable. Prefer a time-weighted outdoor average or hourly aggregates with known coverage.
Electricity and heat counters require a different treatment from instantaneous power. A cumulative kWh meter should be differenced across interval boundaries, with explicit consideration of device resets and rollovers. An instantaneous W or kW sensor must be numerically integrated over time—preferably using a maintained Home Assistant integration designed for that purpose—rather than summing power readings as if they were already kWh. Record the measurement coverage of every daily record so poor data does not silently enter the training set.
| Failure mode | What goes wrong | Validation rule |
|---|---|---|
| Sensor reports only on change | Sample-count mean biases daily outdoor temperature | Use time-weighted interval mean and coverage |
| Daily kWh total resets unexpectedly | Negative or enormous consumption | Flag counter resets; inspect raw history |
| DHW energy included in space-heating target | Hot-water days look like unusually cold days | Separate DHW mode or metering |
| DST moves local midnight | A day may cover 23 or 25 clock hours | Store UTC and explicit local calendar labels |
| Weather forecast revised later | Backtest unintentionally uses information from the future | Archive forecast as it was known at decision time |
| Stale indoor sensor | Room falsely appears stable | Set freshness threshold and availability |
| Missing outdoor values coded as 0°C | Heating load appears artificially high | Keep missing values unavailable; exclude training |
For cost forecasting, local half-hourly tariffs must line up with the same actual consumption intervals, especially around daylight-saving transitions. For thermal inference, periods of unusual manual boosts or open windows can be retained as labelled outliers for diagnostics, but should not be silently used to infer the permanent fabric coefficient.
10. An explicit dataset example: eight daily records
Consider an illustrative model training extract that contains delivered space heat, daily temperature, useful operating notes and no EV or DHW electrical loads. The table below is deliberately small to show the columns; eight days are nowhere near enough to establish seasonal forecast accuracy. A real model should include enough future-style holdout periods to span mild and cold weather, weekdays and weekends, solar conditions and system transitions.
| Date (example) | Outdoor mean | HDD base 15.5°C | Delivered heat | Operating note |
|---|---|---|---|---|
| 1 Nov | 12°C | 3.5 | 15 kWh | Normal |
| 2 Nov | 10°C | 5.5 | 23 kWh | Normal |
| 3 Nov | 7°C | 8.5 | 34 kWh | Cloudy |
| 4 Nov | 6°C | 9.5 | 31 kWh | Sunny gains |
| 5 Nov | 4°C | 11.5 | 46 kWh | Windy |
| 6 Nov | 9°C | 6.5 | 25 kWh | Normal |
| 7 Nov | 11°C | 4.5 | 18 kWh | Setback changed |
| 8 Nov | 5°C | 10.5 | 41 kWh | Normal |
A simple model could fit these observations closely but become unstable because of the wind, sunshine and changed schedule. The best response is usually to label those factors, compare performance on genuinely later days, and resist the temptation to create a special correction for every unusual row. A good production system also records the model version, training period and sensor-health status beside each prediction, so you can trace how a number was created.
11. Chronological validation: three benchmarks every model should beat
Never shuffle daily observations randomly and describe the result as “future accuracy”. Adjacent days have related weather, temperatures, heating schedules and stored heat. Random splitting leaks this structure between training and testing. A better design fits on earlier weeks, chooses model options on a later validation period, then reports one final result on a still-later untouched test period. If there is enough data, rolling-origin or walk-forward testing provides multiple realistic forecasting windows.
Compare at least three benchmarks: yesterday’s heat (persistence), same-weekday typical demand where relevant, and a simple HDD model with fixed coefficients. A complex RC or machine-learning model only merits operation if it improves later-period error, calibration or comfort outcomes by a useful margin after accounting for maintenance. Also compare forecasting electricity separately if COP variability matters.
| Metric | What it answers | Main weakness |
|---|---|---|
| MAE [kWh/day] | Typical absolute daily miss | Treats under- and over-prediction symmetrically |
| RMSE [kWh/day] | How badly large misses are penalised | Can be dominated by a few extreme days |
| Median absolute error | Typical day less affected by outliers | Conceals rare expensive misses |
| Mean bias [kWh/day] | Whether the model systematically over/under predicts | Positive and negative errors can cancel |
| Error by temperature band | Does it fail in cold weather? | Requires enough days per band |
| Prediction interval coverage | Does stated uncertainty match reality? | A wide interval can cover everything without being useful |
| Comfort violations | Did a schedule leave rooms too cold? | Needs independent and appropriate temperature measurement |
Suppose an unseen 20-day test has daily errors of 3.0 kWh MAE for the HDD model and 2.8 kWh for a more complicated thermal model. A 0.2 kWh/day reduction may not justify the latter’s extra sensors, moving parts and tuning unless the improvement is repeatable and matters operationally. Conversely, a modest average improvement could be valuable if it removes severe cold-morning underestimates that cause discomfort. Report both average metrics and the worst practical failure cases.
12. Quantify uncertainty instead of publishing false precision
Weather forecasts are uncertain. Sensor readings are uncertain. A new heating schedule can change the system’s behaviour. Even a correctly fitted thermal model therefore cannot honestly promise “tomorrow 34.27 kWh”. Prefer a practical range supported by validation: for example 31–42 kWh of delivered heat for a predicted 36 kWh, explicitly labelled as an illustration rather than an established 90% confidence interval.
For a lightweight implementation, retain the absolute residuals from chronologically held-out forecasts. Their 80th or 90th percentile can provide an empirical planning margin when data conditions are comparable. Do not call it a formal predictive interval without accounting for sample size, systematic bias and changing weather regimes. Calibrate separately for cold and mild days if errors differ materially; do not assume a winter model retains its accuracy after insulation upgrades or a control-system change.
| Predicted value | What to display | Operator interpretation |
|---|---|---|
| 36 kWh/day thermal | Expected delivered energy | Not electric import |
| Observed test MAE 4 kWh/day | Typical model miss | Not a maximum bound |
| Illustrative 31–42 kWh range | Planning interval | Meaningful only if validated |
| Forecast weather age 14 hours | Input age | Review before scheduling |
| Outdoor sensor missing | Unavailable | Do not silently substitute zero |
| Model version v1.2 and train dates | Model provenance | Supports audit and comparison |
When a source fails, a dashboard should display the last valid forecast as historic information, not pretend it is current. If Home Assistant uses the prediction to suggest a time slot, require fresh weather and tariff data; otherwise fall back to the manufacturer’s native, comfort-protecting schedule. A failed prediction is a reason for a simpler plan, not a reason to bypass equipment safeties.
13. A reproducible local fitting process: what to calculate
For owners comfortable with spreadsheets or Python, the minimum useful fitting workflow is quite modest. Export consecutive daily records with date, outdoor mean, indoor target, dedicated heating energy and exclusions or labels for DHW. Split by time. Fit a simple linear or non-negative model with one balance-point setting, then calculate its unseen-period errors. Save coefficients and a summary of when they were last validated. Do not automatically refit after every new sensor reading; coefficients that jump daily are often a sign of insufficient information or seasonality.
- Pick the physical target: heat meter kWh or heating-only electrical kWh, not both under one name.
- Calculate daily HDD from a validated daily outdoor mean and a documented balance point.
- Fit
E = max(0, a + b × HDD)on the earlier training period; constrain coefficients only where physically justified. - Backtest on later dates with no random shuffling and no forecast values reconstructed using future weather.
- Report MAE, RMSE, bias, day-count and separate winter/mild error.
- Try yesterday-value persistence and a fixed typical weekday as competing baselines.
- Only then consider extra lagged indoor-temperature, solar or wind terms if they reduce held-out error.
- Write model coefficients, version, sensor entity names and refresh timestamp into a short configuration record.
For those using regression software, beware serially correlated residuals: successive cold days and building thermal storage violate the idea that each daily error is independent. You can still produce an operational forecast, but standard error bars from naïve independent residual assumptions may be overconfident. Avoid interpreting model coefficients as a formal building-fabric survey unless all omitted thermal inputs are properly dealt with.
14. Monitoring-only Home Assistant YAML: degree days and heating energy
The example below is deliberately not a thermostat controller. It provides a current temperature-deficit diagnostic and a daily heating meter. Replace the entity IDs with your own, use a reliable outdoor temperature sensorAliExpress price, and ensure the input energy counter represents only the relevant heating equipment. The temperature-deficit sensor is instantaneous “degree-days per day equivalent” at the present reading, not a completed calendar-day HDD and not tomorrow’s forecast.
template:
- sensor:
- name: "Heating Temperature Deficit Now"
unique_id: heating_temperature_deficit_now
unit_of_measurement: "°C"
state_class: measurement
state: >-
{% set outdoor = states('sensor.outdoor_air_temperature') | float(none) %}
{% if outdoor is not none %}
{{ [15.5 - outdoor, 0] | max | round(2) }}
{% else %}
{{ 'unavailable' }}
{% endif %}
availability: >-
{{ is_number(states('sensor.outdoor_air_temperature')) }}
utility_meter:
heating_electricity_daily:
source: sensor.heating_electricity_total_kwh
cycle: dailyThe daily utility meter is only correct when sensor.heating_electricity_total_kwh is a suitable cumulative kWh entity, with correct meter reset behaviour. If your starting source is instantaneous power in watts, first establish a robust energy sensor using the supported Home Assistant integration and check its long-term statistics. The daily meter will then follow local calendar cycle boundaries; comparisons should still account for local DST and the period represented by your weather averages. A virtual zero every midnight does not represent zero lifetime consumption.
For a model needing hourly means, Home Assistant’s Statistics integration supports time-based buffers and time-weighted characteristics. Its documentation cautions that a sparse or insufficiently covered buffer can give unexpected results. An average of last updates is not automatically an accurate hour-mean temperature. Use a regular sampling strategy, check age coverage, and archive time-aligned aggregates for the modelling process.
15. A forecast-only sensor with externally fitted coefficients
The following independent example assumes an existing entity sensor.tomorrow_outdoor_mean_c represents a genuinely forecast next-day mean temperature. It is a placeholder entity name, not a standard Home Assistant weather entity. You must create it from an actual supported forecast source and confirm the period, units, timezone and update freshness. The model coefficients shown are invented demonstration values and must be replaced after fitting against your own energy boundary.
template:
- sensor:
- name: "Tomorrow Heating Heat Forecast"
unique_id: tomorrow_heating_heat_forecast
unit_of_measurement: "kWh"
state_class: measurement
state: >-
{% set out = states('sensor.tomorrow_outdoor_mean_c') | float(none) %}
{% if out is not none %}
{% set hdd = [15.5 - out, 0] | max %}
{{ [2.0 + 4.0 * hdd, 0] | max | round(1) }}
{% else %}
{{ 'unavailable' }}
{% endif %}
availability: >-
{{ is_number(states('sensor.tomorrow_outdoor_mean_c')) }}With a 7°C tomorrow mean, this illustrative sensor calculates HDD = 8.5 and a daily delivered-heat forecast of 2 + 4 × 8.5 = 36 kWh. It is still not a guarantee of electricity consumption. If you later add a COP-based input forecast, do not silently use a constant COP across DHW, cold defrost periods and space heating; it must be labelled a rough assumption or fitted to measured input data. Display any fitted model’s expected error and last update separately, rather than embedding unjustified decimals in the result.
Home Assistant state_class: measurement is appropriate for a forecasted point-in-time numerical value in kWh, not for cumulative metered energy. Do not send this forecast to the Energy dashboard as if it were delivered energy. Measured kWh counters use the appropriate cumulative semantics; forecasts belong in custom dashboards and decision-support entities.
16. Thermal lag with lags, moving averages and validation—not guesswork
A quick way to examine time delay is to compare outdoor temperature, heat-pump operation and indoor response after shifting one series by one, two or several hours. But cross-correlation alone does not identify a physical time constant because a controller changes heat input in reaction to indoor temperature, and both variables follow daily solar and occupancy cycles. Correlation may show the thermostat programme more clearly than the building fabric. Test lags on later days after fitting them on earlier data, and reject a lag term that is unstable across weather conditions.
Another lightweight model uses an exponentially smoothed outdoor temperature as a “weather memory” variable, with a coefficient fitted to historical observations. This can improve daily heating forecasts when a masonry building remains warm after a sunny day. But the smoothing horizon is an empirical modelling choice, not a measured slab response constant. Keep the physically meaningful instant weather input as well; a single smoothed temperature cannot capture direct sun, wind, a changed heating target and DHW interruption.
| Model level | Inputs | Benefit | When to stop |
|---|---|---|---|
| Daily HDD baseline | Tomorrow average outdoor temperature | Transparent and easy to validate | Use if more complex models add negligible value |
| HDD + indoor target | Weather and schedule | Captures occupied vs setback patterns | Stop if setpoint telemetry is unreliable |
| HDD + weather memory | Temperature plus prior-day weather | May capture slower fabric response | Stop if lag term only helps training data |
| RC thermal model | H, C, Tin, Tout, delivered power | Interpretable dynamic temperature model | Avoid if C and gains cannot be identified |
| Extended empirical model | Sun, wind, occupancy, flow temperature | May reduce unusual-day errors | Stop if data maintenance costs exceed benefits |
17. Heating degree hours versus degree days: when precision helps
Daily average temperature loses information about how cold it is at the time you need heat. For example, two days may have the same mean of 8°C, yet one can have a very cold night followed by a warm afternoon. If the home has a setback schedule or a fast-response heater, hour-by-hour heat demand and tariff can differ substantially. Heating degree hours sum max(0, Tbase − Tout,hour) across each valid hour. Divide the sum by 24 to express degree-day equivalents when the hours represent a complete 24-hour period.
In periods when outside temperature crosses the balance point, the daily-mean HDD and the sum of hourly degree hours are not generally identical because of the non-linear max(0, ...) clipping. This difference matters most in mild shoulder-season weather, exactly where some hourly heating schedules are most variable. Do not promote an hourly model solely because it produces more numbers: its weather forecasts, thermal response and interval meter data must all be reliable at that same resolution.
| Period | Outdoor temperature | Deficit below 15.5°C | Degree-hours |
|---|---|---|---|
| 00:00–06:00 | 3°C | 12.5°C | 75 |
| 06:00–12:00 | 7°C | 8.5°C | 51 |
| 12:00–18:00 | 17°C | 0°C | 0 |
| 18:00–24:00 | 9°C | 6.5°C | 39 |
| 24-hour total | 9°C arithmetic mean | — | 165 degree-hours = 6.875 degree-days |
The example’s four six-hour blocks each assume constant temperature in that block. Its mean outdoor temperature is (3 + 7 + 17 + 9)/4 = 9°C, so the daily-mean method gives only 15.5 − 9 = 6.5 HDD. The hourly-block equivalent is 6.875 because the warmest block is clipped at zero. This is one reason time-of-use heating forecasts may need subdaily weather data even when a daily energy estimate appears accurate.
18. Money is a secondary model: combine useful heat, COP and tariff by interval
Once you can predict delivered heat per interval, estimate electricity using Eelectric ≈ Qheat / COP for each corresponding operating interval, and then multiply that interval’s imported electricity by its actual tariff. This cannot be applied as a universal constant across different water temperatures and defrost conditions. A gas boiler instead needs its own appropriate fuel-energy accounting. For a hybrid system, the chosen energy source is itself a control decision.
Illustration: the model predicts 24 kWh of space heat. Option A produces 12 kWh of that heat during a cheap slot at COP 2.8 and 12 kWh in a dear slot at COP 3.5. At 15p and 30p per electrical kWh, costs are (12/2.8 × £0.15) + (12/3.5 × £0.30) ≈ £1.67. If all 24 kWh of heat could instead be produced in the dear slot at COP 3.5, the simplified cost is about £2.06. The £0.39 theoretical difference ignores any extra heat leakage, storage limits, different COP from forced operating conditions, household comfort and plant capacity. It is not a promised saving.
| Scenario | Useful heat | Input assumption | Illustrative purchase cost |
|---|---|---|---|
| Early cheap slot | 12 kWh | COP 2.8; 15p/kWh import | £0.64 |
| Later dear slot | 12 kWh | COP 3.5; 30p/kWh import | £1.03 |
| Split schedule total | 24 kWh | Different COP and tariffs | £1.67 |
| All in dear slot | 24 kWh | COP 3.5; 30p/kWh import | £2.06 |
| Comparison only | Same useful heat | Ignores storage/comfort losses | About £0.39 theoretical difference |
Preheating often means the building is warmer earlier than it otherwise would be. At an illustrative H of 0.18 kW/K, maintaining the home just 1°C warmer for five hours adds roughly 0.18 × 1 × 5 = 0.9 kWh of heat loss under the simple steady-state approximation. If the heat pump must lift flow temperature substantially to preheat quickly, COP may fall further. Actual differences depend on the temperature trajectory and model, not a permanent 1°C step, so measure the full-day outcome. A good optimiser includes comfort, peak power, backup heat, and a no-optimisation baseline.
19. Decision policy: use a forecast as advice before it controls the house
A sensible deployment is staged. In week one, display forecast and observed daily consumption side by side without influencing heating. In week two, show an advisory “likely need to start earlier” message but keep manual judgement. Only after comparing multiple weeks, including cold conditions and failures, consider supported schedule changes through native appliance APIs. Even then, specify upper and lower comfort limits, maximum preheat window, maximum schedule changes per day and a fallback to the vendor controller on missing data.
| System condition | Home Assistant response | Keep outside HA responsibility |
|---|---|---|
| Forecast and sensors healthy | Show estimate and suggest supported schedule | Boiler or heat-pump safety controller |
| Tomorrow weather missing | Use simple validated seasonal baseline | Frost and equipment protection |
| Energy meterAliExpress price unavailable | Disable cost-savings claims; continue normal heating | Physical thermostat and plant control |
| Tariff feed stale | Use native fixed-price schedule or comfort programme | Essential morning warm-up |
| Unexpected occupant setpoint change | Invalidate relevant forecast and recalculate | Manual room thermostat authority |
| DHW priority begins | Allow manufacturer sequence; flag model interval | Heat-pump DHW safety logic |
| Equipment fault or frost alarm | Defer optimiser and inform responsible person | Fault handling and independent protections |
The most dangerous “optimisation” is the one that silently becomes essential to keeping the home safe. Do not bridge thermostat safety terminals with an improvised controller, defeat anti-cycling or minimum-flow protections, or disable frost protection because a weather forecast predicts a warm afternoon. A homeowner may model and monitor locally, but control wiring and changes to heating plant should follow the manufacturer’s requirements and qualified-installer rules.
20. A four-week commissioning plan for a real house
A robust pilot can be conducted without touching the live heating control. During the first week, verify each sensor, its unit, update frequency and whether the heating-energy meter includes pumps or domestic hot water. In week two, fit the plain HDD model using already available historical data and publish forecast and actual values. In week three, test a second model with indoor setpoint or lag only if the baseline has a clear weakness. In week four, compare unseen days, review comfort and sensor outages, and decide whether any schedule recommendation would have been correct in practice.
| Week | Activity | Evidence to keep | Acceptance question |
|---|---|---|---|
| 1 | Survey, meter mapping, daily aggregates | Sensor list and sample validity | Are heating and DHW separated? |
| 2 | HDD model and persistence benchmark | Coefficients and first errors | Does baseline beat a simple guess? |
| 3 | Thermal-lag or schedule model | Chronological comparison | Is improvement genuinely repeatable? |
| 4 | Unseen-period and failure review | MAE, bias, misses, comfort, outages | Is a forecast operationally worthwhile? |
Pass/fail criteria should be proportional to the use case. An indicative winter electricity budget can tolerate more uncertainty than a promise that a child’s bedroom reaches 20°C exactly at 07:00. Before enabling any scheduling change, run a shadow simulation that records what the controller would have requested and compare it with actual operation. Count discomfort, unexpected boosts and extra losses; do not report a monetary saving from theoretical cheap-slot energy alone.
21. Troubleshooting: a systematic checklist when the prediction is wrong
| Symptom | Likely explanation | Next check |
|---|---|---|
| Forecast good in cold weather, poor in mild | Balance point or solar gains incorrectly modelled | Try another base on held-out mild days |
| Good for radiators, poor after UFH retrofit | Thermal response model changed | Retrain, document emitter change |
| Predicted heat matches; kWh electric does not | COP, backup heat or defrost changed | Compare metered electricity and heat separately |
| Model drifts after insulation upgrade | Heat-loss coefficient no longer matches house | Start a new model version |
| Morning comfort achieved late | Warm-up timing too optimistic | Use conditional warm-up validation |
| 24-hour daily totals disagree with utility meter | Boundary mismatch, reset or time zone | Reconcile exact intervals and meters |
| Unreasonably large HDD spikes | Missing sensor interpreted as 0°C | Enforce availability and freshness |
| Excellent training R², bad next month | Overfitting or temporal leakage | Use rolling-origin holdout |
| Weather forecast accurate, demand is low | Sun, occupants or secondary heating changed | Label useful gains and control state |
| Model says cheaper preheat but bill rises | Extra loss or COP penalty omitted | Evaluate complete-day purchased kWh and cost |
Keep a weekly dashboard with forecast versus measured heat or electricity, daily model residual, outdoor mean, indoor setpoint, equipment state, weather-input age and model version. A residual chart often reveals actionable issues—a DHW event mapped to space heat, an outdoor sensor warmed by afternoon sun, or a control schedule accidentally changed. Forecast error is therefore useful diagnostic data, not merely a measure of an algorithm’s mathematical success.
22. Sources, measurements and further technical reading
For Home Assistant’s implementation details, consult Statistics for time-weighted averages and age coverage, Utility Meter for daily counters, Template integration for derived sensors, and sensor state classes before reusing energy entities. Current integration syntax and device support should be checked against the installed Home Assistant release. Read our guide to correctly mapping grid, solar and battery entities when comparing purchased electricity, and our ESP32 multi-zone heating controller for the separate hardware-control discussion.
The measurements and models in this article are for understanding and planning a real heating system, not for certifying design heat loss, overriding manufacturer commissioning instructions or replacing professional appliance sizing. If the data suggests an equipment problem, record a good diagnostic timeline and give it to a competent heating engineer. A transparent forecast with known limits is worth more than an automated system that appears precise while quietly relying on the wrong sensor.
Frequently asked questions
Can outdoor temperature alone predict my heating bill?
It can explain a substantial part of seasonal variation, but the bill also depends on heating efficiency, tariff, hot-water use, solar gains, occupancy and controls. Treat it as a baseline, not a guaranteed bill prediction.
What is the best heating degree day base temperature?
There is no universal best base. Start with a conventional value such as 15.5 °C, then validate a few plausible alternatives against measured heating-only energy.
Do I need a heat meter?
For delivered-heat forecasting, a calibrated heat meter is best. For a first electricity-cost forecast, a dedicated electrical meter can be enough, provided the model is explicitly an electricity model.
Can I estimate heat pump COP from outdoor temperature?
You can build a rough empirical relationship, but flow temperature, defrost, cycling and hot-water production matter. Do not treat outdoor temperature as a complete COP model.
How much data do I need?
A few weeks can support a prototype, but a varied heating season gives a more credible model. Include cold and mild conditions and reserve later periods for testing.
Does underfloor heating have more thermal lag than radiators?
Often, especially where a thick screed stores heat, but the actual response depends on floor construction, water temperature, controls and the building.
Should I use hourly or daily predictions?
Daily predictions are usually more robust initially. Hourly predictions need better timestamps, occupancy data, thermal lag handling and validation.
Why is my prediction wrong on sunny days?
Solar gains reduce heating demand without changing the outdoor temperature enough to explain the effect. Solar irradiance or a daylight proxy may improve the model.
Can Home Assistant replace weather compensation?
It can provide supervisory logic, but native weather compensation is often a better first choice. Preserve appliance protection, safety functions and installer settings.
Will preheating always save money on dynamic tariffs?
No. Increased heat loss, higher flow temperatures and comfort constraints can outweigh cheaper energy prices. Compare full-day measured cost.
How should I handle missing sensor readings?
Mark the forecast unavailable or fall back to a documented conservative baseline. Do not silently treat missing temperatures as zero.
What is a reasonable forecast accuracy?
It depends on building, sensor quality and weather variation. Report absolute error in kWh and compare against a naive benchmark rather than promising a universal percentage.
References and further reading
Official resources: Home Assistant Energy management; Home Assistant Template integration; Home Assistant Statistics integration; Home Assistant History Stats integration; Met Office temperature background. For thermal controls and hot-water scheduling, see our solar surplus hot-water automation guide. Check the latest integration documentation before copying entity names or automation syntax.
Bottom line: Start with a measured heating-energy baseline and outdoor temperature, validate a simple HDD model, then add thermal lag only when it reduces error on unseen days. A good forecast makes heating operation easier to understand; it should never be allowed to defeat the appliance’s own protection and comfort controls.