Construyendo un sensor de ocupación con un ESP32 de 5 $ y una base de datos sin servidor

Artículo original ↗ Discusión en Hacker News ↗

Un sensor de ocupación construido por un estudiante con un microcontrolador ESP32 de 5 $ y balizas Bluetooth Low Energy provoca reflexiones de amplio alcance sobre la fiabilidad del hardware DIY, el diseño de la alimentación y el empaquetado de proyectos más allá de las placas de desarrollo desnudas. Los comentaristas comparan variantes de ESP32, fuentes de alimentación y estrategias de sueño profundo, sugieren alternativas como LoRa, mmWave, cámaras o marcos existentes como ESPHome y Home Assistant, y debaten cuándo tienen sentido las PCB personalizadas o los ASIC. Muchos plantean preocupaciones de privacidad y ética sobre rastrear teléfonos mediante BLE —especialmente en espacios públicos o para uso comercial—, destacando la aleatorización de MAC, la investigación de fingerprinting y la falta de reglas claras para el sensado pasivo de dispositivos.

Fiabilidad del hardware y alimentación

  • Varios informes indican que las placas ESP32 y Raspberry Pi pueden ser muy fiables durante meses si se alimentan bien.
  • Muchos sospechan que la inestabilidad proviene del ruido de alimentación, no de una amperaje insuficiente: los picos de corriente de WiFi/BLE pueden causar caídas breves de voltaje.
  • Recomendaciones: añadir grandes condensadores de baja ESR en los raíles de 3.3V, usar fuentes de alimentación y cables USB cortos/de alta calidad o los oficiales, y evitar placas baratas sin marca.
  • Algunos mencionan fallos de tarjetas SD en las Pis; entre las mitigaciones se incluyen Alpine Linux con tmpfs/commits explícitos o sistemas de raíz de solo lectura.

Comportamiento de la detección de presencia por BLE

  • Los dispositivos pueden seguir “vivos” pero perder la conexión WiFi; se sugiere añadir indicadores de estado visibles y una reconexión agresiva o reinicios completos.
  • Los entornos de radiofrecuencia muy cargados, con muchas redes, pueden aumentar la probabilidad de que la pila WiFi/BLE se quede atascada.
  • Los dispositivos Apple suelen ocultarse de los escaneos salvo que ciertas configuraciones estén abiertas; esto reduce la cobertura del sensado de multitudes basado en BLE.

Privacidad, ética y rastreo

  • Debate sobre la aleatorización de direcciones MAC y sus límites. Complica vincular balizas a individuos, pero no lo hace imposible, especialmente con fingerprinting de RF y rastreo de balizas basado en aplicaciones.
  • Algunos señalan una industria ya existente, un “salvaje oeste”, de SDKs de rastreo Bluetooth/de ubicación y el uso de esos datos por parte de las fuerzas del orden.
  • Para proyectos universitarios, la gente sugiere consultar los procesos de sujetos humanos/IRB y las políticas de privacidad del campus.
  • El comportamiento individual varía: algunos mantienen Bluetooth siempre activado por los wearables, otros lo desactivan por privacidad y batería.

Algoritmos y pila de software

  • Se sugieren estimadores de cardinalidad de tamaño fijo para contar dispositivos únicos en lugar de almacenar todos los IDs.
  • Otros proponen mapas basados en TTL (refrescar al detectar, purgar entradas caducadas) y evitar la asignación dinámica en microcontroladores.
  • El soporte de Rust en ESP32 ha mejorado (especialmente en el RISC-V C3), pero la compilación cruzada con BlueZ/DBus en Linux puede ser dolorosa; se citan Python/Home Assistant o scripts de shell simples en Pis como opciones más fáciles.
  • ESPHome, Home Assistant y MicroPython pueden eliminar la mayor parte del firmware personalizado en muchos casos de uso.

Enfoques y aplicaciones de sensado alternativas

  • Otras ideas de sensado: cámaras, radar mmWave/UWB, radar de 24 GHz, micrófonos, RSSI de WiFi, radar trasero de bicicleta para tráfico, TPMS para ocupación de campus y análisis de multitudes en vehículos/recintos.
  • Existen productos comerciales de ocupación basados en BLE; informan que los recuentos de balizas se correlacionan con la ocupación, pero requieren calibración específica del recinto, y las MAC aleatorizadas hacen poco fiables las estimaciones del tiempo de permanencia.

Producto final y carcasas

  • Hay muchas opciones para dispositivos “terminados”: cajas de proyecto, carcasas genéricas, módulos en caja basados en M5Stack/ESP, sensores comerciales, carcasas impresas en 3D o cortadas con láser.
  • Se debate entre usar módulos ESP32 frente a MCU ultrabaratos o incluso ASICs personalizados; la mayoría coincide en que, para volúmenes bajos o medios, los módulos ESP32 son prácticos y muy usados en IoT comercial.