← Back to the journal

/ A NOTE BY JAKOB

A house is more than a system

A working note on the house project: what should be automated, what should stay simple, and why the ordinary controls matter.

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:

# 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.