Three rooms cooled down — and nobody had a window open

The flat in Merano is often empty. If somebody has been there I want to know — not out of mistrust, but because any measurement series becomes worthless if it does not know about occupancy.

Calendar and phone tracking are not enough for that. A calendar entry can be missing or wrong about the time, and the tracker knows only two phones.

So, a third route: detect ventilation from the physics. It worked, produced a hit — and the interpretation was still wrong. What came out of that mattered more than the feature itself.

The idea

The flat is sluggish. Very sluggish. Measured over 516 hours of empty flat:

Room	fastest fall with no window open
Living room	−0.14 K/h
Bathroom	−0.09 K/h
Bedroom (wall)	−0.07 K/h

More than about 0.2 K per hour cannot be thermal conduction. The threshold in the script therefore sits at 0.25 K/h — room to spare, and still well below the 0.8 to 1.0 K/h that real ventilation produces.

Why simultaneity is the marker

A single outlier can be many things: a sensor jump, a battery change, a newly paired valve.

Several rooms in the same hour cannot. That is somebody walking through the flat opening windows. Single rooms are therefore reported separately and explicitly as “not proof”.

The hit

On 1 October, between 09:00 and 11:00:

Kitchen              21.4 -> 19.9 °C   (−1.6 K)
Children's room      21.5 -> 20.0 °C   (−1.6 K)
Bedroom, window      22.0 -> 20.2 °C   (−1.8 K)

unchanged:           living room, bathroom, bedroom (wall)

Outside 20.3 °C. Three rooms fell, three did not — spatially coherent. And calendar and tracker both said “nobody there”: the entry for the announced visit starts at 17:00.

In 21 days of empty flat that was the only detected event. So the method does not fire wildly.

The conclusion was obvious: somebody aired the place in the morning for the visitor.

And then the interpretation was taken apart

Two objections, both landed.

“Then the door would have been opened.” The door lock read locked continuously from 06:00 to 14:00. Not a single state change. The automation that takes a snapshot on every door opening had last fired the previous day.

“And the cameras are armed.” True — although they failed as witnesses, for a reason that is a lesson in itself: their motion sensors only come into existence at the first motion and do not survive a restart. They read “unavailable” and were no use either way.

And then the objection that solved it: “Could it be that the valves did not deliver clean room values? Because heating does not cool.”

What actually happened

At 09:00 the arrival automation ran. It starts eight hours before the calendar entry and sets the heating to 21 °C.

The valve positions match exactly:

Room	valve from 09:00	sensor
Bedroom, window	0 → 3 → 8 → 12 → 17 %	−1.8 K
Children’s room	0 → 22 → 25 → 31 → 35 %	−1.6 K
Kitchen	0 → 24 → 26 → 32 → 36 %	−1.6 K
Bedroom wall, bathroom, living room	stays 0	unchanged

Exactly the three rooms opened that, at 21.4 to 22.0 °C, were closest to the new setpoint of 21 °C. The other three stood at 23 to 24.7 °C and had no reason to.

The proof came from the real room sensors

Two independent sensors in the rooms stayed unchanged over the same hours:

Time    Children's room       Bedroom               outside
        room    radiator      room    radiator
08:00   22.40     21.54       22.30     21.96       19.8
09:00   22.40     20.56       22.30     21.16       20.8   <- valves open
10:00   22.40     19.97       22.30     20.20       21.6
11:00   22.40     19.84       22.30     20.03       23.4

The room held to the decimal place while it got warmer outside.

Nothing was aired and nothing was cooled. The valve opened, cold water from the still-unheated circuit flowed into the radiator — and the thermostat’s sensor sits on the radiator.

A heating system switching on can cool a temperature sensor. That sounds absurd and is entirely logical once you know where the sensor sits.

The real significance

This is not an isolated case but a permanent state. Compared over 503 hours, valve sensor against real room sensor:

	Deviation
median	−1.12 K
range	−2.63 to −0.34 K
hours more than 0.5 K from the median	24 %

The valve sensor reads a good degree too cold on average, and the deviation is not constant — in a quarter of all hours it departs considerably from its own mean.

So my measurement series spent months measuring radiators, not rooms. Every analysis built on it — cooling behaviour, heat model, preheating demand — rests on a quantity that measures the wrong thing.

A fixed correction does not help. With a deviation swinging between −0.34 and −2.63 K, calibration only moves the error instead of removing it.

What follows

The detector was not switched off. It works — it spotted a real change and reported it correctly. What was wrong was only what I concluded from it.

Something else changed: real room sensors are going into the rooms that so far only have a valve sensor. And the analyses move over to those as soon as they arrive.

So what?

1. Ask where the sensor sits. A thermostatic head measures at the radiator, not in the room. That appears in no product description and changes every analysis.
2. A working detector is not the same as a correct interpretation. The script did clean work. The story around it was invented.
3. Take objections seriously, even when your data looks conclusive. Two sentences achieved more here than 516 hours of measurement: “then the door would have been opened” and “heating does not cool”.
4. A swinging deviation cannot be calibrated away. A fixed offset feigns an accuracy the sensor does not have.
5. Check whether your witness can testify at all. Entities that only come into existence through an event never prove its absence.

And the most uncomfortable part: had nobody objected, my documentation would today state that somebody aired the flat on the morning of 1 October. That would have been a false fact inside a data series — and those outlive any software bug.