Z2.04.1Occupancy versus identificationdesignresearch

Detecting someone present is not knowing who

Aliases: presence sensing · occupancy detection · identity levels

What it is

"Someone is in the room" and "who that someone is" are two different capability levels: occupancy detection answers whether anyone is present; identification answers who. Passive infrared and millimetre-wave know only the former; phone-based presence knows "this phone is here", not who holds it; face and voice reach identity. Each step up the ladder raises capability — and simultaneously raises privacy cost and misidentification risk.

A large class of smart-behaviour failures comes from level mismatch: consuming "someone is present" as "a specific person" — a guest triggers the owner's personalisation, a family member gets treated as an intruder, the cleaner's presence reads as "nobody home".

Why it happens

Three rungs, each with its own capability boundary and privacy price:

  • Anonymous presence (PIR, ultrasonic, millimetre-wave): knows "someone / no one", cannot individuate. Lowest privacy cost, zero misidentification risk — it never distinguishes people at all.
  • Device association (phone or watch beacons, Wi-Fi presence): substitutes the device for the person — it recognises the phone, not the human. The binding assumption ("phone here = person here") fails systematically in three ways: a phone charging at home reads as permanently home; family members swap phones; with several people present, it cannot tell who is doing what.
  • Biometrics (face, voice, gait): identifies the person directly, but collects the most sensitively, degrades most with conditions (home lighting, angle, and distance all depart from lab settings), and carries the heaviest consequences when wrong.

The mismatch cuts both ways: an identity-needing function wired to anonymous sensing (no one's personalisation works), and a presence-only function wired to biometrics (a face to turn on a light — privacy cost and failure surface both inflated for nothing). Match the level to the function's minimum requirement — neither above nor below.

Studying it

  • In-home presence studies: deployments of presence-aware computing consistently find that device-associated presence (Bluetooth/Wi-Fi detection) misstates "who is home" with stable error — forgotten phones, powered-off devices, and several people sharing a room are the main error sources (a generalisable finding across ubiquitous-computing deployment literature).
  • Environmental effects on recognition accuracy: evaluations of face and voice recognition under household conditions (lighting, angle, reverberation) show error rates climbing as conditions depart from enrolment; uneven error rates across demographic groups are extensively documented in the face-recognition literature (state the phenomenon generally, without citing specific figures).
  • Level-requirement analysis: walking the automation inventory item by item asking "what is the minimum level this function needs" is a standard step in deployment studies.

Methodological caution: laboratory recognition accuracy presumes cooperative pose and calibrated lighting; recognition at home happens in natural posture, backlight, distance, and multi-person frames — evaluate under home conditions, not door-access conditions.

Where it stops holding

  • The "phone = person" assumption fails by the hour, not the day. Charging, left behind, silenced — daily routine manufactures exceptions; households relying on phone presence for "away" automations periodically experience "nobody" actions executed while someone is home.
  • Device association loses resolution with co-residents. With two phones home, "who is in the living room" remains unknown — distinguishing individuals requires moving up the ladder, and the privacy cost rises with it; make that trade explicitly.
  • Biometric accuracy claims are nominal-condition figures. Real error rates under home lighting and angles exceed the lab values; choose the level on field measurements, not the product page.

Applying it

  • Annotate every automation with its minimum identity level (presence / device / person) and provision sensing at that level; where a lower level backs a higher-level need, redesign the trigger instead of forcing recognition.
  • When identity is uncertain, degrade to presence-level behaviour and say so: the personalised greeting falls back to a generic one, "welcome home" falls back to "lights on".
  • For situations that truly need to distinguish individuals (per-person personalisation, per-person permissions), explicitly price the upgrade to biometrics — privacy cost and misidentification risk together.
  • How to check: stage guest-present scenarios (a friend walks in; the phone owner is in the bedroom while a guest sits in the living room) and verify each automation's triggered identity against expectation. Any path that treats the guest as the owner is a level-mismatch defect.

Related

  • Same group: Z2.04.2 Misidentification leaks other people's data · Z2.04.3 Visitors and temporary occupants need a default policy
  • Nearby: Z1.03 Defining context · Z4.07 Multi-user permission assignment
  • Search terms: occupancy detection · presence sensing · person identification · smart home personalization

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Z2.04.1