Smart Home & Cognitive Domicile

We use the phrase <em>cognitive domicile</em> deliberately, because the language we have for connected homes is mostly wrong. <em>Smart home</em> implies a consumer-grade collection of individually clever devices that occasionally act in concert and frequently do not. The cognitive domicile is something else: a household-scale operating system whose job is to do the boring work invisibly, surface the signals that matter, and disappear when nothing is wrong. The difference is not the gadgets. The difference is the architecture.<br><br>This pillar is the long-form version of why we run our home this way, what specifically we have automated, what we have deliberately not automated, and what an operator-grade household stack looks like in practice. The intended reader is not a consumer-electronics shopper — it is someone who has tried the off-the-shelf approach and found it consistently more annoying than the manual version it was meant to replace. The premise is that the technology has matured to the point where the operator-grade version is finally worth the build, and the consumer-grade version is no longer worth the trouble.

Why the consumer-grade version disappoints

The off-the-shelf smart home fails on three predictable fronts:

• The cloud is the bottleneck. Most consumer devices route every command through the manufacturer's cloud, which means every action has round-trip latency, every outage of the manufacturer's service is an outage of your house, and every device is one acquisition or product-line wind-down away from being a brick.
• The integration surface is shallow. Even when devices speak the same protocol, the cross-vendor automations a real household actually wants are typically not expressible in the consumer dashboards. The lighting ecosystem can dim the lights. The security ecosystem can arm the alarm. The two of them cannot reliably co-ordinate without a third-party orchestration layer.
• The data is rented. Energy consumption, occupancy, climate, device usage — all of it lives in vendors' clouds, accessible through whichever API surface they choose to expose, and not exportable in any way that compounds across years.

None of these failures are individually fatal. Together they explain why every long-time smart-home user we have ever met eventually rebuilt the house around a local hub.

Local-first, cloud-optional

The architectural commitment is local-first. Every command, every automation trigger, every state change happens on a hub running on a low-power machine in the house. The hub is reachable from outside the home only through the private mesh. Cloud connections happen only when a specific capability genuinely requires them — voice training data, weather forecasts, a tiny handful of integrations that have no offline alternative.

The benefits are immediate. Latency drops to under a hundred milliseconds for any local action. Reliability becomes a function of the local network, which is something we control. Outages of any individual cloud service have no impact on whether the lights work, the heating runs, or the doors lock. Privacy becomes total at the local level — the manufacturer of any specific device cannot read what we do with it.

The cost is the initial setup. The hub has to be installed and configured. Devices have to be onboarded. The automations have to be written. None of those are difficult by the standards of an operator who has built any other kind of system, but they are not zero, and they are unfamiliar to anyone coming from the consumer-app version.

What the household actually wants automated

After several years of running the cognitive domicile pattern, the automations we actually use every day cluster into five categories:

Climate. Heating and cooling that respond to occupancy, weather forecast, electricity price, and time of day. The system pre-heats the bedroom before bedtime, lets the rest of the house cool overnight, and shifts heavy loads to the cheapest tariff window. The setpoints are dynamic, not fixed, and the energy savings versus a fixed-schedule thermostat are measurable.

Lighting. Circadian-aware colour temperature through the day, motion-driven activation in transitional spaces, scene-driven configurations in rooms used for specific tasks. The lights are not in any single state — they continuously adjust to the current context.

Security. Door, window, and motion sensors integrated with occupancy. The house arms itself when no one is home, disarms cleanly on return, and notifies us of anomalies during sleep windows.

Energy. Real-time consumption per circuit, solar production tracking when applicable, automatic shifting of dispatchable loads — laundry, dishwasher, hot water, electric vehicle — to the cheapest available tariff window. The savings are concrete and visible on the time-series dashboards.

Operational. The boring backbone. Notifications when the freezer temperature drifts. Automatic reordering of household consumables when the inventory drops below a threshold. Backup verification. The household equivalent of infrastructure observability.

Sensors first, automations second

The order of build matters. Most consumer smart-home failures start by buying actuators — bulbs, plugs, locks — and then trying to make them clever. The operator-grade approach starts by installing sensors, observing the house for a month, and only then writing automations against the patterns the sensors reveal.

Temperature sensors per room. Humidity per room, especially in spaces vulnerable to condensation. Motion in transitional zones. Door and window state. Power consumption per circuit. Air quality — particulate matter and carbon dioxide — at the rooms where people actually spend time. Soil moisture in any planted area that matters. Water flow at the main intake.

The full sensor footprint of a normal household, properly instrumented, runs to several dozen distinct streams. Every stream writes to the time-series store at a sensible interval. Within a month, the patterns are obvious: which rooms are too cold in the morning, which are too humid after showers, which appliances are drawing more than they should, which areas are most occupied and which are vestigial. The automations that follow are not guesses — they are responses to observed reality.

Voice in, AI out

The interface to the cognitive domicile is intentionally voice. Voice in, any time, anywhere in the house. A locally-running speech-to-text model transcribes the request. A locally-running language model interprets it, decides which tools to call, executes against the home automation, and speaks the result back through any available speaker. None of it leaves the house.

The capability profile is broader than the consumer voice assistants manage:

• Compound requests in natural language — turn off the upstairs lights and start the dishwasher when the off-peak window opens.
• Queries against the time-series store — how much electricity did the study draw last week.
• Read-and-respond against personal calendar, household inventory, and the internal knowledge base.
• Long-form reasoning that the consumer assistants will not attempt.

The privacy difference is total. Nothing about what is asked, what is answered, or what is done with the response is observable to any third party.

Energy is the durable case

Of all the categories we automate, energy is the one with the most concrete, repeatable financial case. UK and EU electricity tariffs are increasingly time-of-use and increasingly volatile. A household whose dispatchable loads — heating, hot water, dishwasher, laundry, electric vehicle, battery storage if applicable — automatically shift to the cheapest window saves in the order of hundreds of pounds a year against a naive-schedule equivalent. The savings compound. The capital cost of the instrumentation pays back inside two years for any household whose annual electricity bill is above modest.

The same logic applies, with greater margins, to households that have or are considering solar generation, battery storage, or heat pumps. The economics of all three depend on the controller's intelligence — a poorly-controlled heat pump is dramatically more expensive to run than a well-controlled one, and the difference is software. The cognitive domicile is, among other things, the only context in which most consumer electrical infrastructure delivers anything close to its theoretical performance.

What we do not automate

Three categories we deliberately leave manual:

• Anything that interrupts a person without strong cause. Notifications are aggressively curated. The default is silence. The discipline is the same as for a production paging system — only wake the operator for things the operator can act on.
• Voice broadcasts into rooms with people in them. The house does not talk unless asked. Ambient announcement is exhausting within a week.
• Anything related to small children. The automation surface is light around any space where a child might learn to expect a system to behave a certain way. Children will encounter every house in their lives without an automation layer; the parental household should not train them to expect otherwise.

The general principle is that the automation should be felt as the absence of friction, not the presence of intervention. When done correctly, visitors do not notice that the house is automated at all — they notice only that things work.

The phased build

For an operator considering a build of their own, the order we recommend, based on what we have seen work and not work:

1. Phase one, foundations. Hub on a dedicated low-power machine, time-series store, dashboards, mesh network. Six weekends of moderate work.
2. Phase two, sensing. Temperature, humidity, motion, energy, door and window state. Aim for total household coverage. Run for a month with no automations, just observation.
3. Phase three, the obvious automations. Climate, lighting, security. Conservative, observable, easily reverted.
4. Phase four, the non-obvious automations. Energy scheduling, household inventory, anomaly detection. These pay back the most and are the easiest to break — build them last and slowly.
5. Phase five, the voice layer. Local speech-to-text, language model interpretation, tool execution. Most rewarding to build, least foundational. Genuinely transformative once it works, frustrating when it doesn't.

Skipping any phase produces a stack that feels clever for a month and annoying for the rest of its life. The order matters.

Two further notes from experience. First, the documentation matters. Every automation, every sensor, every device should have a one-paragraph note that describes what it does and why. Six months later, when something stops working and the cause is non-obvious, that note is the difference between a twenty-minute fix and a wasted Saturday. Second, the back-out plan matters. Every automation we deploy is reversible from a single switch in the dashboard. The household has to be operable manually at all times, by anyone in it, regardless of whether the automation layer is up. That is the discipline that separates the operator-grade installation from the consumer-grade one. The automation is a layer on top of a manually-operable house, not a replacement for it.

What the household looks like once it is running

The signal of a successful build is that the household stops thinking about the automation. The lights are correct. The temperature is right. The energy bill is lower than it would be on a fixed schedule. The notifications are small in number and useful when they come. Visitors do not notice anything specific is automated, because the automation is felt as the absence of small annoyances rather than the presence of cleverness. The voice interface is reliable enough that asking it for things stops feeling experimental and starts feeling like the obvious way to interact with the building.

The harder benefit, the one that is difficult to communicate to anyone who has not lived in a properly-built version, is what happens to the operator's attention. The cumulative weight of small household friction — the things you keep meaning to do, the small adjustments you make through the day, the recurring decisions about temperature and lighting — drops to near-zero. That cognitive overhead, recovered, is genuinely valuable. The case for the build is partly economic and partly that, but the second part is the one operators report mattering most after the fact.

Related pillars