---
title: A house is more than a system
date: "2026-11-09"
description: "A working note on the house project: what should be automated, what should stay simple, and why the ordinary controls matter."
draft: false
---

A house project gives an infrastructure engineer an almost unlimited number of things to connect. Lights, heating, energy, sensors, a dashboard. The more interesting question is which of those connections actually make living there better.

This is a working note about the direction I want to take, rather than a finished tour of the house. My Home Assistant projects already span floor plans, heating, and research into local voice control. I want the decisions around those projects to be as deliberate as the technology.

## Start with the ordinary interaction

A light has a much simpler job than the system behind it. Someone enters a room and wants to see. They should not need to know which service owns the device, whether a broker is running, or what I changed yesterday.

For each proposed automation, I want to write down three things before writing the configuration:

| Question                             | Example to work through                                     |
| ------------------------------------ | ----------------------------------------------------------- |
| What is the everyday action?         | Turn on a room’s lights.                                    |
| What does the automation add?        | A useful scene or a presence-based shortcut.                |
| What happens when it is unavailable? | The ordinary control should still have a defined behaviour. |

That last row is a design requirement, not a claim that every device I own already behaves this way. It depends on the device, its wiring, and the way the integration is configured.

## Keep a decision next to the experiment

It is easy to remember that a setting changed and forget why. A short Markdown note is enough to preserve the useful part:

```markdown
# Decision: room lighting

Status: proposed

Everyday interaction:

- A familiar control at the entrance.

Automation adds:

- A scene selected for the activity in the room.

Failure cases to check:

- Home Assistant is restarting.
- The room has lost its network connection.
- The device has just recovered from a power outage.

Evidence:

- Record the observed behaviour for each case.
- Update the decision if the fallback is surprising.
```

This separates an intention from something I have actually tested. It also makes a later hardware change easier to assess: does it still satisfy the same everyday interaction?

## The interface can be ambitious; the house should be understandable

The Blender floor-plan project is the expressive side of this work. It turns light states into a visual model of the home. But the model is a view onto Home Assistant, not the definition of what a room is allowed to do.

I like that separation. A dashboard can evolve, a rendering can be replaced, and a voice interface can remain an experiment while the underlying interactions stay explicit.

I’ll use this journal to collect those decisions as the project develops. The first technical example is [the floor plan that knows which lights are on](/blog/a-floor-plan-that-knows-the-lights/).