Failure must be expressed, not silently degraded

What it is

When a sensor fails, the system's commonest behaviour is to carry on as if nothing happened: reports stop or go permanently empty, and upper layers keep treating this as "no events detected" — fail-silent degradation. The correct behaviour is the opposite: failure itself must become an explicitly expressed state ("sensor offline"), kept distinct from "no event".

Why the distinction matters: "nobody is here" and "unknown whether anybody is here" are opposite inputs. An automation that consumes "unknown" as "nobody" turns lights off and cuts heating while someone is present, and disarms an alarm in front of an intruder.

Why it happens

The root is in the data layer: absence and zero are indistinguishable. After a sensor dies, the stream carries either nulls or a constant value — the same encoding as "a healthy sensor watching a quiet room". Without a dedicated mechanism, upper layers can never know. That mechanism must be active: sensors emit a periodic heartbeat, and silence beyond a timeout marks them offline; or they run periodic self-tests (built-in test targets, reference signals) that catch "output constant while the environment should be varying".

A behavioural layer compounds it: expressing failure is a liability for products — a red "sensor offline" badge invites distrust — so many products hide offline states by default. The cost is transferred: when the fault surfaces physically (the light that never came on), the user faces a clueless black box, and attribution escalates from "this device is broken" to distrust of the whole system.

Studying it

• Fault injection: deliberately induce offline, constant-value, and drifting sensors, then observe upper-layer behaviour and user-facing presentation — logging which functions consume failure as "no event". The most protocolised method; scales across cases.
• Field studies of smart home troubleshooting: interviews and log analyses with real households consistently find users unable to distinguish device faults from network drops from rule errors, resorting to trial and error; absent failure-state expression is the leading cause of attribution difficulty.
• Degradation design comparisons: contrast silent degradation against declared degradation (explicit notice + conservative defaults) on user trust and recovery time.

Methodological caution: include partial failures — sensitivity decay and intermittent dropouts. Total offline is easy for a heartbeat to catch; partial failure looks nearly identical to healthy data and is the more realistic threat.

Where it stops holding

• Self-tests are not omniscient. Failures whose output "looks plausible but is wrong" (sensitivity drift, spurious triggers) go undetected — self-testing covers structural failure (no signal, constant value), not semantic failure.
• Heartbeats depend on network and power. With power or connectivity gone, the sensor cannot even say "I have failed" — the expression channel itself fails, so a physical last resort (local light or sound) cannot be entirely dispensed with.
• Expression needs a paired degradation behaviour. Reporting "offline" while the automation keeps consuming the missing stream as "nobody" is still fail-silent; notice and conservative default must ship together.

Applying it

• Maintain a health heartbeat and last-seen time per sensor; past a timeout, mark it in the interface with "offline for X hours".
• When a sensor goes offline, automations that depend on it enter a declared conservative default: lighting holds its current state rather than switching everything off; security stays armed rather than disarming — prefer caution over deciding on missing data.
• Critical sensors trigger an active notification on going offline; do not wait for the user to notice abnormal behaviour.
• How to check: unplug each sensor in turn and watch the system. Passing requires all three: an offline mark appears, dependent automations enter conservative defaults, and the user is notified. Any silent leg is one more fail-silent degradation.

Related

• Same group: Z2.01.1 Every sensor has definite failure conditions · Z2.01.2 Fusion raises confidence but amplifies privacy exposure
• Nearby: Z2.09 Freshness and expiry of context · Z4.09 Faults, disconnection, and degradation
• Search terms: fail-silent · fault injection · sensor health monitoring · graceful degradation