Dashboard IoT en tiempo real: del sensor a la decisión

Un sensor que mide y nadie mira no sirve de nada. Entre la lectura cruda de un acelerómetro o una cámara y la decisión de “hay que ir a revisar esa presa” hay una cadena de ingeniería que casi nadie ve y que es donde se gana o se pierde el proyecto. Esa cadena es lo que recorre este artículo: cómo se construye un dashboard IoT en tiempo real que no solo pinta gráficas bonitas, sino que convierte el dato en una decisión a tiempo.

No es teoría. Es lo que llevo haciendo sobre infraestructura crítica —presas, túneles, puentes— en OFITECO y, antes, en proyectos de IoT agrícola del hardware a la nube. Voy a usar esos sistemas reales como ejemplo en cada paso.

El recorrido del dato: cuatro etapas, cuatro decisiones

Conviene pensar en la monitorización IoT como un pipeline con cuatro tramos, y entender que cada tramo impone una decisión de diseño que condiciona a los siguientes:

1. Ingesta — cómo llega el dato desde el campo.
2. Transporte y almacenamiento — cómo se mueve y dónde se queda.
3. Procesado y analítica — cómo pasa de número a información.
4. Visualización y alertas — cómo se convierte en una decisión.

La trampa habitual es empezar por la cuarta etapa (la gráfica) y descubrir tarde que la primera (la ingesta) no aguanta. Vamos en orden.

Ingesta: el campo manda, no el datacenter

La primera regla del IoT real es que las condiciones físicas mandan sobre la arquitectura ideal. No es lo mismo un sensor cableado con corriente y fibra que una cámara solar en mitad de un embalse sin cobertura.

En mi servicio de cámaras 4G autónomas la restricción lo definió todo: cámaras solares, con batería y SIM 4G, sin IP fija ni acometida eléctrica. Con esas restricciones, el patrón obvio —vídeo RTSP en streaming continuo— es inviable: agota la batería y el plan de datos en horas. La decisión de diseño fue invertir el modelo:

• Snapshots JPEG cada 10 minutos en lugar de vídeo, con la cámara durmiendo entre capturas. El ahorro de ancho de banda sobre 4G es de cerca del 90%.
• Control sin IP fija vía MQTT más un puente P2P sobre 4G: captura on-demand, PTZ, presets, batería en tiempo real y comandos remotos (sirena, reboot, wakeup) sin necesidad de exponer la cámara a internet.

Aquí aparece el primer protagonista recurrente: MQTT. Es el caballo de batalla de la ingesta IoT por una razón concreta: es un protocolo pub/sub ligero, pensado para redes inestables y dispositivos con poca energía. El dispositivo publica en un topic; el backend está suscrito; nadie necesita conocer la IP del otro. Para una flota de nodos que entran y salen de cobertura, ese desacoplamiento no es un lujo, es la única forma de que funcione.

MQTT, CoAP y cuándo usar cada uno

MQTT no es la única opción. En PlantsCare IoT, un sistema agrícola que construí de extremo a extremo —firmware de los nodos ESP32 incluido—, combiné MQTT y CoAP. La distinción práctica:

• MQTT va sobre TCP, mantiene una conexión persistente y brilla cuando quieres streaming de telemetría y entrega fiable con un broker central.
• CoAP va sobre UDP, sigue un modelo REST (GET/POST sobre recursos) y pesa aún menos. Encaja en interacciones puntuales tipo petición/respuesta y en los nodos más limitados.

La decisión no es ideológica: depende del consumo energético del nodo, de si necesitas push continuo o consultas esporádicas, y de cuánta fiabilidad de entrega exiges. Elegir mal aquí se paga en batería y en mensajes perdidos.

Transporte y almacenamiento: las series temporales no son una tabla más

Los datos de sensores tienen una forma muy específica: muchas escrituras, ordenadas por tiempo, que casi nunca se actualizan y que se consultan por rangos (“dame la última hora”, “compara esta campaña con la de marzo”). Meter eso en una tabla relacional genérica funciona hasta que no funciona.

Por eso en los sistemas de telemetría continua uso InfluxDB, una base de datos de series temporales. Lo hice tanto en PlantsCare como en el Visor BIM interactivo, donde las lecturas de sensores almacenadas en InfluxDB se representaban con ECharts junto al modelo 3D —el embrión del patrón “BIM más IoT en una sola vista” que luego escalé.

La decisión de fondo: una base de datos de series temporales te da downsampling, retención automática y agregaciones por ventana de tiempo casi gratis. Reinventar eso sobre PostgreSQL es posible, pero acabas escribiendo una base de datos de series temporales peor.

Un matiz que importa en infraestructura crítica: dónde vive el dato. En las cámaras 4G las fotos y los CSV de metadatos se guardan solo en el host del cliente mediante bind mounts, no en una nube de terceros. En entornos sensibles, la soberanía del dato es un requisito, no una preferencia.

Tiempo real de verdad: WebSocket frente a polling

“En tiempo real” se usa con mucha alegría. Técnicamente, hay una frontera clara: ¿el navegador pregunta periódicamente (polling) o el servidor empuja el dato cuando ocurre (push)?

Para un dashboard IoT en tiempo real de verdad, la respuesta es push. En xdata-bim, la plataforma de gemelo digital que desarrollo en solitario, la monitorización en vivo de los sensores va por WebSocket nativo sobre FastAPI. El servidor mantiene el canal abierto y emite cada nueva lectura; el frontend reacciona sin sondear. La diferencia frente al polling no es estética:

• Latencia menor: el dato llega cuando existe, no en el siguiente ciclo de sondeo.
• Menos carga inútil: no hay miles de peticiones que responden “nada nuevo”.
• Coherencia: todos los clientes conectados ven el mismo evento a la vez.

La regla práctica que aplico: WebSocket cuando la frescura del dato cambia una decisión (una alarma, un valor que cruza un umbral); polling o incluso carga bajo demanda cuando se trata de histórico que el usuario explora a su ritmo. No todo necesita ser tiempo real, y forzarlo encarece el sistema sin beneficio.

De número a información: la analítica es la mitad invisible

Un dashboard que muestra el valor crudo del sensor traslada al humano todo el trabajo de interpretación. El salto de calidad está en procesar antes de pintar.

En xdata-bim, sobre el flujo de sensores en vivo, corre una capa de analítica que convierte la telemetría en señales accionables:

• Detección de anomalías por Z-score móvil (ventana de 48 h): marca lo que se desvía de su propio comportamiento reciente, no de un umbral fijo y ciego.
• Bandas de Bollinger y tendencia por regresión lineal: para distinguir ruido de deriva real.
• Un índice de salud compuesto (0–100) que agrega muchas señales en un único número que la gestión entiende de un vistazo.

El caso extremo de “procesar antes de pintar” es Pulso, la plataforma de salud estructural. Ahí la entrada cruda son señales de 18 canales de acelerómetro a 100 Hz —datos que para un humano son ruido absoluto—. Lo que se muestra en pantalla es el resultado de encadenar siete pasos de análisis modal operacional (OMA): de las vibraciones se extraen las frecuencias propias de la estructura, y un paso específico separa el efecto del entorno (temperatura, tráfico) del daño estructural real. Esa separación es la que evita falsas alarmas. Sin ella, el dashboard avisaría cada vez que sube la temperatura, y un sistema que da falsas alarmas se acaba ignorando.

Visualización y alertas: el último metro es donde se decide

Llegamos a la etapa visible. Y aquí el error más común es confundir “muchos datos en pantalla” con “información útil”.

En el dashboard ejecutivo de monitorización que construí, las decisiones de diseño fueron deliberadamente al grano de “¿qué necesita decidir quien mira esto?”:

• KPIs derivados y reactivos al filtro: registros, sensores activos, alarmas, último evento. Cambias el filtro y los indicadores se recalculan, no son cifras estáticas.
• Filtros en cascada (cuenca → río → presa → estado): cada filtro acota a los siguientes, de modo que ir de la vista global al detalle es natural.
• Mapas Leaflet con modo foco a pantalla completa y mapa de calor, porque la infraestructura está distribuida en el territorio y la ubicación es información.
• Histórico en tabla avanzada con sparkline por fila y export CSV robusto (RFC 4180, con anti-inyección de fórmulas: un detalle de seguridad que casi nadie cuida).

Sobre las alertas, la lección que más me ha costado interiorizar: una alerta solo vale si alguien la atiende. Un detector que dispara constantemente entrena a los operarios a ignorarlo, y entonces es peor que no tener nada. Las técnicas que aplico para que la alerta signifique algo:

• Umbrales contextuales, no globales: lo que es anómalo para un sensor no lo es para otro.
• Persistencia temporal: confirmar el evento a lo largo de varias lecturas antes de darlo por bueno reduce el ruido de forma drástica. En las cámaras 4G esto se traduce en confirmar una intrusión en varios frames y aplicar zonas de exclusión por ray-casting para no reaccionar a lo que pasa por el fondo.
• Separar señal de entorno, como en Pulso, para no confundir un cambio ambiental con un problema real.

En monitorización IoT, gestionar bien los falsos positivos es tan importante como detectar de verdad. Una alarma que nadie cree no protege nada.

La decisión es el producto, no el dashboard

Si algo une todos estos proyectos es una idea: el entregable no es la gráfica, es la decisión que la gráfica permite tomar a tiempo. Por eso el diseño empieza por el final —qué tiene que decidir quien mira— y vuelve hacia atrás hasta la restricción física del sensor en el campo.

El stack concreto cambia según el caso (MQTT o CoAP, InfluxDB o un repositorio tras un puerto, WebSocket o carga bajo demanda), pero el criterio es estable: cada etapa del pipeline existe para que la siguiente reciba algo más cerca de la decisión, y ninguna restricción del campo se ignora porque incomode a la arquitectura.

¿Tienes sensores generando datos que nadie explota?

Si tienes instrumentación desplegada —cámaras, acelerómetros, nodos ambientales, lo que sea— y los datos se quedan en un CSV que nadie abre, ahí hay un sistema esperando a construirse: ingesta resiliente, tiempo real donde de verdad importa, analítica que separa señal de ruido y un panel del que salgan decisiones, no solo gráficas.

Es exactamente el tipo de problema que resuelvo de extremo a extremo, del sensor al dashboard. Si quieres una valoración honesta de qué es viable en tu caso, hablemos.