mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-06-08 11:17:27 +00:00
Contains projects associated to the development of modeling products
e509ffdef4
SAP 10.2 Table 4e (PDF p.172-173) "Heating system controls", GROUP 2:
HEAT PUMPS WITH RADIATORS OR UNDERFLOOR HEATING:
Code Description Type
---- ------------------------------------------------- ----
2201 No time or thermostatic control 1
2202 Programmer, no room thermostat 1
2203 Room thermostat only 1
2204 Programmer and room thermostat 1
2205 Programmer and at least two room thermostats 2
2206 Programmer, TRVs and bypass 2
2207 Time + temp zone control by plumbing/electrical 3 ← cert 000565
2208 Time + temp zone control by PCDB device 3
2209 Room thermostat and TRVs 2
2210 Programmer, room thermostat and TRVs 2
Pre-S0380.87 `_CONTROL_TYPE_BY_CODE` contained only Group 1 BOILER
codes (21XX); every Group 2 HP code (22XX) fell through to the
default `return 2`. Cert 000565 lodges `main_heating_control=2207`
on its HP main 1 → silently routed to type 2 → MIT_elsewhere
over-counted by ~+0.5 °C in winter.
The bug: SAP 10.2 Table 9 (PDF p.182) elsewhere off-hours differ
between type 2 and type 3:
Type 1, 2: off-hours (7, 8) — elsewhere heated longer
Type 3: off-hours (9, 8) — elsewhere has separate, shorter
heating schedule per §9.4.14
Wrong control type → wrong off-hours → wrong off-period temperature
reduction (Table 9b) → wrong MIT_elsewhere (line (90)m) → wrong
blended MIT (line (92)/(93)m) → wrong space heating demand
(line (98c)).
Diagnosis chain: post-S0380.86 cert 000565 had structural SH
over-count of +7924 kWh independent of fabric. Diff vs worksheet
intermediates traced it to MIT cascade higher by avg +0.45 °C
(+5.42 °C-months). Per-zone breakdown showed MIT_elsewhere over by
+6.25 °C-months while Th2 setpoint matched. Reverse-engineered the
off-period reduction (cascade u≈4.12 vs worksheet u≈5.14, Jan)
matched off-hours (9, 8) — control type 3 — vs cascade (7, 8) —
control type 2. Verified against Table 4e GROUP 2 spec text:
2207 → type 3 spec-correct.
Cohort + golden + cert 9501 unaffected:
- Elmhurst U985 cohort (000474..000516): all lodge code 2106
(Group 1, type 2) — unchanged
- 20 golden API certs lodge code 2206 (Group 2 HP, type 2 per
spec, type 2 via cascade default) — adding 2206:2 to the
dispatch dict makes the type explicit, behaviour unchanged
- Cert 9501: not lodging 22XX codes
- Only cert 000565 lodges 2207 (and exercises the 22XX→3 fix)
Test (1 new, AAA-structure parametrised across all 10 Group 2 codes
in `test_cert_to_inputs.py`).
**Cert 000565 closure (post-S0380.87 vs post-S0380.86):**
Pin Pre Post Δ worksheet
--- ---- ---- --- ---------
sap_score 23 27 +4 29
sap_score_continuous 22.64 27.35 +4.71 28.51
ecf 6.02 5.51 -0.51 5.39
total_fuel_cost_gbp 5233 4784 -449 4680
co2_kg_per_yr 7165 6581 -584 6448
space_heating_kwh 66932 60468 -6464 59008
main_heating_fuel 39372 35570 -3802 34711
Space heating residual closed +7924 → **+1460 (82% closed)**.
Integer SAP closed Δ-6 → Δ-2 (was the 9th-largest residual; now
gates only on continuous SAP rounding boundary at 28.5).
Test baseline: 561 pass (was 560 + 1 new) + 9 expected
`test_sap_result_pin[000565-*]` fails unchanged. Pyright net-zero
per touched file. SAP 10.2 spec citation included in dispatch dict
comment per [[feedback-spec-citation-in-commits]].
Per [[feedback-spec-floor-skepticism]] + [[feedback-verify-handover-claims]]:
the handover post-S0380.86 listed several candidate SH-channel
root causes (solar gains, internal gains, η, T_int, ventilation).
The single-line spec-dispatch gap was the dominant driver. The
remaining +1460 kWh residual splits roughly: ~+750 kWh from HLC
over-count (+42 W/K, mostly ventilation +27 W/K), ~+700 kWh from
remaining MIT residual.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
||
|---|---|---|
| .devcontainer | ||
| .github/workflows | ||
| .idea | ||
| .vscode | ||
| applications | ||
| asset_list | ||
| backend | ||
| backlog | ||
| datatypes | ||
| deployment/terraform | ||
| docs/adr | ||
| domain | ||
| epr_data_exports | ||
| etl | ||
| infrastructure | ||
| model_data/requirements | ||
| orchestration | ||
| recommendations | ||
| repositories | ||
| scripts | ||
| sfr/principal_pitch | ||
| survey_report | ||
| tests | ||
| utilities | ||
| utils | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| __init__.py | ||
| ara_backend_design.md | ||
| BaseUtility.py | ||
| CLAUDE.md | ||
| conftest.py | ||
| CONTEXT.md | ||
| devcontainer.sh | ||
| Dockerfile.test | ||
| Dockerfile.test.dockerignore | ||
| Makefile | ||
| MEMORY.md | ||
| package-lock.json | ||
| package.json | ||
| pyproject.toml | ||
| pyrightconfig.json | ||
| pytest.ini | ||
| README.md | ||
| run_lambda_local.sh | ||
| serverless.yml | ||
| test.requirements.txt | ||
| tox.ini | ||
| UBIQUITOUS_LANGUAGE.md | ||
Model Repository
This repository contains the code pertaining to the development of the data science and machine learning products being utilised by Hestia.
The different folders in this repository relate to services that can be used independently, or can be imported and used as part of a larger application
Getting Started
Prerequisites
Dev Container Setup
This repo uses a Docker Compose-based dev container. The model-backend service joins a shared-dev Docker network so it can communicate with other local services (e.g. a frontend container) running on your machine.
VS Code users: The initializeCommand in devcontainer.json creates the shared-dev network automatically before the container starts. No manual step required — just open the repo and select Reopen in Container.
Non-VS Code / CI workflows: Run the following once before starting the container:
make dev-setup
This is idempotent and safe to re-run if the network already exists.
Folders
backend/
This folder contains the code for the fastapi backend service, which provides an interface to much of the functionality in this repository, for the frontend
model_data/
This folder contains related to the reading and preparation of assessment model data, including pulling out epc attributes
Testing
All tests can be run, against the configuration in pytest.ini running
pytest
This will run the complete panel of tests and report on coverage in the locations specified by the pytest.ini file.
To run tests in a specific service, e.g. inside of model_data, simply run
pytest --cov-config=model_data/.coveragerc --cov=model_data
This will produce the test results and coverage reports