One device leaving the ecosystem degrades whole scenes

What it is

Scenes bind several devices into one whole, at the price that when any one of them exits, what breaks is not "that device's function" but every scene routed through it. Exit comes in three forms — the device dies, gets replaced, or its service shuts down (cloud sunset or vendor bankruptcy) — and all share the same asymmetry: the user expects to lose one device and actually loses a cluster of functions.

A dead door sensor costs more than door sensing: it is the trigger of "lights on arriving home", "arm on leaving", and "door-left-open alerts" — three things stop at once, and they stop silently. Scenes don't raise errors; they simply never happen again.

Why it happens

A scene set is a dependency graph: trigger device → rule → actuator. The graph's availability is the product of its nodes' availabilities; one exits, and every path through it breaks. Three amplifiers follow:

• Silent disconnection. Devices rarely exit explicitly — they go dark (dead battery, replaced, cloud shut). Platforms typically handle a lost device by waiting for reconnection rather than reporting, so dependent scenes enter a "will never trigger again" state with no notice.
• Trigger concentration. As an ecosystem grows, a few high-value devices (a door sensor, the voice assistant, phone presence) accumulate as the shared trigger of many scenes — dependence on the single point deepens with use, unnoticed by the user, until the sensor over the door is carrying a dozen rules.
• Exit is not deletion. After a service sunset the device may remain "online" but crippled, with rules still referencing it; replacing a device does not migrate old rules to the new one. Zombie nodes linger in the graph, and new scenes built atop them behave unpredictably.

Studying it

• Dependency-graph analysis: export a household's rules and devices, build the graph, compute each device's fan-out (how many scenes route through it). Fan-out distribution is a measurable concentration metric — smart-home research has used such data to show ecosystems' hidden dependence on a few hub devices.
• Service-sunset case studies: the traces users leave in forums and social platforms after a vendor folds — pleas, migration logs, abandonment narratives — form a natural corpus for exit costs.
• Fault injection: disable a single hub device in a test setup and observe dependent scenes (silent stop / error / degrade), measuring how long the exit goes unnoticed.

One methodological caution: dependency graphs exist only where platforms allow export, biasing samples toward open-platform users; community corpora have survivorship bias (those who gave up entirely leave no trace), so abandonment is undercounted.

Where it stops holding

• The damage tracks a device's position in the graph, not its price. A three-dollar sensor can hold half the house's scenes hostage; a dead three-thousand-dollar panel may cost only itself. Budget redundancy by fan-out, never by device value.
• One-way actuator exits hurt less. A broken bulb makes the scene fire to no effect — local, visible loss. Trigger-side exits are the main form of silent disconnection.
• Scenes with local fallback are the exception. Some scenes degrade gracefully when the trigger vanishes (manual trigger remains); whether a fallback exists is a platform design decision users cannot presume.

Applying it

• Identify and duplicate hub devices: give the highest fan-out triggers (usually two or three) a twin — two sensors in AND/OR, or a manual trigger retained. The redundancy budget for a hub follows the number of scenes it carries, not its price tag.
• When a device has been unreachable past a threshold, enumerate and announce the affected scenes: "door sensor offline 24 hours; these 5 scenes are suspended" — silence is this failure's largest amplifier.
• On device replacement, migrate, don't rebuild: rule references should follow the replacement or demand explicit disposal (confirmed one by one); no zombie nodes left in the graph.
• How to check: each season, export the dependency graph and count the largest fan-out; run a pretend-unreachable drill on the top device and see whether the platform reports — or acts as if nothing happened.

Related

• Same group: Z1.06.1 Device coordination requires mutually readable state · Z1.06.2 Mixed-brand ecosystems: protocol differences block coordination · Z1.06.4 Coordination relationships must be inspectable, not implicit backstage
• Nearby: Z4.04 Device lifecycles · Z1.07 Distribution and aggregation of interaction
• Search terms: cascading failure · single point of failure · smart home dependency · cloud shutdown