pti/blubgo
Watch
1
0
Fork
You've already forked blubgo
 0
Code Issues 7 Pull requests Projects Releases Packages Wiki Activity Actions

Analyse tracking error, and overrun time vs outdoor temperature and sun (Open-Meteo) #8

New issue
Open
opened 2026-10-28 09:54:19 +01:00 by pti · 3 comments
pti commented 2026-10-28 09:54:19 +01:00
Owner

Question

How well does blub track the target temperature, and what is systematic about the error? In particular, do outside temperature and sun through the windows explain how the heating responds? If so, is it worth adding outdoor sensors (e.g. a small zigbee weather station) to compensate for them?

Terms as in GLOSSARY.md; the approach is in docs/adr/0001-on-off-control-with-anticipation.md.

Background

The goal is a small tracking error without a systematic bias: the control temperature close to the target temperature, outside warm-ups and cool-downs. Users adjust targets by feel, but they look at the graphs and will notice systematic surprises. Overshoot (peak above target) and undershoot (trough below target) are symptoms. The band's width (hysteresis) and offset, and the anticipation, are tuning parameters for that outcome.

Anticipation switches off early by the predicted overrun: rise rate × learned overrun time. The overrun time is learned from each coast.

While heating, the rise rate is roughly (heater power − UA·(T_in − T_out) + solar gain) / heat capacity. The anticipator measures that rate live, so the current outdoor conditions are already in it. Outdoor data could help with the overrun time, which is learned from past coasts:

  • Cold days should lose more heat during the coast, so a smaller overrun and a shorter overrun time.
  • Sun during the coast keeps the temperature rising beyond what the radiators explain, so that coast's overrun time is over-estimated.

The fall rate (heater off) is much slower than the rise rate (heater on). That is why switch-on is not anticipated for now: undershoot ≈ fall rate × warm-up delay stays small.

The first measured coast (2026-10-28, buros sensor): overrun +0.48 °C after switch-off at 2.25 °C/h, so an overrun time of about 13 min. The peak was 1.1 °C above target.

Data already recorded

  • GET /api/history/anticipation?start=…&end=…:
    • samples: one per control tick during a heating cycle or a coast (rise rate, predicted overrun, overrun time, peak so far)
    • coast_records: one per learned coast (switch-off temp/time, rise rate, peak/time, measured/previous/new overrun time, settled)
  • GET /api/history/export/json: all sensor readings, including off periods
  • GET /api/history/heating: heater on/off changes with reasons

Winter data, 2025-12 to 2026-02: blub's database also holds about 136k readings from January–February 2026. These are mostly the bathroom DS18B20 at 30 s intervals, plus sparse buros readings. There are also about 670 heater on/off changes, and heating events recording the target temperature at the time. There are no coast records from then, because anticipation didn't exist yet. The fall rate, the rise rate and the overrun per heating cycle can still be analysed against the weather from that period, so the analysis can start before end of November.

The API serves at most 30 days per request. Nothing is deleted yet (retention cleanup is not wired up).

Analysis outline

  1. Tracking error: on the control temperature only (not each sensor), outside warm-ups and cool-downs:
    • bias (mean error) and spread (RMS)
    • per time of day and per schedule block
    • overshoot per heating cycle and undershoot per warm-up
  2. Warm-ups: how long each warm-up takes after a target rise, as input for a possible later "start early" feature.
  3. Outdoor data: get hourly outdoor temperature and solar radiation (temperature_2m, shortwave_radiation, also direct_radiation/diffuse_radiation) for the house from the Open-Meteo archive API. It's free and needs no key. The home coordinates still need to be supplied.
  4. Join: pair each coast record with outdoor conditions at switch-off and averaged over the coast (switch_off_at … peak_at).
  5. Overrun time vs weather: regress measured_overrun_time (and the prediction miss peak − (switch_off_temp + rise_rate × previous_overrun_time)) against T_in − T_out and solar radiation. Check whether the residual spread matters compared with the tracking error.
  6. Fall rate vs weather: regress the fall rate while the heater is off against T_in − T_out. This gives the heat loss coefficient (UA/C) from many more hours than the coasts provide. Daytime off periods that cool slower than predicted measure the solar gain.
  7. Rise rate vs weather: the same regression on the rise rate during heating cycles, to confirm the physical model and how much it differs from the fall rate.
  8. Tuning: from 1–7, choose the band offset and hysteresis by hand for the smallest tracking error without bias. Automatic tuning only if the bias proves stable but drifts with the season.

Watch out for

  • Sensor quantization: the buros sensor reports in ~0.31 °C steps, so each measured overrun time is noisy (overrun ≈ 0.5 °C). Expect to need 30–60 coasts for a fit with two variables. A hysteresis below the step size would make switching erratic.
  • Schedule confounding: morning heating cycles are always cold and sunless, evening ones follow a day of sun. Compare like-for-like times of day, or include time of day as a variable.
  • Coasts not recorded: coasts cut short by the next heating cycle before the peak, or with a rise rate below 0.1 °C/h at switch-off, are skipped.
  • Solar geometry: Open-Meteo radiation is on a horizontal surface, not the window's orientation, so expect a weaker solar correlation than a window sensor would show.

Decision

  • Outdoor conditions clearly explain the overrun time variation: add outdoor sensing and make the overrun time (or predicted overrun) depend on it.
  • They don't: keep the learned overrun time as is. Consider smoothing it more instead, or recording samples only when a sensor reports.
  • Either way: set the band offset and hysteresis from the tracking error analysis.

Proposal if sensors are worth it

  • Outdoor temperature: a zigbee temperature sensor outside, read over MQTT. It is a separate input to the control, never part of the control temperature.
  • Sun: a zigbee illuminance (lux) sensor on the inside of the main window. It probably tracks solar gain through that window better than a horizontal radiation figure. Note that lux sensors saturate in direct sun.
  • Glossary: these become their own terms (e.g. outdoor temperature) once they exist.

Prerequisites

  • Commit and deploy the anticipation instrumentation (anticipation_samples / coast_records): ecf8097, deployed 2026-10-28 10:00
  • Let it collect until end of November (~3–4 weeks, aiming for 30+ coasts)
  • Supply the home coordinates for Open-Meteo (supplied privately, kept out of this public issue; Antwerp area; windows face SSW and WNW)
## Question How well does blub track the target temperature, and what is systematic about the error? In particular, do outside temperature and sun through the windows explain how the heating responds? If so, is it worth adding outdoor sensors (e.g. a small zigbee weather station) to compensate for them? Terms as in `GLOSSARY.md`; the approach is in `docs/adr/0001-on-off-control-with-anticipation.md`. ## Background The goal is a small **tracking error** without a systematic bias: the control temperature close to the target temperature, outside warm-ups and cool-downs. Users adjust targets by feel, but they look at the graphs and will notice systematic surprises. **Overshoot** (peak above target) and **undershoot** (trough below target) are symptoms. The band's width (hysteresis) and offset, and the anticipation, are tuning parameters for that outcome. Anticipation switches off early by the predicted **overrun**: rise rate × learned **overrun time**. The overrun time is learned from each **coast**. While heating, the rise rate is roughly `(heater power − UA·(T_in − T_out) + solar gain) / heat capacity`. The anticipator measures that rate live, so the current outdoor conditions are already in it. Outdoor data could help with the **overrun time**, which is learned from past coasts: - **Cold days** should lose more heat during the coast, so a smaller overrun and a shorter overrun time. - **Sun during the coast** keeps the temperature rising beyond what the radiators explain, so that coast's overrun time is over-estimated. The **fall rate** (heater off) is much slower than the rise rate (heater on). That is why switch-on is not anticipated for now: undershoot ≈ fall rate × warm-up delay stays small. The first measured coast (2026-10-28, buros sensor): overrun +0.48 °C after switch-off at 2.25 °C/h, so an overrun time of about 13 min. The peak was 1.1 °C above target. ## Data already recorded - `GET /api/history/anticipation?start=…&end=…`: - `samples`: one per control tick during a heating cycle or a coast (rise rate, predicted overrun, overrun time, peak so far) - `coast_records`: one per learned coast (switch-off temp/time, rise rate, peak/time, measured/previous/new overrun time, `settled`) - `GET /api/history/export/json`: all sensor readings, including off periods - `GET /api/history/heating`: heater on/off changes with reasons **Winter data, 2025-12 to 2026-02:** blub's database also holds about 136k readings from January–February 2026. These are mostly the bathroom DS18B20 at 30 s intervals, plus sparse buros readings. There are also about 670 heater on/off changes, and heating events recording the target temperature at the time. There are no coast records from then, because anticipation didn't exist yet. The fall rate, the rise rate and the overrun per heating cycle can still be analysed against the weather from that period, so the analysis can start before end of November. The API serves at most 30 days per request. Nothing is deleted yet (retention cleanup is not wired up). ## Analysis outline 1. **Tracking error:** on the control temperature only (not each sensor), outside warm-ups and cool-downs: - bias (mean error) and spread (RMS) - per time of day and per schedule block - overshoot per heating cycle and undershoot per warm-up 2. **Warm-ups:** how long each warm-up takes after a target rise, as input for a possible later "start early" feature. 3. **Outdoor data:** get hourly outdoor temperature and solar radiation (`temperature_2m`, `shortwave_radiation`, also `direct_radiation`/`diffuse_radiation`) for the house from the Open-Meteo archive API. It's free and needs no key. The home coordinates still need to be supplied. 4. **Join:** pair each coast record with outdoor conditions at switch-off and averaged over the coast (`switch_off_at` … `peak_at`). 5. **Overrun time vs weather:** regress `measured_overrun_time` (and the prediction miss `peak − (switch_off_temp + rise_rate × previous_overrun_time)`) against `T_in − T_out` and solar radiation. Check whether the residual spread matters compared with the tracking error. 6. **Fall rate vs weather:** regress the fall rate while the heater is off against `T_in − T_out`. This gives the heat loss coefficient (UA/C) from many more hours than the coasts provide. Daytime off periods that cool slower than predicted measure the solar gain. 7. **Rise rate vs weather:** the same regression on the rise rate during heating cycles, to confirm the physical model and how much it differs from the fall rate. 8. **Tuning:** from 1–7, choose the band offset and hysteresis by hand for the smallest tracking error without bias. Automatic tuning only if the bias proves stable but drifts with the season. ### Watch out for - **Sensor quantization:** the buros sensor reports in ~0.31 °C steps, so each measured overrun time is noisy (overrun ≈ 0.5 °C). Expect to need 30–60 coasts for a fit with two variables. A hysteresis below the step size would make switching erratic. - **Schedule confounding:** morning heating cycles are always cold and sunless, evening ones follow a day of sun. Compare like-for-like times of day, or include time of day as a variable. - **Coasts not recorded:** coasts cut short by the next heating cycle before the peak, or with a rise rate below 0.1 °C/h at switch-off, are skipped. - **Solar geometry:** Open-Meteo radiation is on a horizontal surface, not the window's orientation, so expect a weaker solar correlation than a window sensor would show. ## Decision - **Outdoor conditions clearly explain the overrun time variation:** add outdoor sensing and make the overrun time (or predicted overrun) depend on it. - **They don't:** keep the learned overrun time as is. Consider smoothing it more instead, or recording samples only when a sensor reports. - **Either way:** set the band offset and hysteresis from the tracking error analysis. ## Proposal if sensors are worth it - **Outdoor temperature:** a zigbee temperature sensor outside, read over MQTT. It is a separate input to the control, never part of the control temperature. - **Sun:** a zigbee illuminance (lux) sensor on the inside of the main window. It probably tracks solar gain through that window better than a horizontal radiation figure. Note that lux sensors saturate in direct sun. - **Glossary:** these become their own terms (e.g. outdoor temperature) once they exist. ## Prerequisites - [x] Commit and deploy the anticipation instrumentation (`anticipation_samples` / `coast_records`): ecf8097, deployed 2026-10-28 10:00 - [ ] Let it collect until end of November (~3–4 weeks, aiming for 30+ coasts) - [x] Supply the home coordinates for Open-Meteo (supplied privately, kept out of this public issue; Antwerp area; windows face SSW and WNW)
pti added the due date 2026-11-30 2026-10-28 09:54:53 +01:00
pti changed title from Analyse anticipation lag vs outdoor temperature and sun (Open-Meteo) to Analyse tracking error, and overrun time vs outdoor temperature and sun (Open-Meteo) 2026-10-28 10:31:53 +01:00
pti commented 2026-10-28 11:01:15 +01:00
Author
Owner

Last winter's data is usable for this analysis: blub's database has about 136k readings from January–February 2026. They are mostly the bathroom DS18B20 (30 s), with sparse buros readings, about 670 heater on/off changes, and heating events that include the target temperature. I've started a first pass against Open-Meteo outdoor temperature and the solar irradiance on the SSW and WNW facades. It covers the fall rate, the rise rate and the overrun per heating cycle. Results follow here. The coordinates are supplied privately and kept out of this issue.

Last winter's data is usable for this analysis: blub's database has about 136k readings from January–February 2026. They are mostly the bathroom DS18B20 (30 s), with sparse buros readings, about 670 heater on/off changes, and heating events that include the target temperature. I've started a first pass against Open-Meteo outdoor temperature and the solar irradiance on the SSW and WNW facades. It covers the fall rate, the rise rate and the overrun per heating cycle. Results follow here. The coordinates are supplied privately and kept out of this issue.
pti commented 2026-10-28 11:22:45 +01:00
Author
Owner

First pass: winter 2025–26 against Open-Meteo weather

Data: 2025-12-31 to 2026-02-15, 46 days. The control temperature was min(bathroom, study). Outdoor temperature and vertical irradiance on the SSW and WNW facades come from the Open-Meteo archive. An east facade was added as a placebo.

Conclusions

Outdoor conditions do not explain the variation in overrun time. Outdoor sensors are not worth adding for the anticipation.

  • Overrun time
    • Study: median 14 min (IQR 9–17, 63 coasts), matching the first coast record on 2026-10-28 (13 min).
    • Bathroom: median 4 min (IQR 1–8, 50 coasts). Its radiator valve (TRV) limits it, and showers disturb it.
    • No weather term is significant. Predicting the overrun from the weather does worse out of sample than a constant overrun time: an RMS error of 0.29 vs 0.27 °C for the study.
  • Fall rate
    • Sun clearly slows the cooling, by +0.04 ± 0.01 °C/h per 100 W/m² on the SSW wall in both rooms, up to +0.3 °C/h on clear days.
    • The data can't tell the facades apart. SSW and WNW correlate at r ≈ 0.77, and the east placebo fits almost as well.
    • Time since the last heating cycle matters more than inside − outside temperature: −0.4 °C/h at 1–3 h after switch-off, −0.15 °C/h at 6–12 h, and about −0.04 °C/h when free-floating for days.
  • Rise rate: study median 1.3 °C/h, bathroom 2.4 °C/h, about 4–10× the fall rate, so undershoot stays small. Outdoor temperature changes it by only about −0.03 °C/h per K, and the anticipation measures it live anyway.
  • Tracking error (341 h with a known target, outside warm-ups and cool-downs, without anticipation):
    • bias +0.07 °C [0.03, 0.11], RMS 0.50 °C, 67 % within ±0.5 °C
    • weather explains 2 % of it
    • overshoot per heating cycle +0.7 to +1.0 °C: the +0.5 switch-off threshold plus the overrun, which the anticipation now targets
    • undershoot after switch-on about 0.6 °C below target
  • Bigger levers than weather:
    • the anticipation itself
    • the band's width and offset
    • which sensor provides the control temperature: the bathroom is a poor control sensor (TRV, showers), and its overrun time differs from the study's by 10 minutes
    • learning the overrun time per control sensor, rather than one value for the house

Observations about last winter

  • No heat arrived from 14–20 Jan and 2–9 Feb, although the relay switched. The house cooled freely.
  • Bathroom warm: on 2–14 Jan the bathroom sat at 23–28 °C with its own ~50-min oscillation while the heater was off.
  • Relay blips after lockouts: 352 lockouts for exceeding the 2-hour maximum cycle duration. After each one the relay closed again for about 10 s every 5 min. This needs checking against the current code.

Plan: confirm at the end of November

Re-run the same analysis on this autumn's data, which now has anticipation and coast records:

  • Overrun time: does the study stay around 13–14 min, and does it still show no weather dependence? Use 30+ coast records.
  • Tracking error and overshoot vs this winter's baseline (bias +0.07, RMS 0.50, overshoot +0.7 to +1.0 °C): the anticipation should cut the overshoot by roughly the overrun.
  • Sun: with more sunny coasts, check whether sun during a coast lengthens the overrun time. Too few sunny coasts last winter (about 10) to test it.
  • Decide on learning the overrun time per control sensor, and on the band offset and hysteresis.
  • Outdoor sensors: close as not needed, unless the November data contradicts this.

Caveats: this is one partial winter with an old controller (no anticipation, lockout bug, frequent manual overrides), a bathroom-heavy dataset, modelled (not measured) facade irradiance, and targets recovered from the event log for only about two thirds of the hours.

## First pass: winter 2025–26 against Open-Meteo weather **Data:** 2025-12-31 to 2026-02-15, 46 days. The control temperature was min(bathroom, study). Outdoor temperature and vertical irradiance on the SSW and WNW facades come from the Open-Meteo archive. An east facade was added as a placebo. ### Conclusions **Outdoor conditions do not explain the variation in overrun time. Outdoor sensors are not worth adding for the anticipation.** - **Overrun time** - Study: median **14 min** (IQR 9–17, 63 coasts), matching the first coast record on 2026-10-28 (13 min). - Bathroom: median **4 min** (IQR 1–8, 50 coasts). Its radiator valve (TRV) limits it, and showers disturb it. - No weather term is significant. Predicting the overrun from the weather does *worse* out of sample than a constant overrun time: an RMS error of 0.29 vs 0.27 °C for the study. - **Fall rate** - Sun clearly slows the cooling, by +0.04 ± 0.01 °C/h per 100 W/m² on the SSW wall in both rooms, up to +0.3 °C/h on clear days. - The data can't tell the facades apart. SSW and WNW correlate at r ≈ 0.77, and the east placebo fits almost as well. - Time since the last heating cycle matters more than inside − outside temperature: −0.4 °C/h at 1–3 h after switch-off, −0.15 °C/h at 6–12 h, and about −0.04 °C/h when free-floating for days. - **Rise rate:** study median 1.3 °C/h, bathroom 2.4 °C/h, about 4–10× the fall rate, so undershoot stays small. Outdoor temperature changes it by only about −0.03 °C/h per K, and the anticipation measures it live anyway. - **Tracking error** (341 h with a known target, outside warm-ups and cool-downs, without anticipation): - bias **+0.07 °C** [0.03, 0.11], RMS **0.50 °C**, 67 % within ±0.5 °C - weather explains 2 % of it - overshoot per heating cycle **+0.7 to +1.0 °C**: the +0.5 switch-off threshold plus the overrun, which the anticipation now targets - undershoot after switch-on about 0.6 °C below target - **Bigger levers than weather:** - the anticipation itself - the band's width and offset - **which sensor provides the control temperature**: the bathroom is a poor control sensor (TRV, showers), and its overrun time differs from the study's by 10 minutes - learning the overrun time **per control sensor**, rather than one value for the house ### Observations about last winter - **No heat arrived** from 14–20 Jan and 2–9 Feb, although the relay switched. The house cooled freely. - **Bathroom warm:** on 2–14 Jan the bathroom sat at 23–28 °C with its own ~50-min oscillation while the heater was off. - **Relay blips after lockouts:** 352 lockouts for exceeding the 2-hour maximum cycle duration. After each one the relay closed again for about 10 s every 5 min. This needs checking against the current code. ### Plan: confirm at the end of November Re-run the same analysis on this autumn's data, which now has anticipation and coast records: - [ ] **Overrun time:** does the study stay around 13–14 min, and does it still show no weather dependence? Use 30+ coast records. - [ ] **Tracking error and overshoot vs this winter's baseline** (bias +0.07, RMS 0.50, overshoot +0.7 to +1.0 °C): the anticipation should cut the overshoot by roughly the overrun. - [ ] **Sun:** with more sunny coasts, check whether sun during a coast lengthens the overrun time. Too few sunny coasts last winter (about 10) to test it. - [ ] **Decide** on learning the overrun time per control sensor, and on the band offset and hysteresis. - [ ] **Outdoor sensors:** close as not needed, unless the November data contradicts this. **Caveats:** this is one partial winter with an old controller (no anticipation, lockout bug, frequent manual overrides), a bathroom-heavy dataset, modelled (not measured) facade irradiance, and targets recovered from the event log for only about two thirds of the hours.
pti commented 2026-10-29 11:36:49 +01:00
Author
Owner

Data point 2026-10-29, first coast with anticipation (overrun time 13 min, rate window 20 min):
Outdoor 10 °C at 09:00, 11 °C at 10:00, 12.6 °C at 11:00 (Open-Meteo)
Sun 76 W/m² at 09:00, 164 at 10:00, 292 at 11:00; cloud cover 85% → 65% → 3%
Warm-up 18.34 → 20.16 °C, 09:00–10:00:40; reported rise from 09:24 at about 2.34 °C/h
Switch-off 10:00:40 at 20.16 °C, anticipated (20.16 + 0.51 > 20.5)
Peak 20.74 at 10:30, 20.78 at 11:00 (sun)
Overrun 0.62 °C, measured overrun time about 16 min

Most of the overrun (0.58) came within 30 minutes of switch-off. The last 0.04 was likely solar gain. Without anticipation the heater would have run until about 10:15, with a peak around 21.3.

The coast never dropped 0.2 °C below its peak before the 3 h timeout, because of the sun. From the next release, a coast also settles when the temperature levels off (less than 0.1 °C rise in 30 min), and a coast that times out is no longer learned from. Days with solar gain after switch-off should be tagged in this analysis.

Sensor reporting resolution: #15. Optimum start for the warm-up: #14.

Data point 2026-10-29, first coast with anticipation (overrun time 13 min, rate window 20 min): | | | |---|---| | Outdoor | 10 °C at 09:00, 11 °C at 10:00, 12.6 °C at 11:00 (Open-Meteo) | | Sun | 76 W/m² at 09:00, 164 at 10:00, 292 at 11:00; cloud cover 85% → 65% → 3% | | Warm-up | 18.34 → 20.16 °C, 09:00–10:00:40; reported rise from 09:24 at about 2.34 °C/h | | Switch-off | 10:00:40 at 20.16 °C, anticipated (20.16 + 0.51 > 20.5) | | Peak | 20.74 at 10:30, 20.78 at 11:00 (sun) | | Overrun | 0.62 °C, measured overrun time about 16 min | Most of the overrun (0.58) came within 30 minutes of switch-off. The last 0.04 was likely solar gain. Without anticipation the heater would have run until about 10:15, with a peak around 21.3. The coast never dropped 0.2 °C below its peak before the 3 h timeout, because of the sun. From the next release, a coast also settles when the temperature levels off (less than 0.1 °C rise in 30 min), and a coast that times out is no longer learned from. Days with solar gain after switch-off should be tagged in this analysis. Sensor reporting resolution: #15. Optimum start for the warm-up: #14.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.11
v0.10
v0.9
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
2026-11-30
Dependencies

No dependencies set

Reference
pti/blubgo#8
No description provided.