Building an occupancy sensor with a $5 ESP32 and a serverless DB

Original Article ↗ Hacker News Discussion ↗

A student-built occupancy sensor using a $5 ESP32 microcontroller and Bluetooth Low Energy beacons prompts wide-ranging reflections on DIY hardware reliability, power design, and packaging projects beyond bare dev boards. Commenters compare ESP32 variants, power supplies, and deep-sleep strategies, suggest alternatives like LoRa, mmWave, cameras, or existing frameworks such as ESPHome and Home Assistant, and debate when custom PCBs or ASICs make sense. Many raise privacy and ethics concerns around tracking phones via BLE—especially in public spaces or for commercial use—highlighting MAC randomization, fingerprinting research, and the lack of clear rules for passive device sensing.

Hardware reliability & power

  • Several reports that ESP32 and Raspberry Pi boards can be very reliable for months if powered well.
  • Many suspect instability comes from power noise, not insufficient amperage: WiFi/BLE current spikes can cause brief voltage drops.
  • Recommendations: add large low-ESR capacitors on 3.3V rails, use short/high‑quality or official power supplies and USB cables, and avoid cheap no‑name boards.
  • Some mention SD card failures on Pis; mitigations include Alpine Linux with tmpfs/explicit commits or read‑only roots.

BLE presence detection behavior

  • Devices can stay “alive” but drop off WiFi; adding visible status indicators and aggressive reconnection or full reboots is suggested.
  • Busy RF environments with many networks may increase chance of WiFi/BLE stack getting stuck.
  • Apple devices often hide from scans unless certain settings are open; this reduces BLE-based crowd-sensing coverage.

Privacy, ethics & tracking

  • Discussion of MAC address randomization and its limits. It complicates linking beacons to individuals but not impossible, especially with RF fingerprinting and app‑based beacon tracking.
  • Some note an existing “wild west” industry of Bluetooth/location tracking SDKs and law‑enforcement use of such data.
  • For university projects, people suggest consulting human‑subjects/IRB processes and campus privacy policies.
  • Individual behavior varies: some keep Bluetooth always on for wearables, others turn it off for privacy and battery.

Algorithms & software stack

  • Suggestions to use fixed-size cardinality estimators for counting unique devices instead of storing all IDs.
  • Others propose TTL-based maps (refresh on sighting, purge expired entries) and avoiding dynamic allocation on microcontrollers.
  • Rust on ESP32 has improved support (especially RISC‑V C3), but cross‑compiling with BlueZ/DBus on Linux can be painful; Python/Home Assistant or simple shell scripts on Pis are cited as easier.
  • ESPHome, Home Assistant, and MicroPython can eliminate most custom firmware for many use cases.

Alternative sensing approaches & applications

  • Other sensing ideas: cameras, mmWave/UWB radar, 24 GHz radar, microphones, WiFi RSSI, bicycle rear radar for traffic, TPMS for campus occupancy, and vehicle/venue crowd analytics.
  • Commercial BLE‑based occupancy products exist; they report that beacon counts correlate with occupancy but require venue‑specific calibration, and randomized MACs make dwell-time estimates unreliable.

Productization & enclosures

  • Many options for “finished” devices: project boxes, generic enclosures, M5Stack/ESP-based boxed modules, off‑the‑shelf sensors, 3D‑printed or laser‑cut cases.
  • Debate over using ESP32 modules vs ultra‑cheap MCUs or even custom ASICs; most agree that for low–medium volume, ESP32 modules are practical and widely used in commercial IoT.