What does a flat cool towards? Not the outside air

In my flat in Merano the building’s central heating runs only at fixed times: 05:30 to 12:00 and 15:00 to 22:30, season mid-October to mid-April. From 22:30 to 05:30 there is no hot water in the circuit — seven hours.

The thermostatic valves can do nothing during that time. They can open a valve, but nothing arrives behind it.

That turns into a simple question: how warm does it have to be at 22:30 so that it is still comfortable at 05:30? The answer cost me two mistakes, and the second was the instructive one.

The first mistake was mine

My first suggestion was to heat at night with the air conditioners — all three can do it. The answer came straight back: that is the most expensive route.

And it is right. The radiators are billed through the building community, the heat pump through our own meter. Heating electrically at night means replacing the cheaper heat with the expensive one.

The better suggestion was: heat up more the night before and measure how fast it cools.

Why kelvin per hour is not enough

The obvious measurement would be: 22 °C in the evening, 18 °C in the morning, so 4 K in seven hours, 0.57 K/h.

That is wrong, and fundamentally so. A room cools exponentially, not linearly. The smaller the difference to its surroundings becomes, the slower it goes. A K/h figure holds exactly for the one night it was measured in, and for no other.

What counts instead is the time constant τ. It is a property of the building and holds for every night. A script computes it from the sensors in the Shelly BLU TRV heads, which resolve to 0.01 K.

The real finding: not towards outside

Here is the mistake that matters. I had silently assumed the flat cools towards the outside air.

It does not. It is on the second floor, with heated neighbours above, below and beside. What surrounds it is not zero degrees.

The difference is not academic:

What it is computed against	Preheating needed for 19 °C at 05:30
0 °C (outside air)	26–36 °C — nonsense
14 °C (effective surroundings)	19.3–23.5 °C — doable

Same flat, same night, same formula. The only difference is the assumption about what it cools towards — and it decides between an impossible and an obvious target.

The script therefore estimates that limit from the cooling curve itself, via a three-point method, rather than being given it.

And why the summer measurement is worthless

The first run returned: the flat cools towards −34.7 °C, with a time constant of 192 hours.

Formally computed correctly. Substantively nonsense.

The reason: in summer the gradient between inside and outside is only 3 to 7 kelvin. The noise is then larger than the signal. Any curve fit will return some number under those conditions, and it can be arbitrarily far off.

Plausibility limits now apply. With too small a gradient the tool says “not evaluable” instead of inventing figures.

To me that is the most important sentence about this whole setup. A tool that always returns a number is more dangerous than one that sometimes stays silent.

The model for both directions

The time constant is useful in winter — but once you know the flat’s coefficients, the same model improves heat control in summer. Only the sign of the problem flips.

Fitted per room:

dT/dt = a · (T_out − T_in) + b · P_solar + c

        τ = 1/a          T_rest = T_out + c/a

The solar input comes from the output of the solar panel. That is not a workaround but exactly right: the panel measures irradiance on the same façade the heat enters through.

With one explicit limitation: the panel sees one façade. So the coefficient b means “heat input relative to this panel”. Move it, and it has to be measured again.

Two decisions learned from measurement errors

Data from the long-term statistics, not the state history. The history is gone after about ten days; hourly means survive the purge. For a time constant of 10 to 20 hours, hourly resolution is plenty.

But “permanent” is not true of the statistics either: on this instance they have been lost twice. If you build a model on months of data, back the raw data up separately.

Check the calendar against presence detection. A cooling curve from a night when somebody was actually there falsifies everything — and the calendar alone does not know that reliably.

The trap that blocks itself

Now the part that surprised me most.

The thermostatic head in the kitchen sits next to the riser pipe. That heats the sensor. As soon as the building is heating, the kitchen reports 23 to 25 °C.

The arrival automation sets all valves to 21 °C. The head compares 21 against 24 — and keeps the valve shut.

And it does so precisely during the heating windows, that is, when heating would be possible at all. At night, when the sensor drops to 22.5, there is no water in the circuit.

A feedback loop that blocks itself: the head closes because heating is running, and opens when heating is impossible.

In the children’s room the same type of sensor reads 1.12 K too low on average. In the kitchen it reads 2 to 4 K too high. It is not a device fault, it is the mounting position.

Three ways out, honestly ranked

1. The right one: a separate room sensor in the kitchen, its value written regularly to the head’s external temperature input. Then it regulates on the room instead of the riser. Needs hardware on site.
2. A stopgap from afar: set the calibration to −3. The head then computes 24 − 3 = 21 and opens. But the offset is not constant — it swings with the 2.25 K daily cycle.
3. The cheapest option, no technology at all: simply run the kitchen at 24 instead of 21 °C. More honest than a calibration that feigns an accuracy the sensor does not have.

That option 3 is seriously on the list is not a joke. It describes the situation correctly instead of computing it away.

The gain that was not on the list

And now the turn. The kitchen sensor is unusable as a room measurement — but as a measurement of the building circuit it is exactly what the preheating model was missing.

Until now a notice in the stairwell said when heating runs. Now it is measurable when hot water actually arrives — daily.

That means “how many degrees do we have to heat up to” can be computed against the real switching times instead of against a piece of paper.

The same mechanism applies once more: in the unheated hallway a sensor regulates nothing at all. But it delivers the coldest point in the flat — and with it a direct measurement of what the flat cools towards. Exactly the value the three-point method had to estimate from the curve.

What that means for preheating

The arrival automation raises all valves at 16:00. After one measured night it is clear: whether that helps depends on the day’s weather, not on the clock. In mild weather the valves open into a cold circuit — and slightly cool the rooms in the process.

That is no reason to change the automation: the circuit is only cold when it is mild anyway, and then nobody needs preheating.

But my original justification was too optimistic. It read: “16:00 is in the middle of the heating window, so hot water is arriving.”

Correct would be: hot water arrives, provided the building control is calling for heat that day.

So what?

Three things that reach beyond this flat:

1. Do not ask how fast it cools, ask what towards. For a flat with heated neighbours the outside temperature is the wrong reference — and the difference between “preheat to 26 °C” and “preheat to 20 °C” is exactly that assumption.
2. Measure in winter, not in summer. Without a sufficient gradient the result is noise, however cleanly it is computed.
3. A sensor in the wrong place is not worthless — it is measuring something else. Before you disconnect it, ask what it actually measures. Sometimes that is exactly the quantity you were missing.

The model is not finished. Sensors are missing, and so is a full heating season of data. What is written here is the state, not the result.