Beyond Smart Switches: Building a Cyber-Physical Digital Twin for Home Automation

Most smart home setups are a pile of independent rules: if this switch flips, do that thing. It works right up until two rules need to agree on what's actually true in the house at the same moment, and neither of them has anywhere to check. There's no shared model of the space — just a stack of triggers that happen to usually not contradict each other.

This post is a progress log, not a finished architecture. The backend and UI for the digital twin exist and work; the sensor fleet that's supposed to feed it real data does not, yet.

The idea: model the house, not the switches

Instead of automations reacting to raw device events, everything routes through one model of the physical space — rooms, fixtures, sensors, and their current state, all queryable as one source of truth. A rule doesn't ask "did this switch fire," it asks "what's the state of the living room right now," which means every rule is reasoning over the same picture instead of independently reconstructing it from whichever event happened to arrive.

Where it actually stands

Floor plan generation is working. Given a residential listing, the twin's backend can generate the floor plan for the space directly — rooms, boundaries, and layout — rather than requiring it to be modeled by hand room by room.
The taxonomy is done. Every entity type the twin will ever track — room types, fixture types, sensor categories — has a defined place in the model. This is the "what kinds of things exist" layer.
The ontology is next. Taxonomy says what things are; ontology is how they relate — which sensors belong to which room, which fixtures depend on which conditions, what "occupied" actually means when three different sensor types disagree. That's the current work.
Real telemetry hasn't arrived yet. A couple of Shelly devices — temperature/humidity and motion-class sensors — are inbound and will be the first hardware to actually feed the model, rather than the model being exercised with synthetic or manually-entered state.

The event contract that ties it together

The design commits to one canonical event shape for every device, regardless of vendor. A Shelly sensor and whatever comes after it both normalize down to the same structure before the twin ever sees them:

{
  "device_id": "sensor-livingroom-01",
  "metric": "temperature",
  "value": 22.4,
  "unit": "C",
  "ts": "2026-07-18T09:00:00Z",
  "source": "shelly"
}

The bet is that defining this contract — and the taxonomy and ontology behind it — before wiring up hardware is worth the delay. Every future device, whatever protocol it speaks, is an adapter that maps into this one shape. Nothing upstream of that adapter ever has to know or care that it changed.

Why bother with all of this before a single sensor reports in

Because the failure mode I'm avoiding isn't "the lights don't come on," it's "the lights come on based on a rule that no longer has any relationship to what the house actually looks like." A model that's slow to arrive but actually shared beats a pile of automations that are fast to write and individually blind to each other. The Shelly devices arriving next are the first real test of whether that bet was worth it.

Next post: the same build-vs-buy question this project keeps raising — when a custom tool like this twin is worth owning, and when it isn't.