Every sensor has definite failure conditions

What it is

A sensor is not a general-purpose "environment perceiver": each one works reliably only within specific physical conditions and fails systematically outside them. Failure is not random noise — it is structured. A passive infrared (PIR) sensor will necessarily miss a person under specific conditions; a camera is necessarily blind under specific lighting. The envelope within which sensing is trustworthy is the sensor's operating envelope.

The commonest design mistake in automation is treating "the sensor is installed" as "the sensor is sensing". The two come apart precisely under failure conditions: the device is online, powered, and reporting — an empty world.

Why it happens

Failure conditions follow from the measurement principle, not from product quality. However expensive, a PIR sensor only detects change in infrared radiation: someone walking into the room triggers it; the same person fallen and lying still disappears; movement behind curtains or through glass is invisible. Likewise, millimetre-wave and ultrasonic sensing suffer multipath reflections and absorbing materials; cameras are defeated by backlight, darkness, and occlusion; microphones drown the target in noise and reverberation; a door contact reports only open/closed — not who, not whether anyone is really there. Every principle has physics it cannot see.

The danger lies in a second layer: a failing sensor does not report an error — it reports "no event". A motionless person reads as "room empty", indistinguishable in the data stream from a genuinely empty room. Automations that consume this as fact turn lights off, cut heating, and arm alarms while someone is still there.

Studying it

• Spec-condition testing: systematically vary lighting, distance, angle, and target motion speed in a controlled setting, mapping detection-rate curves. Vendor figures ("12 m detection range") are ideal-condition endpoints; effective range in a real home (partitions, furniture, pets, clothing thickness) shrinks noticeably and must be re-measured.
• Sensor–task matching: the activity recognition literature systematically compares which activities are recoverable from which sensors. Bao and Intille (2004) used multiple body-worn accelerometers to recognise twenty everyday activities with roughly 80% overall accuracy and huge variance across activities — evidence that "can this be recognised" is first a question of whether the information exists in the signal at all, not of model quality.
• Lab-to-field gap: comparing detection rates for the same sensor model between laboratory and real households is a standard design; the gap itself is an inventory of failure conditions.

Methodological caution: vendor test protocols cover nominal conditions. Real failure conditions — a person fallen still, night-time backlight, a pet passing — must be scripted by the researcher.

Where it stops holding

• Failure is not an error report. Most failures emit an innocent-looking "no event", which is why they are more dangerous than crashes: crashes get noticed, silent failures do not.
• Spec values do not transfer. Nominal range, field of view, and response time are ideal endpoints; home layouts take a discount that only field measurement can quantify.
• Safety functions on a single modality are a design defect. When a life-safety function (fall detection, gas) rests on one modality, reliability is a bet that this modality happens not to fail. How multi-sensor complementarity works is a sibling topic; here only the boundary judgement stands.

Applying it

• For every automation, keep a failure-condition list for each sensor involved (lighting, occlusion, stillness, range, materials, interferers) and ask, item by item, whether that condition occurs in this home.
• Safety-related functions: never single-modality. Convenience functions may be, if silent failure is an acceptable consequence.
• At deployment, measure the trigger boundary in the real environment: have every household member walk through in their everyday manner — slowest, quietest, and sitting still included — and log misses.
• How to check: collect moments when "the sensor reported nobody" and spot-check how many actually had someone present (camera review or diary). That fraction is the probability this automation fails silently.

Related

• Same group: Z2.01.2 Fusion raises confidence but amplifies privacy exposure · Z2.01.3 Failure must be expressed, not silently degraded
• Nearby: Z2.02 Uncertainty of inference · Z2.03 The costs of false positives and false negatives
• Search terms: sensor failure modes · operating envelope · PIR sensor · activity recognition