PIR Motion Sensor + Buzzer

By the end of this project, you will:

• Understand how a PIR sensor detects movement, and what it cannot detect.
• Wire a 5 V sensor to the ESP32 safely and know why it uses VIN rather than 3V3.
• Use millis() to build a non-blocking timer and explain why delay() is the wrong tool for it.
• Track state across loop iterations with a flag, so an event fires once instead of continuously.
• Build a small alarm that holds its output for a few seconds after the last movement.

• A PIR senses the infra‑red heat of living bodies and triggers on change, a warm, moving object.
• OUT = HIGH on motion, LOW otherwise.
• A person standing perfectly still may not be detected; a moving heat‑less object (robot, car) isn't either.

The two orange trimmers adjust sensitivity/range and time delay. The jumper (usually labeled H and L) selects retrigger mode:

• H (repeatable trigger, the default): each new motion during the sensor's own delay window resets that window, so its output stays HIGH as long as something keeps moving.
• L (single trigger): the output goes HIGH once, holds for the delay set by the time‑delay trimmer, then drops LOW and ignores further motion for about 2.5 s, even if something is still moving.

Defaults (H, trimmers centered) are fine for this project. If the buzzer holds on far longer than the sketch's own 3‑second holdTime, someone is still moving in front of the sensor and H mode keeps resetting the sensor's output: that's expected, not a bug (see Troubleshooting).

delay(3000) freezes the whole program for 3 s. Instead we record when motion last happened and check elapsed time: keeping the loop responsive:

lastMotionTime = millis();                    // remember "now"
if (millis() - lastMotionTime >= holdTime) {  // has enough time passed?
  ...
}

This pattern scales to programs doing many things at once, a habit worth building early.

Let's walk through the sketch so you understand what each line does and why.

Step 1: Pins, the hold time, and the state we remember

const int buzzerPin    = 26;  // active buzzer -> GPIO 26
const int motionSensor = 27;  // PIR OUT       -> GPIO 27

const long holdTime = 3000;         // hold the buzzer this long (ms)
unsigned long lastMotionTime = 0;  // when motion was last seen
bool alarmActive = false;           // is the buzzer sounding right now?

Two variables carry the logic. lastMotionTime is a timestamp, not a countdown: it stores the moment motion was last seen. alarmActive is a flag recording what the program already did, which stops the buzzer being switched on again on every pass through loop().

Step 2: one-time preparation in setup()

pinMode(buzzerPin, OUTPUT);      // the buzzer is driven by the ESP32
pinMode(motionSensor, INPUT);    // the PIR drives this pin
digitalWrite(buzzerPin, LOW);    // start silent

Note the explicit digitalWrite(buzzerPin, LOW). A freshly configured output pin is not guaranteed to be in the state you want, and starting an alarm project with an unexpected beep is a poor demo.

Step 3: loop() watches for motion and times the hold

void loop() {
  bool motion = (digitalRead(motionSensor) == HIGH);

  if (motion) {
    lastMotionTime = millis();          // remember when we last saw motion
    if (!alarmActive) {                 // only act on the RISING edge
      digitalWrite(buzzerPin, HIGH);
      alarmActive = true;
      Serial.println("[EVENT] MOTION detected  -> buzzer ON");
    }
  } else {
    // No motion now: stop once the hold time has elapsed.
    if (alarmActive && (millis() - lastMotionTime >= holdTime)) {
      digitalWrite(buzzerPin, LOW);
      alarmActive = false;
      Serial.println("[EVENT] No motion (hold elapsed) -> buzzer OFF");
    }
  }
}

Read it as two questions asked thousands of times per second: is there motion right now? and, if not, has it been quiet long enough to stop? Because the loop never blocks, the sensor is still read while the hold counts down, so fresh motion pushes lastMotionTime forward and extends the alarm.

Key concepts: what each line really does

Expected output on the Serial Monitor

==============================================
 Project 4: ESP32 PIR Motion Sensor + Buzzer
==============================================
PIR OUT -> GPIO 27
Buzzer  -> GPIO 26
Buzzer holds ON for 3000 ms after motion stops.
NOTE: the PIR needs ~30-60 s to warm up after power-on.
----------------------------------------------
[EVENT] MOTION detected  -> buzzer ON
[EVENT] No motion (hold elapsed) -> buzzer OFF

Going further: swap in the obstacle-avoidance module

The kit's obstacle‑avoidance module reads exactly like the PIR: a digital pin that goes HIGH or LOW depending on what its sensor sees, this time IR reflectance instead of body heat.

The trimmer on the module sets detection distance: turn it to tune how close an object has to get before OUT goes HIGH. digitalRead(motionSensor) in the sketch above doesn't change at all: an obstacle module and a PIR are both "is something there right now" sensors, just tuned to different physics.

This is the sensor half of Project 13's Obstacle alarm idea.

You now have a sensor driving an actuator, with timing that does not freeze the program. The key takeaways:

• A PIR sensor reports change in infra-red heat, so it sees a moving warm body but not a still one, and not a cold moving object. It also needs 30 to 60 s to warm up.
• Some modules need 5 V. VIN supplies it while the board is USB-powered, and the HC-SR501's 3.3 V output is safe to feed back into a GPIO.
• millis() gives you a clock that never stops. Storing a timestamp and subtracting it later is the standard non-blocking timer pattern.
• delay() would have worked here but blocks everything. Once a project has two things to do at once (Projects 8 and 11 do), blocking code stops being an option.
• A state flag like alarmActive lets the program tell a new event from an ongoing condition, which keeps the log clean and the output stable.

Now try

• Countdown timer: Instead of a fixed hold time, display a countdown on the Serial Monitor ("Alarm active, 3s remaining... 2s... 1s...").
• Obstacle-avoidance swap: Replace the PIR with the kit's obstacle-avoidance module. It reads the same way (digital HIGH/LOW) but must be powered from 3.3 V, not 5 V.