ESP32 presence detection is one of the most useful patterns in home automation and IoT because it turns a low-cost microcontroller into a room-awareness layer. The real question is not whether an ESP32 can sense occupancy, but which method will stay reliable for people, devices, and objects in the environment you actually have. In practice, the answer depends on whether you need motion, stationary presence, or direct object detection, because those are three different problems.
The best result comes from matching the sensor to the kind of presence you need
- Motion is easy to detect; stationary presence is harder and usually needs mmWave radar or a similar continuous sensor.
- If you are tracking people carrying phones or wearables, BLE can work well, but it is not universal.
- If you mean objects, the best answer is often a direct sensor such as ToF, a beam-break, a load cell, or a switch.
- Wi-Fi CSI is powerful, but it is still a more advanced and experimental route than most projects need.
- For a dependable smart-home build, I would usually start with mmWave + ESP32 before reaching for clever radio inference.
Why presence is not the same as motion
Most confusion around occupancy sensing starts here. Motion detection tells you that something changed in the scene; presence detection tells you that something is still there, even if it is sitting quietly reading, typing, or watching television. That difference matters because a PIR sensor can be brilliant for a corridor light and still be the wrong tool for a living room, office, or bedroom.
For people, I think in terms of continuous confirmation. If the person stops moving, the system should still know they are there. For objects, the problem changes again: a box on a shelf, a parcel in a tray, or a tool in a dock is usually best handled by sensing the object directly rather than trying to infer it from body movement or radio reflections.
When a PIR is enough
A PIR is still the right answer when you only need a cheap trigger based on movement. It is simple, low power, and easy to wire, which is why I still use it for basic hallway automation and outdoor alerts. The limitation is blunt: once the person stops moving, the PIR stops caring.
Read Also: Smart Thermostat - The Perfect IoT Example Explained
When presence needs a different strategy
As soon as the requirement becomes “keep the lights on while someone is still in the room,” “hold the HVAC state while the office is occupied,” or “know whether a package is still on the tray,” you need a sensor that sees more than motion. That is where the sensor choice starts to matter, and where the trade-offs become much more interesting.
Once that distinction is clear, the next step is comparing the sensing methods that actually make sense on an ESP32.
The sensor types that actually make sense
For ESP32-based occupancy work, I usually think in five buckets: PIR, mmWave radar, BLE tracking, Wi-Fi CSI, and direct object sensors. ESP32 presence detection only becomes reliable when you stop treating all of those as interchangeable. They solve different problems, and the wrong one in the wrong room leads to unstable automations.
| Method | Best for | Main weakness | My take | Typical UK cost |
|---|---|---|---|---|
| PIR | Simple motion triggers | Cannot reliably see still people | Good for cheap lights, not true presence | About £2 to £6 |
| mmWave radar | People sitting or standing still | Needs tuning and sensible placement | Best general-purpose choice for rooms | About £8 to £25 |
| BLE tracking | Phones, watches, tagged devices | Depends on the person carrying a device | Useful, but not a human-presence universal | Low if you already own the device |
| Wi-Fi CSI | Advanced sensing and research builds | Calibration and implementation effort | Interesting, but not my first production choice | Low hardware cost, high engineering cost |
| ToF, beam-break, load cell, switch | Objects and physical state | Requires direct geometry or contact | Usually the right answer for object presence | About £3 to £15 |
For people, mmWave radar is the strongest default because it can detect tiny movement and keep reporting occupancy after the person stops moving. That is why it behaves much better than a PIR in a real room. For object detection, though, I would usually bypass radio entirely and use a sensor that measures the object itself. A shelf, a dock, a box, or a tray is often easier to monitor with direct sensing than with inference.
Two implementation details matter here. First, many radar modules speak UART, and that gives you proper configuration control rather than a binary on/off output. Second, ESP32 boards already give you Wi-Fi and BLE, so you can keep everything local and avoid extra gateways when the project is built sensibly. That combination is what makes the platform attractive in IoT work.
With the sensor choice mapped out, the real work becomes placement, calibration, and logic design.
How I would build a dependable setup
I start by defining the state I actually want the automation to hold. If the goal is “someone is in the room,” the system needs immediate activation and slower release. If the goal is “an object is on the shelf,” it needs a different threshold, maybe even a different physical sensor. When the state definition is vague, the automation is vague too.
- Pick the sensing mode first. Use PIR for motion, mmWave for room occupancy, BLE for device-based presence, and direct sensors for objects.
- Mount the sensor for stable geometry. Radar performs better when it is not aimed at moving curtains, fans, heaters, or reflective metal surfaces.
- Use a clear state machine. I prefer an immediate “occupied” transition and a delayed “clear” transition, often somewhere in the 30 to 120 second range for rooms.
- Keep the logic local. Publish the state to your automation bus, but avoid cloud dependence unless you genuinely need remote analytics.
- Choose the right interface. For radar modules, proper UART wiring is usually worth it because it lets you tune sensitivity, zones, and timing.
- Test in the actual room. A lab bench is not a living room, and a hallway is not a desk. Reflections, human behaviour, and furniture arrangement change the result.
On radar modules, I also prefer hardware serial once the prototype starts to matter. Some modules ship with baud rates such as 115200 or 256000 depending on firmware, and that is one of those boring details that saves you from flaky behaviour later. A presence sensor that cannot survive a reboot or a noisy serial link is not finished, even if it looks good in a demo.
When the build is done this way, the remaining problems are usually not “can it detect presence?” but “where will it fail, and why?”
Where projects go wrong
The biggest mistake is calling any motion sensor a presence sensor. That works only until someone sits still. The second mistake is assuming the room will behave like a reference video. Real homes have radiators, glass, curtains, pets, ceiling fans, and furniture that all affect the signal in different ways. In UK flats and terraced houses, smaller rooms can actually make bad placement more obvious because reflections arrive faster and overlap more aggressively.
- False occupancy happens when the sensor sees reflections from movement outside the target zone.
- False vacancy happens when the person is still, blocked by furniture, or outside the sensor’s effective angle.
- RAM pressure becomes real when BLE tracking is combined with other heavy features on the same device.
- Poor tuning makes radar feel unpredictable, when the real issue is that the default zone or sensitivity was never adapted to the room.
- Overreaching on CSI creates a research project instead of a reliable product, because Wi-Fi sensing needs proper calibration and careful software work.
ESPHome’s documentation is explicit that BLE presence tracking consumes a significant amount of RAM, and that is a useful warning even if you are not building inside ESPHome itself. The lesson is general: if you stack too many features onto a small board, reliability drops before you expect it to.
Privacy is the other failure mode people underweight. Presence sensing can become surveillance-adjacent very quickly, especially if you start storing occupancy histories or device identifiers. My rule is simple: keep the signal local, keep the retention short, and avoid collecting anything you do not need. That becomes even more important once the system is used in a home or small office rather than a lab.Those failure patterns are easier to avoid once you decide which use case you are actually building for.
Which approach fits each IoT job
When I map presence sensing to real projects, I stop asking “what is the coolest sensor?” and start asking “what is the most honest sensor for the job?” That change usually saves time, money, and a lot of automation debugging.
| Use case | Best fit | Why it works |
|---|---|---|
| Hallway light | PIR or mmWave | You mainly need movement, and a fast trigger matters more than micro-presence. |
| Living room occupancy | mmWave | People sit still for long periods, so a motion-only sensor will clear too early. |
| Desk presence | mmWave or BLE | Radar is best for the person; BLE is useful if the room state should follow a known device. |
| Bathroom occupancy | mmWave | Quiet stillness is common, and continuous presence matters more than motion bursts. |
| Box, tray, or shelf | ToF, beam-break, load cell, or switch | Objects are easier to measure directly than to infer from room activity. |
| Experimental sensing project | Wi-Fi CSI | It is flexible and powerful, but it needs serious calibration and software discipline. |
That table is the point where most buying decisions become obvious. If you need room occupancy, choose a sensor that understands still people. If you need object state, choose a sensor that can measure the object or its position directly. If you want phone-based occupancy, BLE is a neat shortcut, but only when device ownership is part of the design.
For a future-facing IoT build, I like this split because it scales cleanly: the ESP32 handles connectivity, automations, and local logic, while the sensing layer stays honest about what it can and cannot detect. That separation is what keeps the system maintainable as the installation grows.
The practical path I would recommend in 2026
If I were building this today, I would start with mmWave for human occupancy, PIR only for basic motion triggers, BLE only when device tracking is a requirement, and direct sensors whenever the target is an object rather than a person. Espressif’s own documentation treats CSI as a real Wi-Fi capability, but I would still reserve it for advanced projects because it is more of a sensing platform than a plug-and-play occupancy feature.
- Use mmWave first when you want the best chance of accurate room presence.
- Use PIR first when cost and simplicity matter more than stillness detection.
- Use BLE first when the person’s phone or watch is part of the logic.
- Use direct object sensing first when the question is about a package, tool, container, or shelf.
My practical rule is this: if the system should behave like it understands a room, use mmWave; if it should behave like it understands a device, use BLE; if it should behave like it understands an object, measure the object. That is the shortest path to a stable, useful deployment, and it is usually the difference between a clever prototype and a system you can live with.
