A fault may sit in the device, network, or rule layer

What it is

Every automation in a smart environment runs on a serial, layered chain: the device layer (does the sensor or actuator hardware work), the network layer (do messages get through), the rule layer (does the logic actually fire). The same complaint — "the light didn't turn off on schedule" — could originate in any of the three. The first step of diagnosis is not repair but locating the layer.

Locating the fault to a layer first is the foundation of troubleshooting method in this space. Layered troubleshooting is a long tradition in IT operations — isolate from physical connectivity up to application logic. Smart environments import that discipline into the home and add a layer traditional networks never had: the rule layer, user-configured conditional logic that fails in ways no error message ever reports.

Why it happens

Why can't the symptom point at the layer directly? Because the chain is a serial dependency: break any link and everything downstream looks the same — the action never happens. The symptom is the absence of output at the end of the chain, and it structurally conceals upstream causes.

The three layers have distinct faces, but the faces overlap:

• The device layer offers the most physical clues: no response, abnormal indicator, dead battery — yet a device that is online but non-compliant may simply be dropping packets.
• The network layer is the trickiest: faults are often intermittent (signal edges, congestion, roaming), symptoms come and go, and things "mysteriously" improve after a restart — hardest to distinguish from the other two.
• The rule layer is the blind spot specific to automation systems: its failures are silent — a condition that can never be true, a result overridden by another rule, a timezone or unit mismatch. No error, no physical clue, only the negative symptom "didn't fire".

Layers also impersonate each other: power is a cross-layer common factor (an outage looks like a network fault); a rule firing too often drains a battery-powered device (a rule-layer cause presenting as a device-layer fault). Acting before localising the layer is searching for keys on the wrong floor.

Studying it

• Challenge checklists for real homes: Edwards and Grinter's classic analysis of ubiquitous computing meeting domestic reality lists "who troubleshoots when it breaks" among the problems lab prototypes never face but homes always do — the cross-layer nature of faults is the technical root of that unclear responsibility.
• Troubleshooting interviews: field studies asking users to reconstruct their last fault hunt consistently show a jump from symptom straight to action (restart / replace / abandon), with no intermediate layer-attribution step — evidence both for this entry and for the missing diagnostic tools.
• Fault injection: inject faults into controlled deployments at each layer in turn (kill the device, kill the network, break the rule), measuring the proportion of users who localise to the correct layer, time taken, and misattribution rates. This is the paradigm that treats layer attribution as the dependent variable.

One methodological caution: injected faults are easy to separate in the lab (clean conditions), but real domestic faults are frequently multi-layer (a power cut disrupts devices and network at once); single-layer injection alone yields systematically optimistic conclusions about users' ability to localise.

Where it stops holding

• Three layers is the common domestic cut, not a universal truth. In more complex ecosystems the cloud deserves its own layer (remote rule execution and voice entry points depend on it); the granularity should follow fault-responsibility boundaries, not a checklist.
• Users can self-check only some layers. Physical inspection of devices and simple connectivity checks (can the phone on the same network control it) can be delegated to users; the rule layer has no physical clue at all — the product must provide trigger records, or the layer stays a permanent black box.
• Layer attribution must not be fully automated. The system may suggest "likely the network layer", but turning attribution into an automatic verdict removes the user's chance to verify — a mis-attributing machine is harder to correct than no attribution.

Applying it

• Fix the path for "the action didn't happen" as three ordered questions: is the device online → is the local network reachable → has the rule fired recently. Each question carries a tappable self-check, not a hope that users think of it themselves.
• The rule layer must keep trigger logs (which condition matched, when) — it is the only layer with no physical clue.
• Record cross-layer events to unmask impersonation: put device offline moments and rule firing moments on one timeline, and let a battery device's "unexplained" offline spells be traceable to the high-frequency rules it participates in.
• How to check: inject one fault in each of the three layers, count correct-layer localisation rate and time; run one round before and one after shipping a triage wizard. If the localisation rate does not rise, the troubleshooting path is not actually organised by layer.

Related

• Same group: Z7.02.2 Users lack the tools to localise faults · Z7.02.3 Layered status display is the precondition for diagnosis
• Nearby: Z4.09 Faults, disconnection and degradation · Z5.03 Traceable causation
• Search terms: layered troubleshooting · fault localization · smart home maintenance · at home with ubiquitous computing