An exhibit should wake when someone approaches. A room device should know whether anyone is still there. Those sound similar, but the sensing requirements are different: detecting a change near the device is much easier than proving continuous occupancy.
An Arduino forum discussion about presence sensing for an art project makes the distinction explicit by asking what should count as a person rather than another object. On our bench we ran a simple PIR trigger experiment: a lens-equipped PIR module connected to a Raspberry Pi Pico on a GraftPort carrier, programmed in BIPES blocks that generate MicroPython. It answers one narrow question, and this note is about which one.
Begin with the demonstrated signal
The program reads GPIO9 with the internal pull-up enabled, checks for a high state, and waits 200 ms before checking again. When the input is high, it prints an "infrared sensor triggered" message.
The console showed repeated trigger lines, plus a KeyboardInterrupt from an earlier run that we stopped by hand. Repeated lines mean the input was high on repeated checks. They do not count separate people or separate approaches: a single movement can hold the output high across many 200 ms polls. We did not measure a detection boundary, and we did not compare different targets or movement types.
Two firmware points follow directly. First, if the product needs to count events, detect the rising edge, not the level. Second, check what the module's output does when it is idle; a pull-up on an input that the module drives actively may be harmless, but it should be a decision rather than a default carried over from a button example.
Match the interaction to a change detector
Panasonic's PIR explanation describes these sensors as responding to changes in infrared energy. That supports an approach-triggered interaction well. It leaves a gap for a person who is present but still: silence from a PIR should not automatically be read as an empty room.
The lens, the mounting direction and the environment shape what movement is observed. A short-distance description that comes with a module is not a verified detection range for your installation. Test the intended approach paths and the ordinary background activity in the actual arrangement before choosing a response rule. Include the cases you do not want to trigger on: people walking past, doors, heating vents, sunlight moving across a wall.
Turn the raw state into a product rule
For a first exhibit prototype, the desired behavior might be to wake the display after a trigger and keep it active for a defined interval. That is an application rule, separate from the sensor's raw state, and it needs a few explicit decisions:
- Does further motion extend the interval, and by how much?
- What happens when somebody stands still in front of the exhibit and the sensor goes quiet?
- How long after waking can it trigger again, so the display does not flicker on and off at the edge of the field?
Write those rules down and test them with people walking the real paths, not only with a hand waved in front of the lens on the bench.
Keep the claim within what the sensor observes
A motion-triggered display remains a response to a sensor condition. A product requirement for dependable stationary occupancy, person counting or identifying a human rather than another warm object calls for different evidence and possibly a different sensing approach, or a combination of sensors.
State the user-facing behavior in the same terms the sensor supports: "wakes when someone approaches" is a claim a PIR test can back up; "knows when the room is empty" is not, until you have tested people sitting still for long periods in the real space.