Per-system heat feed provenance (register vs computed) and metering_boundary_code derivation — for an open analysis of measured vs declared performance

Hardware
,
1

Hello,

I’m doing an independent analysis of heat pump field performance using the public heatpumpMonitor API, comparing measured seasonal performance against manufacturers’ declared SCOP values, normalised for actual operating conditions (second-law / Carnot-fraction approach, similar in spirit to the EoH analysis on this site). Method and code will be published openly, heatpumpMonitor credited as the source — and I’d genuinely welcome the community’s review of the method before anything is published.

I’ve read the earlier thread “COP calculation during defrost cycle”, which answers the general convention: cumulative registers on standard heat meters accumulate heating only, while COP computed from the instantaneous feeds can include negative defrost heat, and there’s no standard approach across systems yet. Building on that, three questions I can’t resolve from the public API:

1. Per-system heat feed provenance. Is it recorded anywhere (even internally) whether a given system’s heat energy derives from (a) the heat meter’s cumulative energy register — heating-only, floored at zero — or (b) heat computed from flow rate and ΔT, which can go negative during defrost? For a fair cross-system comparison this distinction matters: the same machine would score slightly differently under the two conventions, and if the convention correlates with anything (meter model, installer, brand integration) it becomes a systematic bias. If it isn’t recorded, would a survey field be worth adding? Happy to help with that.

2. How is metering boundary code derived ? I classified all public systems independently against SEPEMO boundaries using the published metering inc * flags, and disagree with metering boundary code on 136 of them. One direction I can explain (71 code-3 systems have distribution pumps metered; 66 code-4 systems appear to lack controls metering), the other I can’t. Is the code computed from non-public fields, or manually assigned by system owners? For now I’m using the conservative intersection (536 systems H4 under both readings) and will report the disagreement openly — but knowing the derivation would let me align rather than guess.

3. Outdoor temperature resolution. Many systems log energy at 10 s but outdoor temperature hourly. Is hourly outdoor a configuration default (and changeable), or typically an external-source limitation (e.g. nearby weather station)? I’ve quantified the effect of hourly-vs-native outdoor data on condition-normalised results using the systems that have both, and I’m happy to share that analysis here if it’s useful to others.

Thanks for building and maintaining this — it’s a rare public resource, and this analysis simply isn’t possible without it.

2

Great to hear that you are doing this @Vincent.

After a bit of a break from this side of things I’m also back trying to improve on our HeatpumpMonitor data analysis. I’ve attached a Claude based regression analysis you might find interesting regression.zip (20.0 KB). I’m a bit embarrassed that even with all this data we still dont have a solution that can predict the performance of each system on the site to better than e.g R² 0.630 (weighted flowT-outsideT combined with utilisation factor) or CV-R² 0.56 using measurements that are slightly more intuitive and more relatable to design stage variables such as measured_mean_flow_temp_coldest_day or (lift + ln(utilisation) + DHW fraction) I would love to hear your thoughts on how we can improve on this!

To your questions:

1. Per-system heat feed provenance. Yes all the metrics such as combined_heat_kwh are integrated from the power register data from the heat meters themselves (for MID-metered systems), the power register data does go negative on defrosts and so is not affected by the heat only energy registers on the heat meters. Doing a quick check now I did notice ~5 systems that were still not showing negative heat on defrosts and have added data error flags to those so that they are flagged as having that issue.

2. How is metering boundary code derived ? The code that derives the boundary code can be found here heatpumpmonitor.org/www/Modules/system/system_view.php at main · openenergymonitor/heatpumpmonitor.org · GitHub.

The reason we dont require monitoring of the indoor controller for all systems on H4 is that we noticed early on that Vaillant Arotherm+ indoor controller only used about 1W of electrical power which only makes about a 0.01 SPF difference and so is not worth the cost of an additional electric meter to record. The Grant R290 indoor controller is similar at ~3W, both are roughly an order of magnitude less than the potential metering error from the electric and heat meters e.g Heat meter accuracy testing - #6 by TrystanLea. I noticed reviewing a few systems now that some of the Viessmann units had not ticked the box even though we can see on the backend feeds that they had the indoor controller metered so have corrected those. Thinking about it I think we could actually improve on this and have a standarised way of dealing with the case of known negligible power indoor controllers. E.g have an option to add additional small power draws manually as a constant value and have a list of what we expect those to be for applicable makes and models.

Looking at the H3 systems, there are a lot of H3 systems with hydraulic separation but no metering of secondary distribution pumps hence H3.

I notice your total numbers of systems 66 code4 systems without control metering and 71 code3 systems are larger than the totals I get. I assume you are quoting numbers for all systems including those that are not mid metered or/and have metering errors? I would recommend filtering out all non mid-metered systems in your analyses.

3. Outdoor temperature resolution. Most of the hourly outdoor temperature data is from the MetOffice weather data API. Higher resolution outdoor temperature data indicates a local sensor at the home.

Good to hear, let us know how you get on! would love to hear if you can make any headway on the performance prediction challenge!

3

I usually apply the following filters for systems that I use in any of the annual value based analyses:

  • MID metered
  • H4 boundary
  • 330 days of data (last 365 days)

267 Systems: https://heatpumpmonitor.org/system/list?filter=query:metering_boundary_code:4:eq:t

229 Systems without active cooling: https://heatpumpmonitor.org/system/list?filter=query:cooling_heat_kwh:1:lt:t,metering_boundary_code:4:eq:t

If your interested in other things other than the pre-calculated stats on an annual basis, e.g consumption profiles, behavior over shorter periods etc, then expanding the range of systems makes a lot of sense of course.

4

Thanks Trystan — all three answers were more useful than we could have asked for, and two of them changed our analysis in ways I’ll show below. This reply delivers the sensitivity analysis promised in the first post, plus a contribution aimed squarely at Tier 1, item 1 of your regression write-up: the declared-performance lookup table.

1. Declared-value table — attached as CSV

Since your analysis names “join declared unit performance” as the biggest single lever, here is ours to use: 34 ErP-grade rows covering 25 machines across six manufacturers (Vaillant, Daikin, Viessmann, Grant, Samsung, Mitsubishi), one row per (variant, source) so that two documents about the same machine stay visible as two rows rather than being averaged. Each row carries SCOP at both applications (published, or derived from EPREL ηs with the derivation basis recorded), rated output, source type, source URL, retrieval date, and EPREL registration ID where we hold one — the EPREL fiches at https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_{id}_EN.pdf are public static PDFs (each CSV row carries its full ready-made URL), which makes every such row independently checkable. Every Vaillant, Grant and Samsung primary row is now EPREL-sourced with its registration ID and fiche URL.

Three honesty flags travel with the table, and they matter more than the row count:

  • 16 rows currently rest on a single document, marked as such.
  • 6 rows are missing source URLs — five are second-source rows from a working document whose original URL was never captured (kept because they carry the published SCOPs that pin the ηs→SCOP conversion), plus one manufacturer datasheet; all marked.
  • One row’s figures match no current registration: our earliest 55/6 source gives a low-temperature figure (ηs 177) that appears in none of that model’s four EPREL registrations (181–183, and one at 130 — see §3). It is flagged unmatched to register and neither averaged in nor used as corroboration.
  • The rows sit on two distinct declaration bases. Computing the implied medium-temperature part-load water schedule from each row’s own SCOP35/SCOP55 (or ηs) ratio, the table splits into two clusters roughly 3–4 K apart — and both appear entirely lawful: 813/2013 fixes the design point only, Annex III permits “other reliable, accurate and reproducible methods”, and EN 14825’s Annex F is informative. We tested and eliminated registration vintage, ID-block ordering, transcription error and fixed-outlet declarations against these same rows (the Grant family was decisive: five variants, one supplier, one market date, both conventions present). So this is a comparability note, not a claim about anyone: two rows from different makers — sometimes the same maker — are not automatically on the same footing, and a naive join of declared values onto measured systems will inherit that scatter. The convention column classifies each row so a join doesn’t have to.

One self-caution we’d want any user of the table to see: the consistency check behind that column uses our reading of EN 14825’s water-temperature schedules, which we haven’t yet verified against the purchased standard. A row can sit away from our value because our schedule is wrong just as easily as because the row is.

2. The outdoor-resolution sensitivity analysis (promised in the first post)

On the 43 systems with everything at ≤15 minutes, we computed the condition-normalised fraction twice over identical intervals — native outdoor resolution vs the same series down-sampled to hourly means — with thresholds fixed before any number existed. Result, over the 40 systems that produced a paired measurement: median Δ −0.025%, 95th percentile 0.161%, 36 of 40 moving negative (the direction predicted in advance: hourly averaging smooths cold excursions, and heat is delivered disproportionately during them). So hourly outdoor resolution costs ~0.03% — practically nothing.

Two limitations on the record: the manufacturer-correlation check passes (permutation p = 0.165) but is underpowered at this n; and your answer that hourly series are MetOffice API data means we tested resolution when the live question is location — a house sensor vs a remote grid. We’re measuring that now, same paired design, using gridded reanalysis at each site’s coordinates.

A side-finding possibly more useful than the headline: 21 of those 40 best-instrumented systems fall below a 95%-complete threshold on the season used. It can’t bias a paired comparison (a gap removes the interval from both passes), but it suggests completeness bites harder than expected even at the well-maintained end — consistent with why your standard filter carries the 330-day rule.

3. Register observations collected along the way

Pinning our Vaillant rows to exact registrations meant reading the whole family’s entries, and a few things in the register itself seem worth passing on, all stated as observations only:

  • Two registrations declare low-temperature ηs equal to medium-temperature — VWL 55/6 A 230 V S3 (1789022, 130/130) and VWL 105/6 A S2 (1062793, 142/142) — while their sibling registrations declare 181–199 at low temperature. That pattern looks like a data-entry defect in the registrations rather than a machine property.
  • One model appears registered twice with only a whitespace difference in the identifier (1844396 “VWL 55/6 A 230V” and 1805174 “VWL 55/6 A 230 V”, identical figures), and one nameplate (VWL 155/6) is registered at two slightly different figure-sets (187/143 and 186/143), each of those twice.

None of this affects the platform, but anyone joining EPREL data by model string will meet it.

4. A small reproducible detail in calculate boundary ()

While aligning our boundary classification with yours we reproduced calculate boundary () from system_view.php — it matches on 781/781 public systems and 312/312 rows of the July all-fields export, and your published regression table reproduces step-for-step on that export too, which was reassuring in both directions. The one detail worth reporting: value(`hydraulic separation`, `None`) defaults on null only, so an empty string (an unanswered survey field) reads as having hydraulic separation, and combined with unmetered secondary pumps it demotes a system from code 4 to 3. Twelve recently-registered systems are demoted by this alone: 1060, 1066, 1081, 1090, 1163, 1171, 1174, 1176, 1179, 1188, 1230, 1238. It costs code-4 systems and admits none, so nothing is flattered by it. We’ve adopted the behaviour as-is in our reproduction — the point of reproducing your function is to agree with it — and either resolution is fine by us: if unanswered should mean unanswered, the fix is one condition; if you’d rather stay strict, we keep matching it.

5. One question — outdoor source for non-UK systems

Our location-error control set includes four systems outside the UK ([193] Switzerland, [436] Netherlands, [462] Denmark, [586] US). The MetOffice doesn’t serve those — is there a second gridded product for non-UK sites, a per-system configuration, or is hourly outdoor simply not filled there? We’ve fixed in advance what we do with either answer (different product → they stay as their own stratum; unknown → we restrict to the 29 UK systems and say so), so this is provenance curiosity, not a request to change anything.

The CSV below, as a PR against whatever schema you’d prefer, or simply as reference material; the Python calculate boundary () reproduction if a second implementation is useful as a regression check; and the location-error analysis when it’s done, in the same form as §2. Asked in return: nothing — the platform is why any of this is possible.

Vincent

declared_values_contribution.csv — click to expand, select all, save as .csv 
manufacturer,model_family,variant,kw_rated,kw_basis,scop35,scop55,etas35,etas55,phi35,phi55,consistency_pct,convention_class,f_basis,source_type,source_url,retrieved,eprel_id,status,flags
Daikin,Altherma 3,EBLA04E3V3,4.3,prated,4.540,3.290,179,129,0.3981,0.3988,+0.2,A (8.265),,data_book,https://www.daikin.eu/content/dam/document-library/catalogues/heat/air-to-water-heat-pump-low-temperature/ebla04ev3/Daikin%20Altherma%203%20M%204-8%20kW_Product%20catalogue_ECPEN22-764_English.pdf,2026-08-05,,,single-sourced
Daikin,Altherma 3,EBLA06E3V3,6,prated,4.520,3.280,178,128,0.3963,0.3976,+0.3,A (8.277),,data_book,https://www.daikin.eu/content/dam/document-library/catalogues/heat/air-to-water-heat-pump-low-temperature/ebla04ev3/Daikin%20Altherma%203%20M%204-8%20kW_Product%20catalogue_ECPEN22-764_English.pdf,2026-08-05,,,single-sourced
Daikin,Altherma 3,EBLA08E3V3,7.5,prated,4.610,3.350,181,131,0.4042,0.4061,+0.5,A (8.288),,data_book,https://www.daikin.eu/content/dam/document-library/catalogues/heat/air-to-water-heat-pump-low-temperature/ebla04ev3/Daikin%20Altherma%203%20M%204-8%20kW_Product%20catalogue_ECPEN22-764_English.pdf,2026-08-05,,,single-sourced
Grant,Aerona HP290,Aerona HPR290i40,4,eprel_prated55,,,200,146,0.4387,0.4422,+0.8,A (8.326–8.386),SOLVED per application from Grant published SCOP on all five variants (F_low 0.0-0.6 mean 0.16; F_med -0.4 to 0.4 mean -0.08),eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_2199863_EN.pdf,2026-08-05,2199863,,eta_s-derived
Grant,Aerona HP290,HPR2904 (i40),4,eprel_prated55,5.000,3.660,,,0.4384,0.4437,+1.2,A (8.349),,manufacturer_datasheet,https://www.grantuk.com/professional/products/air-source-heat-pumps/r290/,2026-08-05,2199863,,
Grant,Aerona HP290,Aerona HPR290i65,7,eprel_prated55,,,203,145,0.4453,0.4392,-1.4,A (8.147–8.210) — at the band edge,SOLVED per application from Grant published SCOP on all five variants (F_low 0.0-0.6 mean 0.16; F_med -0.4 to 0.4 mean -0.08),eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_2222156_EN.pdf,2026-08-05,2222156,,eta_s-derived
Grant,Aerona HP290,HPR29065 (i65),7,eprel_prated55,5.080,3.620,,,0.4454,0.4388,-1.5,A (8.128) — at the band edge,,manufacturer_datasheet,https://www.grantuk.com/professional/products/air-source-heat-pumps/r290/,2026-08-05,2222156,,
Grant,Aerona HP290,Aerona HPR290i90,9,eprel_prated55,,,189,148,0.4146,0.4483,+8.1,B (8.931–8.983),SOLVED per application from Grant published SCOP on all five variants (F_low 0.0-0.6 mean 0.16; F_med -0.4 to 0.4 mean -0.08),eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_2222203_EN.pdf,2026-08-05,2222203,,eta_s-derived; consistency
Grant,Aerona HP290,HPR2909 (i90),9,eprel_prated55,4.740,3.690,,,0.4156,0.4473,+7.6,B (8.879),,manufacturer_datasheet,https://www.grantuk.com/professional/products/air-source-heat-pumps/r290/,2026-08-05,2222203,,consistency
Grant,Aerona HP290,Aerona HPR290i120,11,eprel_prated55,,,190,150,0.4168,0.4544,+9.0,B (9.004–9.054),SOLVED per application from Grant published SCOP on all five variants (F_low 0.0-0.6 mean 0.16; F_med -0.4 to 0.4 mean -0.08),eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_2222208_EN.pdf,2026-08-05,2222208,,eta_s-derived; consistency
Grant,Aerona HP290,HPR29012 (i120),11,eprel_prated55,4.740,3.740,,,0.4156,0.4534,+9.1,B (8.999),,manufacturer_datasheet,https://www.grantuk.com/professional/products/air-source-heat-pumps/r290/,2026-08-05,2222208,,consistency
Grant,Aerona HP290,Aerona HPR290i160,14,eprel_prated55,,,182,133,0.3993,0.4028,+0.9,A (8.335–8.401),SOLVED per application from Grant published SCOP on all five variants (F_low 0.0-0.6 mean 0.16; F_med -0.4 to 0.4 mean -0.08),eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_2222219_EN.pdf,2026-08-05,2222219,,eta_s-derived
Grant,Aerona HP290,HPR290155 (i160),14,eprel_prated55,4.560,3.330,,,0.3998,0.4037,+1.0,A (8.329),,manufacturer_datasheet,https://www.grantuk.com/professional/products/air-source-heat-pumps/r290/,2026-08-05,2222219,,
Mitsubishi,Ecodan,PUZ-WM112VAA,11.2,prated,4.780,3.340,191,134,0.4191,0.4049,-3.4,⚠ anomaly — second source required (7.970),,manufacturer_datasheet,,2026-08-05,,,single-sourced; consistency; no-source-URL
Samsung,EHS Mono R290,AE050CXYDEK,5,eprel_prated55,,,201,141,,,,⚠ below A (8.001–8.067),UNSOLVED - no Samsung ErP-grade SCOP-eta_s pair found for the CXYD series; secondary retail sources quote SCOP35 5.10 (implies F_low 3.0) and the sibling AE080 4.8 (implies F_low 1.0) which are mutually inconsistent at published precision. D-28 forbids assuming one.,eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1853015_EN.pdf,2026-08-06,1853015,,single-sourced; eta_s-derived
Samsung,EHS Mono R290,AE080CXYDEK,8,eprel_prated55,,,191,139,,,,A (8.300–8.364),UNSOLVED - see the AE050 row; F is a family property and neither variant pins it.,eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1853014_EN.pdf,2026-08-06,1853014,,single-sourced; eta_s-derived
Vaillant,aroTHERM+,VWL 55/6 A 230V,4.2,prated_it_retained,,,183,130,0.4075,0.4034,-1.0,A (8.102–8.173) — at the band edge,"family mean of the four variants that do pair (F_low 2.8-3.0, F_med 3.0-3.2); this variant has NO usable SCOP-eta_s pair because the Italian fiche's 177 is unmatched to any registration",eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1844396_EN.pdf,2026-08-06,1844396,primary,single-sourced; eta_s-derived
Vaillant,aroTHERM+,VWL 55/6 A S3,4.2,prated,4.500,3.320,177,130,0.3945,0.4025,+2.0,A (8.415),,product_fiche_it,,2026-08-05,,unmatched_to_register,single-sourced; no-source-URL; unmatched-to-register
Vaillant,aroTHERM+,VWL 65/6 A 230V S3,5.1,prated_it_retained,,,186,136,0.4138,0.4219,+1.9,A (8.340–8.404),solved from this variant's own published SCOP 4.72/3.48 against registered eta_s 186/136,eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1062855_EN.pdf,2026-08-06,1062855,primary,eta_s-derived
Vaillant,aroTHERM+,VWL 65/6 A S3,5.1,prated,4.720,3.480,186,136,0.4138,0.4219,+1.9,A (8.409),,product_fiche_it,,2026-08-05,1062855,second_source,no-source-URL
Vaillant,aroTHERM+,VWL 85/6 A 230V S3,7.8,prated_it_retained,,,187,135,0.4165,0.4182,+0.4,A (8.234–8.300),solved from this variant's own published SCOP 4.75/3.45 against registered eta_s 187/135,eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1844409_EN.pdf,2026-08-06,1844409,primary,eta_s-derived
Vaillant,aroTHERM+,VWL 85/6 A S3,7.8,prated,4.750,3.450,187,135,0.4165,0.4182,+0.4,A (8.284),,product_fiche_it,,2026-08-05,1844409,second_source,no-source-URL
Vaillant,aroTHERM+,VWL 105/6 A 230V S2,9,eprel_prated55,,,197,142,0.4384,0.4395,+0.2,A (8.221–8.285),solved from siblings VWL 85/6 and VWL 155/6 (F=3.00 in both applications),eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1062890_EN.pdf,2026-08-05,1062890,primary,single-sourced; eta_s-derived
Vaillant,aroTHERM+,VWL 125/6 A S3,11.6,prated,5.070,3.680,200,144,0.4445,0.4461,+0.4,A (8.279),,product_fiche_it,,2026-08-05,1062787,second_source,no-source-URL
Vaillant,aroTHERM+,VWL 125/6 A S3,11.6,prated_it_retained,,,200,144,0.4445,0.4461,+0.4,A (8.212–8.275),solved from this variant's own published SCOP 5.07/3.68 against registered eta_s 200/144,eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1062787_EN.pdf,2026-08-06,1062787,primary,eta_s-derived
Vaillant,aroTHERM+,VWL 155/6 A 230V S3,14.3,prated_it_retained,,,187,143,0.4165,0.4425,+6.2,"decl_schedule — B on both registered declarations, marginally on this one (D-34) (8.722–8.778)",solved from this variant's own published SCOP 4.75/3.65 against registered eta_s 187/143,eprel,https://eprel.ec.europa.eu/fiches/spaceheaters/Fiche_1844414_EN.pdf,2026-08-06,1844414,primary,eta_s-derived; consistency
Vaillant,aroTHERM+,VWL 155/6 A S3,14.3,prated,4.750,3.650,187,143,0.4165,0.4425,+6.2,"decl_schedule — B on both registered declarations, marginally on this one (D-34) (8.764)",,product_fiche_it,,2026-08-05,1844414,second_source,consistency; no-source-URL
Viessmann,Vitocal 150-A,AWMOF-151.A1.08-230-V002 (6 kW),6,eprel_prated55,,,175,141,0.3902,0.4364,+11.9,B (9.190–9.239),"SOLVED per application from Viessmann's own technical guide, which prints eta_s and SCOP for the same types on one page (F_low 2.8-3.0; F_med 3.0). Viessmann sits in the Vaillant/Daikin F convention",eprel,https://eprel.ec.europa.eu/screen/product/spaceheaters,2026-08-05,,,single-sourced; eta_s-derived; consistency
Viessmann,Vitocal 150-A,AWMOF-151.A1.10-230-V002 Modular (9 kW),9,eprel_prated55,,,190,145,0.4230,0.4485,+6.0,⚠ between clusters (8.704–8.760),"SOLVED per application from Viessmann's own technical guide, which prints eta_s and SCOP for the same types on one page (F_low 2.8-3.0; F_med 3.0). Viessmann sits in the Vaillant/Daikin F convention",eprel,https://eprel.ec.europa.eu/screen/product/spaceheaters,2026-08-05,,,single-sourced; eta_s-derived; consistency
Viessmann,Vitocal 150-A,AWMOF-151.A1.10-400-V001 (9 kW),9,eprel_prated55,,,199,156,0.4428,0.4819,+8.8,B (8.941–8.990),"SOLVED per application from Viessmann's own technical guide, which prints eta_s and SCOP for the same types on one page (F_low 2.8-3.0; F_med 3.0). Viessmann sits in the Vaillant/Daikin F convention",eprel,https://eprel.ec.europa.eu/screen/product/spaceheaters,2026-08-05,,,single-sourced; eta_s-derived; consistency
Viessmann,Vitocal 150-A,AWO-E-AC 151.A10,9,eprel_prated55,4.825,3.700,190,145,0.4230,0.4485,+6.0,⚠ between clusters (8.746),,technical_guide,https://viessmanndirect.co.uk/files//d9882b61-18c6-42a1-82ff-bba528bf2a8b/Technical%20Guide.pdf,2026-08-05,,,single-sourced; consistency
Viessmann,Vitocal 150-A,AWMOF-151.A1.13-400-V002 (12 kW),12,eprel_prated55,,,194,155,0.4318,0.4789,+10.9,B (9.113–9.159),"SOLVED per application from Viessmann's own technical guide, which prints eta_s and SCOP for the same types on one page (F_low 2.8-3.0; F_med 3.0). Viessmann sits in the Vaillant/Daikin F convention",eprel,https://eprel.ec.europa.eu/screen/product/spaceheaters,2026-08-05,,,single-sourced; eta_s-derived; consistency
Viessmann,Vitocal 150-A,AWO-E-AC 151.A13,12,eprel_prated55_crossref,4.520,3.600,178,141,0.3963,0.4364,+10.1,B (9.084),,technical_guide,https://viessmanndirect.co.uk/files//d9882b61-18c6-42a1-82ff-bba528bf2a8b/Technical%20Guide.pdf,2026-08-05,,,single-sourced; consistency
Viessmann,Vitocal 150-A,AWO-E-AC 151.A16,13,eprel_prated55_crossref,4.525,3.600,178,141,0.3967,0.4364,+10.0,B (9.074),,technical_guide,https://viessmanndirect.co.uk/files//d9882b61-18c6-42a1-82ff-bba528bf2a8b/Technical%20Guide.pdf,2026-08-05,,,single-sourced; consistency

PS: New accounts can’t attach files here yet, so the CSV is inline below; happy to supply a proper file or PR once the account can

5

Thanks @Vincent

I will look into that, thanks!

The met office API does serve these as well, we use the following API, it’s a paid for service:

https://data.hub.api.metoffice.gov.uk/sitespecific/v0/point/hourly?excludeParameterMetadata=true&includeLocationName=false&latitude=".$lat."&longitude=".$lon;

an important note is that in order to reduce API costs, we use shared locations, e.g nearest town. So multiple systems will get the same weather data from a single location. This will usually be within a few miles.

Thanks for the EPREL data, I will read up on that and see if I can make use of it!

6

Thanks Trystan — that answered it completely, and the Met Office note
turned out to be the most consequential thing in your reply.

The shared-location detail changed our analysis materially, so it’s
worth reporting back what it does. Clustering the systems by identical
outdoor series, 63 of 133 hourly-outdoor systems in our sample share a
feed across 23 clusters, with a median maximum separation of 27 km
inside a cluster and one cluster spanning 244 km. Comparing the
platform’s outdoor series against ERA5-Land reanalysis at each site’s
own coordinates, the typical effect on a condition-normalised
efficiency is small — median 1.4%, 95th percentile 4.7%. So on average
the input is close.

The part worth your attention: that residual error is not
independent of manufacturer at this sample size (permutation
p ≈ 0.04, with groups as small as n = 3). We’re treating that as
provisional rather than established — the groups are small — but the
mechanism is plausible and unglamorous: shared locations are
geographic, installers work geographically, and installers tend to fit
particular brands. It doesn’t say anything about any manufacturer’s
machines; it says brand-level comparisons drawn from this data can
inherit a weather-siting artefact. It bears on any per-manufacturer
residual analysis, including the one in your own write-up, which is
why I’d rather flag it early than sit on it.

Consequence for us: we’ve restricted our own ranking sample to
systems with local outdoor sensors and are writing the weather finding
up properly, with the method and thresholds fixed in advance. Happy to
share the full analysis when it’s done, in the same form as the
sensitivity summary.

One small thing that would help everyone downstream, if it’s ever
cheap to do: storing the observed series rather than (or alongside)
the forecast one going forward would remove this whole error class for
future analyses. And if the EPREL table is useful, I’m glad to help
with the join — the model-string matching has a few traps in it that
took us a while to find.