About This Site: Evidence, Scope and Status
How small household annoyances turn into disproportionate AI-led engineering, and how the resulting work becomes public technical notes without overstating the evidence.
All I wanted was…
to make a few things around the house less annoying.
Then it escalated quickly.
How AI took over my life, one small household annoyance at a time
I have a habit of solving small household annoyances with disproportionate AI-led engineering.
The starting point is usually completely reasonable: turn off the lights from bed, control a heater remotely, understand what the solar is actually saving, or make three Sonos speakers behave. The ending is less reasonable: Home Assistant, local infrastructure, custom software, self-hosted dashboards, network engineering and an AI team with job titles.
I am not trying to hide the AI involvement. It is part of the engineering process and part of the story.
ChatGPT acts as the project lead and coordinator: helping investigate, break work down, review evidence, plan changes and verify outcomes. Peasant, my local LLM, handles suitable retrieval, log work and repetitive evidence tasks. Minion/Codex is used selectively when a bounded implementation task genuinely benefits from a stronger coding agent.
The human role did not disappear. I still decide which problems are worth solving, what gets built, when a change is acceptable, what hardware gets connected and whether the result actually works in the real house. AI can help reason about whether a heater should turn on; somebody still has to look at the heater.
So this site is not a claim of AI-free craftsmanship. It is a record of what happens when normal household problems meet an increasingly elaborate AI-assisted engineering workflow.
What this site documents
This site records engineering work from a real private Home Assistant and home-infrastructure project. It focuses on architecture decisions, bounded experiments, software projects and the lessons that survived review. It is a technical notebook, not a live inventory, operating manual or complete map of a household environment.
Public articles are sanitised versions of retained private engineering records. They favour recorded evidence over reconstructed memory, while deliberately generalising or omitting private identifiers, network topology, credentials and tokens, access-control implementation, recovery procedures, sensitive radio work, and personal or account information. An omission does not mean the omitted mechanism does not exist; it means publishing it would add unnecessary exposure.
How to read status language
- Current / deployed means retained evidence establishes that something is presently part of the live environment.
- Tested / validated means a bounded test succeeded. It does not automatically mean the work is deployed or continuously healthy.
- Historical describes an earlier state or experiment. It is not proof of the current environment by itself.
- Proposed / planned describes design intent or future work, not implemented state.
- Abandoned / superseded describes work that was explored or previously used but is no longer the intended design.
- Unverified means retained evidence cannot establish the current state confidently.
These distinctions are intentional. They keep a successful test from becoming an unsupported production claim and let the site describe useful lessons without exposing a private environment. When the evidence is incomplete, the article should say so rather than fill the gap with inference.