Z1.07.3Loss of the aggregation pointdesign

Losing the aggregation point costs control of the whole system

Aliases: hub outage · control hub failure

What it is

Distributed entry points need an aggregation point — the companion app, the gateway, the voice platform — to unify state and rules. When that point fails (power, network, cloud outage, app that won't open), the loss is not "one fewer entry point" but loss of control over the whole system: everything aggregated through it becomes unreachable at once, and it aggregated most things.

The failure's shape is routinely underestimated: not a black screen with an error, but stuck mid-state. With the aggregation point gone, devices keep executing their last commands and automations keep running on old rules, but the user can neither edit rules nor stop actions — the system isn't dead, it is "alive and deaf to command", which is worse than dead.

Why it happens

Why does one fallen hub paralyse the house? Because it hosts three irreplaceable things:

  • The rules' host. Most scene logic runs on the aggregation point (or its cloud); its failure stops the rules — triggers keep arriving (sensors still report), but nothing interprets or dispatches them.
  • The state junction. Each device's state assembles into a whole-house picture only at the aggregation point; after failure each entry holds only its directly connected sliver, and nowhere can see the whole.
  • The control router. Cross-device commands ("away mode" touches ten devices) require the aggregation point's routing table; afterwards users must go device by device — a mode of operation they have never practised, since its existence depended on aggregation.

One level deeper is the contagion direction of failure: a distributed system can be designed for partial failure (lose one unit, lose that unit's functions), but concentrating intelligence into the aggregation point rewrites the failure structure as centralised — the point's availability caps the house's availability. Devices whose physical switches still work go unused anyway, because control habits have fully migrated to the aggregated entry.

Where it stops holding

  • Outage duration sets the damage tier. A ten-second blip reads as latency; an overnight hub failure exposes every ounce of the user's rust at manual per-device control. Severity tracks recovery-time distribution, not failure rate.
  • Local and cloud aggregation fail differently. A local gateway cuts one segment of the house; a cloud aggregation point cuts every remote entry plus all cloud-side rules — with a cloud-dependent hub, being home doesn't help. Which side the hub sits on decides which failures hurt most.
  • Hub failure is not device failure. When devices are healthy but unreachable, fixing the aggregation point restores everything; conflating the two sends users into pointless device reboots and resets that create fresh problems.

Applying it

  • Physicalise the fallback control path: keep for every consequential device a local control route that bypasses the aggregation point (physical switch, IR remote, direct Bluetooth) — and keep it marginally alive in daily use, or it will be useless on failure day.
  • Degrade, don't blank, when the aggregation point fails: entry interfaces state "hub unreachable" and list what remains operable (which devices still respond directly), instead of a mute screen that invites retries without feedback.
  • Local rule fallback: critical scenes (security, heating) retreat to a minimal set executable device-to-device locally when the hub is lost, rather than halting outright.
  • How to check: run an "unplug the hub" drill — gateway off or cloud service logged out for twenty-four hours — and track the household's success rate and detour paths for basic operations. Any operation with a low completion rate marks where the fallback wasn't built.

Related

  • Same group: Z1.07.1 Interaction capability spreads across many devices instead of one place · Z1.07.2 Distributed interaction needs consistent entry points to stay manageable · Z1.07.4 Over-aggregation into a single entry point builds single-point-of-failure risk
  • Nearby: Z4.03 Network loss and degradation · Z4.09 Faults, disconnection, and degraded modes
  • Search terms: hub outage · graceful degradation · local control fallback · single point of control

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Z1.07.3