Repository navigation
Ideal Logic Heat H24 Real Time Boiler Performance #40
Replies: 4 comments 41 replies
|
@sergeantd83 Could I please have your thoughts on the efficiency notes I made in the first post when you have time? GCV vs NCV. Does that seem correct to you? |
|
Sorry but I don’t have an answer for this. I noticed the same on my installation but I can’t explain it. My boiler manual indicates minimum gas consumption 0.53 m3/h, while in real life, after some calculations, gas meter indicates minimum gas consumption only 0.43 m3/h. That means my boiler in real life uses about 19% less gas than the manual indicates. In conclusion I can’t really tell what is happening here. But for sure it is a positive conclusion. |
|
Prob 0.53m³ @ 20C? |
|
Hi @sergeantd83 just started to use SAT as you know, entered my figures from the boiler manual (decimal point input would be nice) as 0.6 min and 3.4 max. then been looking at the gas sensor current_consumption figures which seemed higher than I expected. Anyway I've been monitoring my boiler for a while and the absolute minimum the relative modulation goes to is 3.57% and that seems to equate to what I've seen on my smart meter of around 5-6kw of gas usage per hr. With the setting from the boiler manual rounded to 0.6 for SAT, @3.57% RM that indicated a gas usage of roughly (Cal 40) 6.7kWhr which was not what I was seeing from the smart meter, more like 5.6kWhr. So I've adjusted my minimum value based on the following logic, which could be completely wrong :) The maximum gas use according to the manual is 3.314 so at a RM of 3.57% that would be around 0.1183098 I've then taken the minimum value 0.59 and then subtracted this to give 0.4716902, so rounded gives 0.5 to enter in SAT. This now give me a usage rate 0.5 at min RM @3.57% and hence 5.6kWhr which is closer to smart meter readings and what the boiler manual states as the minimum Thoughts? |
|
Excellent write up, I've an Ideal Vogue Max 18kW system boiler which isn't on the SAT list of compatible gateway boilers, did your Opentherm system need a lot of configuration to get it to work for a boiler type not listed? The reason for asking is that I'm really keen in trying to smooth out my efficiency as I currently control with Hive and have Home Assistant, the big but is I'm not a coder, however, your experience has tweaked my interest. |
|
Thought I'd post an image of how my systems performing before I get a thermostat which updates every 30s (its on order), and without calibrating SAT as it fails to do it, I'm putting that down to the current thermostat not updating frequently enough. |
|
It looks like the boiler is misfiring. Have you got the experimental dynamic minimum setpoint enabled in the configuration too? If yes, could you please disable it so we can look at the graph without it? |
|
Hi, no that’s not set. |
|
@redpis looking at your graph looks like you set Overshoot protection value is just over 40? I had the same issue with one a manually calculated at 44 (by the way the auto calibrate is not working stably on the current SAT version for others and myself). |
|
@MarkC1210 overshoot protection was set at 10c, and increased to 50c as suggested, so I'll see how that goes, as an aside my Xiaomi LYWSD03MMC came today for me to play with and try and increase the read rate. |
|
@critictidier so I've been messing around and made a couple of tweaks for our type of boiler, firstly I noticed that the gas consumption and kW output was much higher than I expected re: above post my boiler for example in Opentherm reports back a maximum output of 40kW and a minimum of 8kW according to SAT, but according to the specs its 5.7kW at the lowest so I coded out to ignore the lower and used the 7:1 modulation ration hence A second thing as our boilers don't respect the MM command and therefore SAT by no fault of its own performs a high modulation fast heat up in the morning was something I don't like. So I'm testing a HA automation at present (not got my head round the SAT python code yet to understand where if anywhere this could fit in maybe a new routine for boilers that ignore MM and you want some control) that controls the warmup based on raising the CS slowly and letting the RM stabilise before raising it again up to a setpoint where it hands over to SAT for the rest of the day.
Ran it for first full time this morning but seemed to work well sure there is much more that can be done minimise the startup burn, and to make it better and tie into SAT for weather comp settings etc. |
High modulation isn't bad when your current temperature is far from the target temperature, in order heat the house relatively quickly when needed. However, I agree, and it's nice to have the option to minimise modulation for our boilers where we can. Given that we have the same brand of the boiler, I can only suggest you try my fork as a temporary solution. It's works really well for me, minimises modulation (0% rm most of the time) but also provides power boost when necessary. You would need to enable dynamic minimum setpoint and then set its version to “boiler” temperature back the in the general section. You can look at my dashboards. I'm sure all of this feedback will eventually be incorporated into SAT making all boilers working perfectly. I can also see some misfires on your graph and I think there is a chance that my fork might also handle that better, although I can't guarantee it, sorry! We are all here, because we were fed up with relatively poor thermostats available on the market. All the feedback only brings us closer to the perfect solution that should be available to everyone for many years 😃 |
|
OK I'm giving your fork a try, let you know how tomorrows run goes :) |
|
Thanks @critictidier, your fork now in play and setup as you suggested on the "boiler temp", you said "I can also see some misfires on your graph" sorry what am I looking for? most of the noise at the end of my picture above is because the hot water kicked in as being a combi so boiler temp goes ramping up and when water turned of flame goes out and takes time before kicks in again and ramps up hard as sat keeps CS the same value but boiler water temp has normally dropped from what it was. |
|
Ah ok, combi boiler, makes sense in that case. Let’s see whether that fork is suitable for you 🤞 |
|
Hi! Really love the data in Grafana. Would it be possible to share sole of your code, I’d appreciate it if only to know what to look for and where to start. Thanks in advance. Sam |
|
Hi Sam, If you’re trying to set up a grafana dashboard, it’s really easy. In home assistant, install NodeRed addon. Then, in NodeRed install influxDB package. Sign up to influxDB cloud and Grafana cloud for free. For each entity you want to publish, send it to influxDB cloud from NodeRed, then from influxDB to Grafana. Then create a Grafana dashboard how you want it. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Follow boiler's diary on Blue Sky and X/Twitter.
What two heating seasons taught me about running an oversized boiler with SAT and OpenTherm
This is my two-season case study of an Ideal Logic Heat H24 that is large for the steady demand of my home. I use SAT (Smart Autotune Thermostat) in Home Assistant and OpenTherm to make its operation observable and to ask for lower water temperatures when the house needs less heat. It is a practical control experiment, not a laboratory boiler-efficiency test.
Updated in July 2026 with a sensor-recorded electric-immersion comparison.
Current system and live dashboards
My S-Plan installation has two central-heating zones and one cylinder zone for central heating (CH) and domestic hot water (DHW). The cylinder holds 242 litres. The boiler’s published range is approximately 5 kW minimum to 24 kW maximum, so it cannot continuously reduce its flame to match every mild-weather heat demand.
The current public views are the long-term EmonCMS dashboard and the time-stamped Grafana dashboard. EmonCMS is more useful for long trends; Grafana is more useful for examining a particular run. They report control and sensor signals, not calibrated heat-meter measurements.
Headline findings
How the system works
OpenTherm lets a compatible controller exchange more than an on/off call with the boiler. SAT combines weather/load-style control with timing and room-temperature feedback; when there is little demand, it can ask for a lower flow-temperature target and use cycling where the boiler’s minimum output is still too high. An OpenTherm gateway can monitor or, in gateway mode, relay/control this traffic; it is optional where the thermostat itself already speaks OpenTherm.
Mean water temperature (MWT) is
(flow temperature + return temperature) / 2. Lower MWT can support condensing operation when the emitter system can still meet demand, but it does not by itself establish an efficiency figure. I therefore describe observed water temperatures and comfort separately from modelled energy performance.Evidence and provenance
Note
How to read the evidence. I label dashboard/sensor observations as measured, product-document values as manufacturer, calculations using those values as derived, manually adjusted estimation models as calibrated, and explanations that have not been independently tested as hypotheses. None of the local telemetry is an independently calibrated input/output heat measurement.
ErP means Energy-related Products. The relevant efficiency values are based on gross calorific value (GCV), which includes the heat released when water vapour condenses; see the EU ErP communication. Net calorific value (NCV) excludes that latent heat. I keep the two denominators separate: a percentage above 100% has meaning only when quoted on an NCV denominator. The manufacturer’s cited part-load value and the subsequent dashboard-derived figures are not interchangeable.
CH findings
[Manufacturer, product data at 40 °C MWT]: the source record cites 5.1 kW minimum heat output and 4.9 kW NCV gas consumption, which corresponds to 104.1% on an NCV basis. It must not be read as 104.1% GCV efficiency or as a direct measurement of this installation.
[Derived model, April 2024 source data]: the model uses the historical linear limits
minimum kW = -0.01 x MWT + 5.5andmaximum kW = -0.0467 x MWT + 27.467, then maps reported modulation between them. It is an interpolation of manufacturer/source data and a control-side model, not a heat meter. It is particularly uncertain during warm-up, cycling and unusual boiler behaviour.What I can say from the logs is that lower requested temperatures and low-load control made it easier to run the radiator circuit at lower MWT in mild conditions while retaining the room-temperature behaviour described below. I cannot claim an optimum efficiency, performance beyond an ErP rating, or direct boiler efficiency without independently measuring fuel input and delivered heat.
DHW strategy change
In July 2024 I recorded a preference for 80 °C boiler flow during DHW recovery. By August 2024 I was trialling roughly 67.5–68 °C flow, based on a recorded approximately 13 °C flow-to-cylinder difference and a 54.5 °C target. That is a dated change of view in control strategy, preserved in the notebook rather than presented as a universal optimum.
Warning
This article does not prescribe a DHW storage temperature. HSE guidance calls for stored hot water to be at least 60 °C. Domestic safety depends on the complete system, use pattern, controls and a competent risk assessment; the historical 54.5 °C setting is not reassurance about Legionella risk.
July 2026: electric immersion versus the boiler scenario
All 31 July days were present: 29 had non-zero values and 2 were zero. The Home Assistant history records 75.762 kWh of immersion electrical input. This is input accounting from the sensor, followed by a deliberately bounded boiler scenario; it is not a delivered-hot-water measurement or a gas-meter comparison.
The modelled gas input is 1.45x the immersion input; the immersion input is 31.0% below the modelled gas input. These are model invariants from the 68.97% assumption, not a measured efficiency gain.
This 2026 assumed 69% effective DHW comparator and the earlier historical dashboard estimate above 90% use different model boundaries and datasets. Neither is a direct heat-meter result, and the solar project does not document the 69% value as an empirical correction to the 2024 estimate.
The economics depend on how the electricity was supplied: off-grid surplus otherwise curtailed; exportable solar with foregone export income; or paid grid electricity at the applicable tariff. I cannot calculate a definitive July cost because the historical operating mode is not stored per workbook row. For the wider choices around solar generation and export, see the Energy Saving Trust solar-panels guidance.
The resistance element converts electricity to heat near-unity at the element, but cylinder, pipe, standing and draw-off losses—and whether both methods supplied equivalent service—are unmeasured. The DOE/NREL comparison of water-heating systems is useful context for those system boundaries.
Using the project's emissions factor, the scenario would produce 21.53 kgCO2e of gross modelled displaced-gas emissions for July. That is not net carbon saved: electricity-source emissions and source attribution are absent.
Gas estimation and validation
The gas model begins with the derived output model above, then applies a mean-water-temperature factor and, for DHW, a historical multiplier. Its raw check is the household smart gas meter, which records at 30-minute resolution and also includes a gas hob. This makes short cycles, CH/DHW handover overlap and cooking contamination hard to separate.
The source has two explicit validation windows, not a universal percentage-accuracy result. For CH from 18:00 on 26 September 2024 to 09:00 on 27 September 2024, it records 29.241 kWh modelled heat output, 29.910 kWh smart-meter gas and 29.978 kWh estimated gas: the displayed derived ratios were 0.97763 and 0.97541. For CH/DHW windows from 20:50 on 30 September 2024 to 09:30 on 1 October 2024, the recorded totals were 25.167/24.800/24.225 kWh and 24.761/24.760/24.843 kWh for estimated gas/actual gas/modelled heat output. These are small, contaminated samples rather than accuracy proof. Since September 2025 I have manually tuned separate CH and DHW coefficients against the meter, making this a calibrated model.
Comfort and filtering
The 2025 comparison is exploratory. Its displayed comfort score is retained as supplied, but the source does not document a reproducible formula, so I do not invent one. The main record shows my boiler row and a calculated cohort summary; all 146 rows remain in the appendix. The comparison is limited by sensor position and calibration, sampling cadence, occupancy, different setpoints, missing data and different thermostat/control regimes across homes.
The October 2024 target was 20.50 °C and the period mean was 20.51 °C. Matching averages does not prove instantaneous accuracy, nor does it prove equality of heat input and heat loss at every moment. My Kalman/PyScript code is retained in full below. It is a smoother signal for control and display, not a claim that the underlying sensor is more accurate without a calibrated reference.
Heat-loss estimate evolution
The August 2025 radiator and valve changes increased heat-emitter capacity and may change the water temperature the house can achieve at a given load; they did not change the building fabric heat loss. That distinction is important when interpreting later estimates.
Current conclusions, limitations and open questions
SAT and OpenTherm gave me a better-observed, more controllable way to operate an oversized boiler. The clearest observed outcome is stable room-temperature behaviour in the recorded period; the energy outcome remains inferred through a derived/calibrated model. July 2026 is best read as sensor-recorded immersion input accounting plus a boiler scenario, not as measured delivered hot water, gas displacement or net carbon. The main unanswered questions are how the model behaves across colder weather, how much hob/DHW overlap biases meter checks, and what independent delivered-hot-water and gas measurement would show.
The appendices preserve the detailed, dated record behind these conclusions. “Superseded by” marks a later interpretation; it does not erase the original evidence.
Appendix: dated lab notebook and retained source material
Real time performance of the Ideal Logic Heat H24 boiler, managed by SAT (Smart Autotune Thermostat) and OpenTherm:
EmonCMS
EmonCMS live dashboard
Grafana dashboard, updated October 2024 with additional data points:
Grafana live dashboard
EmonCMS vs Grafana reporting.
EmonCMS - better for long term view.
Grafana - better for a daily snapshot view, with precise datapoints / timestamps where it matters.
Other example boilers and their real time data for comparison:
Expand each section below for more details:
Appendix: research and source links
Some commercial thermostats advertise their thermostat as **smart**, where the only smart feature is the ability to control the heating remotely, but in fact, only offer the simple communication.Typical efficiency curve for condensing boilers:
Image source: Heat Geek explanation of condensing boiler efficiency
Appendix: comparable boilers and installation context
minimum_setpoint, then PWM controls on/off timing. My earlier workaround for keeping the boiler near minimum modulation during warm-up was superseded by a later SAT version with official 0% modulation support.What is ErP?
In the EU and UK, ErP stands for Energy-related Products. It provides a framework for expressing the efficiency of energy-using appliances, including boilers, in converting fuel energy into heat for space heating and hot water.
For a boiler, the ErP figure is an energy-efficiency rating expressed as a percentage and category. The source record refers to the A+++ to G scale; this appendix does not use that rating to infer the measured efficiency of this installation.
GCV vs NCV (gross vs net calorific value) for condensing boilers
GCV (Higher Heating Value): Total energy, including latent heat of condensation of water vapour.
NCV (Lower Heating Value): Usable energy, excluding latent heat of water vapour.
Condensing boilers are designed to improve energy efficiency by recovering some of the latent heat from the water vapour in the flue gases, which would otherwise be lost in non-condensing boilers.
Since condensing boilers are capable of reclaiming a portion of the latent heat contained in the water vapour, they operate more efficiently and can achieve efficiencies higher than 90% relative to the GCV. Thus, when calculating the efficiency of condensing boilers, GCV might be considered more appropriate because it represents the maximum potential energy content of the fuel, including the recoverable heat.
European Commission GCV definition
UK retained Regulation 813/2013 GCV definition
ErP of the Ideal Logic Heat H24 at the ErP rated 40 °C Mean Water Temperature
Ideal Logic Heat H24 ErP can be found: Ideal-Logic-Heat-H.pdf
The product document reports a Part Load ƞ1 value of 98.7%. ErP efficiency values are GCV-based; dashboard telemetry cannot demonstrate that this installation attains that value during CH, nor the historical 92–94% DHW estimate, without independent input/output heat measurement.
Appendix: formulas and Home Assistant templates
ErP Part Load ƞ1 was tested at the 40 °C mean water temperature MWT = (flow + return) / 2. However, SAT's low-load control makes it possible to run the boiler below 40 °C. This is an operating observation, not a direct efficiency result.
Example April 24 2024
In the snapshot below, the MWT is about 35 °C.
The table below indicates that the minimum output at 40 °C mean water temperature is 5.1 kW.
Historical formula artefact. Using that source data, I plotted an interpolated relationship between temperature and heat output. The following formulas are retained verbatim as historical modelling inputs, not repaired or promoted to heat-meter evidence.
Mean Water Temperature Formula
mean_temp = (boiler_flow_temp + return_temp) / 2
Formula
Minimum Heat Output (kW)=−0.01× Mean Water Temperature (°C)+5.5
Table
Formula
Heat Output (kW)=−0.0467× Mean Water Temperature (°C)+27.467
Table
Using these values, we can adjust how we calculate the heat output dynamically!
This template does the following:
July 2024: Some DHW observations
Domestic Hot Water
Historical observation, superseded by the August 2024 strategy: I initially preferred heating at full throttle, i.e. 80 °C flow temperature.
The cost of providing hot water is much lower compared to central heating on annual basis, and the comfort of having hot water irrespective of demand is more important than some small potential energy saving that could be made.
The historical dashboard estimate suggested DHW efficiency above 90%, but this is a derived/calibrated estimate rather than a direct efficiency measurement.
August 2024: Some more DHW observations
Domestic Hot Water
A slightly more efficient historical experiment was to heat the cylinder at around 68 °C flow. The logged target was 54.5 °C and the minimum observed delta-T while DHW was running was about 13 °C, hence
54.5 + 13 = 67.5 °Cas a cycling-related control calculation. This is not a Legionella safety claim: HSE guidance calls for stored hot water at least 60 °C, and system-specific safety needs competent assessment. The source video remains available for historical context.The observation that fuel consumption appeared lower at 67.5 °C than 80 °C comes from the model and must not be taken as a direct efficiency comparison.
Legionella risk vs Cylinder Water Tank Temperatures and Water Daily Turnover (from the YouTube video above)
September 2024: Estimating Gas Consumption based on historical data
Manufacturer's Gas Consumption
When the boiler is working in the condensing mode, the source manufacturer values are 4.9 kW NCV gas consumption and 5.1 kW minimum heat output, giving 104.1% on an NCV denominator at 40 °C MWT. More than 100% has meaning only on that NCV denominator; this is not a GCV efficiency and not a measurement of this installation.
Historical data observations
Looking at the smart gas meter and the derived output model suggested results near that level in selected periods. It cannot establish direct boiler efficiency because the denominator and delivered heat are not independently measured.
Hypothesis from the historical model and illustrative curve: lower MWT may support better condensing conditions once the system is warm. The warm-up and cycling period remains a material limitation, and the model cannot turn that hypothesis into a direct efficiency measurement.
Typically, looking at historical data, you will observe that
System is
Smart Meter Gas Readings limitations
The installed smart gas meter runs on a battery that can last for many years; however, readings are limited to every 30-minute interval.
Other gas appliances
There is also a gas hob for cooking, which means that it adds another complexity when estimating efficiency. On average, about 1.2 kWh is used for cooking per day. And it's usually early morning or evening when gas hob is used.
Warmer months
During spring, summer and autumn, CH is often required only overnight. Gas-hob use can therefore often be distinguished, and Home Assistant automations apply rules to account for it.
Winter months
During winter, CH may operate during the day, so cooking-gas use must be accounted for. The estimate then becomes more difficult and less precise.
Estimating Central Heating & Domestic Hot Water gas consumption
The historical data led to a set of calibrated functions that estimate gas consumption. They were manually adjusted against limited 30-minute smart-meter windows; the exact checks and their contamination limitations are stated in the main article, so this is not a universal percentage-accuracy claim. Below is the Jinja Home Assistant template, which applies a coefficient depending on MWT.
These functions were derived from the following data
Mean Water Temperature (left column), typical efficiency at that the level (right column)
Here is the complete Home Assistant template for estimated gas consumption. It first calculates derived heat output from MWT and modulation, then applies the relevant gas-consumption factor.
Comparing actual and estimated gas consumption during CH cycles, 26 September 2024, 18:00–27 September 2024, 09:00
0.97763 is the Actual efficiency
where 29.241 = Heat Output, and 29.91 = Actual Gas Consumption
0.97541 is the Estimated efficiency
where 29.241 = Heat Output, and 29.978 = Estimated Gas Consumption
The estimate was intentionally configured conservatively, but that design choice does not validate the model beyond these specific sample windows.
Comparing actual and estimated gas consumption during CH and DHW cycles, 30 September 2024, 20:50–1 October 2024, 09:30
Gas Smart Meter Data
Estimated Gas Data
Gas Smart Meter Data
Estimated Gas Data
Comparing Actual vs Estimated Gas Consumption results during DHW cycles
DHW cycles operate at higher modulation levels, and additional factor is applied on top of above template, which is:
DHW Gas Consumption = CH Gas Consumption Template Above * 1.12October 2024: Create a dynamic heat-loss sensor in Home Assistant using SAT, 4 October 2024, 22:00–5 October 2024, 10:00
Historical temperature-average observation, 4–5 October 2024
Indoor target temperature is set to 20.50 °C and actual average indoor temperature over this period was 20.51 °C.
Matching averages does not prove instantaneous sensor accuracy or that heat input equalled heat loss at every point in the period.
Actual Gas Consumption based on the data from the smart meter over the specified period of time.
31969.48 - 31945.46 = 24.02 kWh
Average outdoor temperature over the specified period of time
9.48 °C
Calculate average gas consumption over the specified period of time
Heating Start Time: 22:15
Heating Stop Time: 09:45 (following day)
Heating Demand Total Hours = 11 hours and 30 minutes
24.02 kWh / 11.5 = 2.088695652173913 kW or 2088.7 Watts
Given the assumed average watts required to keep the house at 20.5 °C while the outside temperature was 9.48 °C, I used the figure to make an early whole-building proxy. It is not a fabric U-value: floor area is not the relevant envelope area and the calculation includes operational assumptions.
Historical whole-building proxy, not a fabric U-value
The U-value, also known as thermal transmittance, is a measure of how well a building element conducts heat. It quantifies the rate of heat transfer through a material or assembly of materials (like walls, windows, roofs, or floors) per unit area per degree of temperature difference between the inside and outside environments.
In the context of calculating the heat loss of a house, the U-value plays a crucial role in determining how much heat energy is lost through the building's envelope. A lower U-value indicates better insulating properties, meaning less heat is lost and the building is more energy-efficient. Conversely, a higher U-value means the material allows more heat to pass through, leading to higher energy consumption to maintain indoor comfort levels.
The relationship between heat loss and the U-value is expressed by the formula:
{% set Watts = 2088.7 %} #Average Heat Loss
{% set A = 184.87 %} # total floor area in square meters
{% set indoor_temp = 20.51 | float %}
{% set outdoor_temp = 9.48 | float %}
{% set delta_t = indoor_temp - outdoor_temp %}
{% set U = Watts / (A * delta_t) %}
{{ U | round(10) }}
U = 1.0243163692
Create Dynamic Heat Loss sensor
And now, with the U value, we can dynamically calculate the Heat Loss given the indoor and outdoor conditions.
Heat Loss (Watts)=U×A×ΔT
𝑈: U-value (measured in Watts per square meter per degree Kelvin, W/m²·K)
A: Area of the building element through which heat is being transferred (in square meters, m²)
ΔT: Temperature difference between the inside and outside environments (in degrees Celsius or Kelvin)
Jinja Home Assistant Template
{% set U = 1.0243163692 %}
{% set A = 184.87 %} #total floor area in square meters
{% set indoor_temp = 20.51 | float %}
{% set outdoor_temp = 9.48 | float %}
{% set delta_t = indoor_temp - outdoor_temp %}
{{ (U * A * delta_t) | round(3) }}
U * A * delta_t = 2088.7 Watts
Calculate Heat Loss sensor at the design temperature
This calculates the heat loss for the worst case scenario expected during coldest months.
{% set U = 1.0243163692 %}
{% set A = 184.87 %} #total floor area in square meters
{% set indoor_temp = 20.51 | float %}
{% set outdoor_temp = -3.5 | float %}
{% set delta_t = indoor_temp - outdoor_temp %}
{{ (U * A * delta_t) | round(3) }}
U * A * delta_t = 4546.662 Watts
Note 1: This historical exercise is an early whole-building proxy rather than a true fabric U-value. Colder, steady conditions may be more informative, but do not remove the limitations of gas attribution, area choice and unmeasured heat output.
Note 2: For your home assistance instance, replace static values with your dynamic sensors where relevant.
What does it mean to calculate Heat Loss at the design temperature?
Calculating heat loss at the design temperature involves determining the maximum amount of heat that will be lost from a building when the outdoor temperature reaches a specific, typically extreme, value known as the design temperature. This calculation is crucial for properly sizing heating systems to ensure they can maintain comfortable indoor temperatures even under the most demanding weather conditions.
What is Design Temperature?
Why Calculate Heat Loss at the Design Temperature?
Long Term Heat Loss Graph
Another run, 11–12 October 2024
Gas Smart Meter usage between 17:17pm and 10:30am = 39.83 kWh, and average consumption 2343.288786 Watts
Between 11 October 2024, 17:15 and 12 October 2024, 10:30
{% set U = 0.9231852047 %}
{% set A = 184.87 %}
{% set indoor_temp = 20.53 | float %}
{% set outdoor_temp = -3.5 | float %}
{% set delta_t = indoor_temp - outdoor_temp %}
{{ (U * A * delta_t) | round(3) }} = 4101.182 Watts or 4.1 kW
This result seems very optimistic, so if we instead, look at data between 20:50pm and 07:30am, with average consumption at 2639.528571 Watts, we get
Between 11 October 2024, 20:50 and 12 October 2024, 07:30
{% set U = 0.9792698918 %}
{% set A = 184.87 %}
{% set indoor_temp = 20.5 | float %}
{% set outdoor_temp = -3.5 | float %}
{% set delta_t = indoor_temp - outdoor_temp %}
{{ (U * A * delta_t) | round(3) }} = 4344.903 Watts or 4.3 kW
28 October 2024: Random quality check to verify that estimated gas consumption ≤ actual gas consumption
Actual
13.66
Estimated
13.594
22 February 2025: A note for people interested in SAT and an OpenTherm gateway
Please note that I still experiment with SAT and so when you look at the graphs, sometimes you might see they are quite messy. I made small modifications to the code, but for the best results, please use the official release without modifications.
Appendix: complete 146-row comfort table, 19 April 2025
The data below covers the coldest period of winter 2024/2025: 1 January 2025, 00:00–19 February 2025, 23:59.
Appendix: installation changes, August 2025 radiator and fan upgrade
Appendix: installation changes, August 2025 Danfoss RA-DV valves
Danfoss RAS-C2, RA-DV and RLV product listing
Danfoss auto-balancing valve video
27 September 2025: Updated Home Assistant sensors for estimated gas consumption and heat output
See Heatlytics for more details and the Home Assistant Jinja templates I used. In addition, I use separate CH and DHW gas-consumption coefficients for real-world inefficiencies, manually comparing and adjusting them against smart-meter data.
2 October 2025: Updated heat loss using the [HeatPumpMonitor heat-loss methodology](https://heatpumpmonitor.org/heatloss)
See the HeatPumpMonitor heat-loss method and OpenEnergyMonitor measured heat-loss guidance for more details.
No DHW influence, only CH.
Appendix: full Kalman/PyScript code, 22 October 2025
I use the following room temperature sensor Xiaomi LYWSD03MMC
The graph shows a historical small target-to-reading difference, likely most clearly overnight. The roughly 0.03 °C resolution/noise observation is not a calibrated accuracy claim.
On the graph, it can be seen as the blue "unfiltered" line.
The following PyScript (HACS integration) smooths the signal for control/display and deals with spikes; it does not make the Xiaomi sensor more accurate without a calibrated reference.
The "red" line on the graph is the filtered room temperature, based on the python script below.
25 January 2026: Calculating heat loss after radiator upgrade and comparing previous estimates
Before radiator upgrade (approximately 4.2 kW):
After radiator upgrade (3.98 kW, latest estimate): The emitter upgrade altered heat-emitter capacity, not building fabric heat loss; this remains a later estimate with uncertainty.
Appendix: July 2026 DHW daily evidence and formulas
The local workbook's July history supplies the following daily sensor values. They are shown to three decimal places for readability;
zeromeans a present zero-valued day, not a missing row.The exact unrounded July totals are 75.762180 kWh immersion input, 109.855161 kWh gas comparator and 34.092981 kWh difference. At the fixed 1.45 multiplier, the arithmetic residual is zero.
The formulas are
Q_proxy = E_immersion;G_model = E_immersion / 0.689655... = 1.45 × E_immersion;Delta_input = G_model - E_immersion; andreduction = Delta_input / G_model.Every July row is sourced as
ha-history-daily, withlatest-daily-totaland qualityobserved. Here, observed means sensor-recorded, not independently calibrated.The longer 5 April–31 July view is partial coverage only: 78 of 118 days were usable and 40 were missing. Its partial sum is 266.838 kWh immersion input, 386.915 kWh modelled gas and 120.077 kWh difference; it is not a period total.
All reactions