El navegador puede hacer que la telemetría parezca inmediata, pero un valor que cambia no siempre es actual ni confiable. Un buen panel muestra conexión, antigüedad de muestra, huecos de secuencia e identidad del dispositivo. Si también envía comandos, autorización y comportamiento seguro del firmware importan más que la animación del botón.
Para un prototipo local, el servidor HTTP de ESP-IDF puede ofrecer WebSockets; el ESP32 también puede actuar como cliente con el componente de Espressif. Elige una topología deliberadamente. Una página HTTPS normalmente requiere un endpoint WSS seguro; no mezcles página segura con socket inseguro. Un gateway o backend suele facilitar identidad, escalado y actualizaciones frente a exponer directamente el equipo a Internet.
Envía tipos como telemetry, status, ack y error, con versión de esquema, ID, secuencia y marca temporal. Incluye unidades e indicadores de calidad. Rechaza datos malformados, demasiado grandes o inesperados antes de mostrarlos. El navegador no debe confiar en HTML del dispositivo: renderiza como texto y valida rangos permitidos.
Limita frecuencia y tamaño. El panel rara vez necesita cada muestra de alta frecuencia; agrega en el borde/gateway y conserva el histórico duradero aparte. WebSocket es transporte en vivo, no una base de datos.
Separa el estado del socket del estado del dato. La conexión puede seguir abierta aunque el sensor dejó de reportar. Muestra antigüedad, última secuencia, intervalos faltantes y salud del equipo. En los gráficos, representa huecos en vez de unir datos ausentes. Al ocultar o volver a la pestaña, define si mantienes el socket o solicitas una instantánea actualizada.
Usa backoff exponencial con jitter y límite. Reinicia la demora solo tras una conexión estable, no después de un handshake breve. Evita temporizadores duplicados y limpia listeners al cerrar el panel. Al reconectar, solicita una instantánea y cursor; no simules la reproducción de eventos que el servidor no almacenó. Limita clientes y colas para que una pestaña lenta no consuma memoria sin control.
| Estado | Evidencia en pantalla | Comportamiento |
|---|---|---|
| Conectado y reciente | Socket abierto y muestra actual | Flujo normal |
| Conectado con dato antiguo | Socket abierto, edad excedida | Marcar telemetría degradada |
| Desconectado | Reconexión explícita | Backoff e instantánea al volver |
| Comando pendiente | Pendiente/aceptado/rechazado/caducado | Correlacionar ID y plazo |
La URL del socket o el encabezado Origin no autentican. Revisar Origin ayuda contra usos cross-site en navegadores, pero clientes no-browser pueden falsificarlo. Autentica usuario y sesión, autoriza cada equipo y comando, valida el contenido en backend y dispositivo, y registra quién lo solicitó. Exige caducidad e ID único para que una orden repetida o tardía no parezca nueva.
Para actuadores físicos, muestra el efecto previsto y estado actual, pide confirmación en acciones relevantes e informa si el firmware aceptó y completó. El evento de envío del navegador solo indica que los bytes llegaron a la pila del socket. Interbloqueos locales, valores seguros y parada manual siguen bajo responsabilidad del dispositivo.
Mide sesiones conectadas, tasa de mensajes, cola, errores de parseo, dispositivos obsoletos, reconexiones y latencia de ACK. Prueba suspensión del navegador, cambios Wi-Fi, reinicios, eventos duplicados, JSON inválido y un sensor detenido con socket abierto. Un panel fluido en el caso ideal pero engañoso en esos escenarios no sirve para operar.
WebSockets sirven para paneles ESP32 responsivos si el sistema define contrato, vigencia, reconexión limitada y autorización. Usa gateway cuando mejore identidad y gestión, conserva aparte el histórico y muestra datos obsoletos o desconectados. “En vivo” es un estado medido, no un efecto CSS.