Home automation field notes All concepts

ventilation

Airing into a wall

Two small automations about doors, windows, and the questions nobody thought to ask: is this door actually airing anything, and who is still home.

The bedroom opens onto a balcony, and the balcony is glazed. There is an inner door, which tilts or swings wide, and beyond it a sliding window that is the actual boundary between us and the weather. Open the inner door with the outer one shut and you have not aired anything. You have created a slightly larger, slightly colder bedroom.

The sliding window had been shut against rain a few days earlier. One evening in September somebody tilted the inner door to air the room and went off to do something else, secure in the knowledge that ventilation was in progress. It was not. The room got the cold off the glass and none of the fresh air.

A door that opens onto nothing

The house already knew how to check that airing had happened: the air advice closes its own loop by watching two contacts on opposite sides of the flat, both open, and says well done instead of nagging again. What nothing covered was a door opened on a person's own initiative, into a glazed balcony, where the second contact is not on the far side of the flat but two metres away.

The fix is a template binary sensor, which we called blind airing. It is true when the inner door is tilted or wide open and the sliding window is shut, and false otherwise. That is the whole sensor. It is the same trick as the through-draught sensor, a state neither contact knows on its own, with the sign reversed: that one notices two windows open, this one notices one door open and the wrong second thing shut.

The sensor is a level fact, true for as long as the condition holds, whatever order you got there in. It does not care whether you opened the door with the window already shut, or shut the window with the door already open, which was the rainy-day order of events. The automation still watches the moment it becomes true, because that is when a reminder is useful; the difference is that the fact underneath survives a restart and the moment would not.

Two minutes after that moment, a reminder: the bedroom door is open, tilted or wide, the sliding window is shut, no air is coming, open the other one too. At the half-hour mark, if it is still true, a second one. Not while anyone is asleep, though. The consequence of a stuffy bedroom is CO₂, and CO₂ has its own automation, and waking somebody to tell them they are not ventilating would cost more than the ventilation is worth.

The rain exception

The refinement arrived the same day. When it rains, somebody goes out onto the balcony to fetch tools, and in the rain a shut sliding window is not a mistake, it is the point. A door open for a few minutes in those conditions is a person, not an oversight, and a reminder at two minutes is a nag.

So the delay depends on the weather: ten minutes if it is raining, two if it is not. "Raining" is decided by any one of three sources, because each has been known to be wrong on its own: the weather provider's millimetres per hour, our own rain nowcast reporting less than a minute until rain, or the national forecaster's current state being any of the wet ones. One vote is enough. Two sources, and their disagreement is the house rule; here the disagreement is cheap to settle, because the cost of believing a false "raining" is eight extra minutes of silence.

A template sensor's own delay, the delay_on that would normally do this job, is a fixed value; it cannot be a template. A state trigger's for can. So the sensor has no delay at all, deliberately, and the rain-dependent wait lives in the automation's trigger, where it is computed at the moment the door opens. The comment in the sensor says as much, for the benefit of whoever next wonders where the debounce went.

The other wrinkle is older, and we have paid for it before: a template entity flickers to unavailable and back on every reload, and a trigger with only a to: counts the flicker as a real event. So the two-minute trigger says from: 'off'. The half-hour repeat leans on its own long for: instead, which is not the same thing and is on the list.

Leaving, with the other of us still home

The second story is shorter and more embarrassing. Just before one o'clock the next afternoon, a phone received the message "Balcony wide open, and you are leaving". The living-room balcony door was indeed wide open, not tilted, which is the summer setting and stays silent. One of us was indeed walking away from the flat. The message was accurate in every respect but the one that mattered: the other of us was at home.

The house knew this, too, and had gone to some trouble to know it. (The presence page makes the case for the distinction between an empty flat and one occupied by somebody else. This automation had simply never been told about it.) That phone has no home-automation app on it. Its presence is assembled from two things nobody designed for the purpose: a classic Bluetooth name request, which the phone answers whenever its radio is on, and a ping from the router, tried every minute, with four consecutive misses required before either dares to say "away". Two trackers feed one person entity, and both had been saying home all morning.

The automation had never asked. Its one condition was that guest mode, the switch we flip when somebody is staying with us and the house should stop having opinions, be off. The branch for walking away checked that the door was wide open and that the alarm was disarmed, so as not to duplicate the warning the alarm already gives when it arms, and then it sent the message. Who else might be in the flat did not come into it. An open balcony door is not unattended if somebody is attending it.

The fix is one condition, and the shape of it matters more than the fact of it. It is a template asking whether the other person entity is anything other than home, rather than the tidier built-in test for not_home. The difference is what happens when presence is unknown or unavailable: the template still warns, the state condition would not. We chose the template on purpose. A warning we did not need costs a glance at a phone. A warning we did not get costs a wet living room. The automation is quiet only when the house is sure somebody is there.

The one we left alone

There is a sister automation: a storm approaching, the sliding window open, and somebody leaving. It has the same trigger and the same blind spot, and we did not touch it. Rain coming onto the balcony is damage, and the person at home may not know it is coming; they are not watching the forecast, the house is. Silencing that warning because somebody is home would be fixing the wrong thing. The right fix there is different wording, "ask the other of us to close it" rather than "come back and close it", and that is on the list rather than in the file. Alert hygiene has the general principle: the cure for a wrong alert is rarely no alert.

Lesson: a departure warning must ask who stays. "You are leaving" is a fact about one person; "this is unattended" is a fact about everyone, and only the second is worth interrupting somebody for. The bedroom taught the same thing in miniature: a door that is open is not a door that is airing, and a sensor that knows the difference is worth two minutes of anyone's time, or ten in the rain.