ESP-NOW vs WiFi en venues con mala conectividad
Notas técnicas sobre por qué elegimos ESP-NOW para la comunicación entre badges, y los compromisos prácticos que eso implica.
Por Equipo HoldPixel
Este post es para CTOs, heads of engineering o personas curiosas que quieran entender por qué un sistema de badges electrónicos para eventos no usa WiFi convencional. La pregunta es razonable y la respuesta tiene matices.
Por qué el WiFi de venues falla, casi siempre
Llegas a un hotel decente con sala de convenciones para 600 personas. Te dicen que hay WiFi. Tú te lo crees. El día del evento, el WiFi no funciona. Esto pasa con una regularidad casi religiosa, y las razones son técnicas:
- Saturación de 2.4 GHz. La mayoría de venues siguen apoyándose en 2.4 GHz porque tiene mejor cobertura. Pero cualquier sala con 200+ móviles tiene tantas redes WiFi como personas (móvil + portátil + smartwatch + auriculares), todas saltando entre los tres canales no solapados. El ruido sube hasta que ningún paquete pasa.
- Captive portals. El WiFi del hotel está detrás de una página de “acepta los términos”. Los dispositivos IoT no saben pulsar “acepto”. Como mucho, abres un navegador en cada badge a mano. Inviable a 250 unidades.
- APs de hotel. Los puntos de acceso suelen ser modelos consumer rebrandeados, con timeouts agresivos de sesión, sin QoS, sin separación de SSIDs. Una sala llena los tumba en 20 minutos.
- NAT y firewall opaco. Tu backend está en Internet. El badge necesita salir. El hotel, por seguridad razonable, bloquea puertos arbitrarios. Tu protocolo MQTT custom se queda fuera.
- Ancho de banda compartido con asistentes. Si los 500 invitados están en Zoom o Teams paralelos durante las pausas, tus badges compiten por bytes con los humanos. Los humanos ganan.
Resumen: confiar en el WiFi del venue para una experiencia coordinada y en tiempo real es planificar el fallo. Lo hemos visto suficientes veces como para no negociarlo.
Qué es ESP-NOW
ESP-NOW es un protocolo de capa MAC propietario de Espressif, diseñado para comunicación directa entre dispositivos ESP sin necesidad de un AP WiFi. Algunas características relevantes:
- Peer-to-peer. Cada nodo habla con cada nodo, hasta 20 peers registrados por dispositivo (limitación práctica, no protocolar — con técnicas como broadcast llegas a miles).
- Sin asociación WiFi. No hay handshake de 4-way, no hay DHCP, no hay roaming. Un paquete sale en milisegundos.
- Frame de 250 bytes de payload útil. Suficiente para mensajes de control y deltas de UI; insuficiente para imágenes — los assets pesados se distribuyen por chunks o por OTA fuera del evento.
- Latencia ~50 ms end-to-end en condiciones normales. Bajo carga sube a 100-200 ms, pero rara vez se rompe.
- Comparte radio con WiFi. El ESP32 solo tiene una radio: ESP-NOW y WiFi coexisten en time-slicing si necesitas ambos. En el evento solo usamos ESP-NOW; el WiFi se mantiene apagado para ahorrar batería.
- Cifrado nativo opcional con AES-128 (CCMP) por peer.
Es un protocolo pensado por Espressif para precisamente este caso: muchos dispositivos en un espacio físico que tienen que coordinarse sin infraestructura.
Tradeoffs reales
ESP-NOW no es magia. Tiene limitaciones que hay que asumir:
- Rango ~30 m indoor con pared de pladur en medio. Más en línea de vista, menos con muros de hormigón. Para venues grandes hay que distribuir balizas-repeater.
- Sin Internet directo. Si quieres backend cloud (admin remoto, analytics, estado de pedidos), necesitas un gateway: un dispositivo con ESP-NOW + WiFi/Ethernet que haga de puente. Nosotros lo solucionamos con balizas conectadas al panel cloud.
- No es estándar. Solo lo entienden chips Espressif. Si querías reaprovechar el badge en infraestructura genérica IoT, ESP-NOW te ata. Mitigación: en nuestra arquitectura, el badge habla BLE estándar también, así que un futuro pivot a BLE Mesh es viable.
- Throughput limitado. No es una buena idea hacer streaming. Para una OTA de firmware de 1 MB hablamos de minutos, no segundos. Lo hacemos cuando el badge está en cargador, no en sala.
Cuándo elegir cada uno
La heurística práctica:
- Coordinación en tiempo real entre muchos dispositivos en un espacio físico → ESP-NOW.
- Acceso a Internet, OTA pesada, sincronización con backend → WiFi (cuando hay) o BLE→móvil→Internet.
- Eventos al aire libre con cobertura móvil decente → considera 4G/LTE Cat-M; aún más caro pero independiente del venue.
En la práctica, una arquitectura híbrida es lo correcto: ESP-NOW para la coordinación en sala, WiFi en las balizas para sincronizar con cloud cuando hay red, y todo lo crítico almacenado localmente para que la experiencia sobreviva a desconexiones.
Caso real: 250 badges, venue de 1.000 m², sin tocar el WiFi del cliente
Pilotamos esta configuración en un evento corporativo a principios de 2026. 250 badges activos, sala de 1.000 m² en planta baja de hotel, paredes interiores. Desplegamos:
- 5 balizas ESP-NOW repartidas en perímetro y centro de sala, cada una con alimentación por enchufe.
- 1 gateway (una baliza con WiFi adicional) en la cabina de control técnico, conectada al WiFi staff del hotel —no al WiFi de invitados— solo para subir analytics al panel.
- Frecuencia de heartbeat badge→baliza: 30 segundos en idle, 2 segundos durante juegos masivos.
- Broadcast de juego desde el panel: pulsa “lanzar Arkanoid” → todas las balizas reciben la orden por WiFi en <500 ms → reenvían por ESP-NOW al fleet → 240 de 250 badges entran en el juego en menos de 1 segundo. Los 10 restantes en 2-3 segundos.
El WiFi de invitados del hotel se cayó dos veces durante el día. El evento no se enteró: los badges seguían operando, las balizas tenían cola local, y el panel reanudó la sync cuando el WiFi volvió. Esa es la propiedad importante: degradación elegante.
La conclusión
ESP-NOW no es la respuesta a todo. Es la respuesta correcta cuando quieres coordinar muchos dispositivos en un espacio físico controlado y no quieres depender de infraestructura que no es tuya. En eventos corporativos, eso describe el 95% de los casos.
Si vienes de un fondo de IoT industrial o de cloud, el protocolo se siente primitivo. Pero precisamente esa primitividad —sin handshake, sin DHCP, sin TLS, sin nada— es lo que lo hace fiable cuando todo lo demás falla. Y en un evento, todo lo demás falla con frecuencia incómoda.