The model with more physics was the worse one

My Home Assistant has known the gas consumption of the Vienna flat since October 2025. Before that: nothing. An empty chart and the question of whether this winter was expensive or ordinary.

The numbers existed anyway. 71 meter readings, December 2021 to November 2025, typed by hand into a heating app over the years and retrievable there.

The catch sits between the readings. A meter reading tells you how much has passed through in total. It does not tell you when.

The hard part: from readings to days

Over three days the distribution does not matter. Over 527 days it does.

Gap	Length	Volume	spread flat
May 2023 – Oct 2024	527 days	335 m³	0.64 m³/day
Oct 2024 – Apr 2025	195 days	575 m³	2.95 m³/day
Apr 2025 – Oct 2025	165 days	37 m³	0.22 m³/day

Flat would mean 0.64 m³ on every July day. But from the dense readings of the same household I know that a July day sits at 0.09 and a February day at 3.07. Flat would be seven times too high in summer — and a summer that looks like half a heating season makes every analysis worthless.

First attempt: my own seasonal shape

So: a shape. One average daily consumption per calendar month, derived from my own dense readings — only intervals of at most 32 days, where the distribution barely matters any more.

01:1.77  02:3.07  03:1.81  04:0.62  05:0.19  06:0.09
07:0.09  08:0.11  09:0.14  10:0.47  11:0.25  12:2.36   m³/day

No external model, no borrowed assumptions, everything from this household. It felt clean.

Two days later the shape could be held against a full measured year for the first time. It failed:

Month	measured	seasonal shape	factor
November	1.74 m³/day	0.25	7.0×
January	7.18	1.77	4.1×
February	2.34	3.07	0.8×
July	0.04	0.09	0.4×

The November of the seasonal shape came from 37 days of one single mild month.

Build a monthly average out of that and you don’t get a climate, you get a weather.

That is the error in one sentence: I had twelve numbers, each looked like an average, and behind some of them stood exactly one month.

The obvious replacement: real temperatures

If the seasonal shape has too little behind it, take the quantity that actually drives consumption. The Austrian weather service holds daily mean temperatures for Vienna going back to 1775; for the entire gap period 1425 days were available without a hole.

From that, a model whose two numbers are both measured at my own building:

weight per day = 0.0459 m³ + 0.4662 m³ × heating degree day (12 °C)

Quantity	Where it comes from
Base load 0.0459 m³/day	Mean of all 61 July and August days of the measured year. In high summer nobody heats; what remains is hot water — the combi boiler does both.
0.4662 m³ per degree day	Least squares over 317 measured days
Heating limit 12 °C	Tried from 10 to 20 °C; 12 fitted best and explains 73.9% of the daily variance — and it is also the Austrian standard value. Two independent routes, same answer.

This is not a borrowed model. Base load measured, slope fitted, heating limit confirmed twice. I was rather pleased with it.

And then this model failed too

There was exactly one independent check point: a self-reading from 19 February 2025 that appears in the annual bill and entered neither derivation.

Model	Reading per model	Document	Deviation
Temperature model	6181.8	6071	+110.8
Seasonal shape (old)	6083.9	6071	+12.9

The physically better model was the worse one. By a factor of nine.

The reason sits in the numbers of the interval itself:

Oct 2024 -> Feb 2025   363 m³ in 125 days  =  2.90 m³/day
Feb 2025 -> Apr 2025   212 m³ in  70 days  =  3.03 m³/day

Deep winter and spring use almost the same amount per day. By temperature the winter part would have to be far above that — which is exactly what my model assumed, and exactly why it put the February reading too high.

What rules here is not the weather but presence. A flat that is not in continuous use does not heat at −5 °C either. A weather model cannot know that; in its world every cold day is a heating day.

A model answers the question you built it for. It is blind to the question you did not ask.

What actually helped: a measured number

The check point itself was the solution.

The annual bill contains two self-readings that had never been entered into the app. They sit exactly where the gaps are largest. Added as support points, both gaps fall apart:

before	after
527 days in one piece	379 + 148 days
195 days in one piece	125 + 70 days

Measured back in the database, against all three documents:

Date	Document	Model	Deviation
May 2024	5692	5692.0	±0.0
Feb 2025	6071	6071.0	±0.0
Oct 2025	6320	6320.0	±0.0

These numbers cost nothing. They had been sitting in the annual bill the whole time.

One reading I deliberately leave out

A third value from the same bill did not go in. The bill itself marks it as calculated, and together with the real reading six days later it would imply 6.8 m³ on a day in May.

That is not a reading, that is an extrapolation. Using it as a support point would mean taking somebody else’s estimate for a measurement.

What stays honestly open

The temperature model is still in use — for the distribution inside the now shorter gaps. It is calibrated on 317 measured days of this building and physically justified.

But its superiority can no longer be proven there, because the only independent check point has now been consumed as a support point. You cannot test a model against a number you handed it.

And the presence gap remains its blind spot. I now know it is there. It is not gone.

That is why the result carries the same separation I drew for the cool-down model in Merano:

Measured are the meter readings on 71 reading days and two billing days. Inferred is the distribution between them.

What I’d suggest

1. Write down what is measured and what is inferred. A reconstructed series looks exactly like a measured one in any chart. The difference has to be in the text, not in the author’s head.
2. An average from a single month is not an average. Count how many periods each of your figures is built from.
3. Test against something that did not enter the derivation — and before you import, not after.
4. Look for the real number before you model. Old bills, reading cards, building manager records. One genuine reading in the middle of the gap beats any model.
5. Leave out what the source itself marks as calculated. Otherwise you build on somebody else’s estimate and never notice.

So what?

For two days I assumed the better model would win. More physics, real measurement series, cleanly fitted — surely that had to be the more accurate one.

It was the worse one, clearly so. Not because the physics was wrong, but because this flat’s consumption hangs on something that appears in no temperature series.

The cheapest improvement in the whole project turned out to be not a model but reading a bill properly. The same kind of document I had gone through line by line ten days earlier when I checked 25 invoice lines — except that then I was looking at the energy amounts and skipped past the reading dates.

That is the part that stays: the number that beat my model, I had all along.