Guía técnica · Capítulo 02 de 06
Cómo adquirir y normalizar datos industriales en ThingsBoard
¿Cómo llegan datos industriales a ThingsBoard sin perder contexto? Por conexión directa o gateway, con un contrato que defina identidad, unidad, timestamp, frecuencia, seguridad y recuperación.
Dos temperaturas, dos significados
Un sensor ambiental publica `temperature: 28.4` cada minuto. Un PLC expone otro valor llamado `Temp`, en décimas de grado, que sólo cambia cuando el proceso está activo. Ambos pueden terminar en una gráfica. Si se los incorpora sin normalización, uno se interpreta en grados y otro como 284; además, la ausencia del segundo durante una parada puede parecer una falla de comunicación.
La adquisición no consiste sólo en hacer llegar mensajes. Debe preservar significado.
Conexión directa: MQTT, HTTP y CoAP
La guía oficial de conectividad de ThingsBoard describe conexión directa por MQTT, HTTP y CoAP, entre otros protocolos. MQTT resulta habitual cuando el equipo mantiene una sesión, publica telemetría y puede recibir atributos o comandos. HTTP es útil para envíos periódicos o equipos que ya trabajan con solicitudes web. CoAP reduce sobrecarga en dispositivos restringidos y redes UDP; exige considerar que los mensajes no confirmables pueden enviarse sin acuse y que DTLS requiere configuración específica.
El soporte de un protocolo no define automáticamente la arquitectura. Hay que revisar:
- autenticación y cifrado disponibles en el dispositivo;
- dirección de la comunicación y necesidad de comandos;
- frecuencia, tamaño y prioridad de los mensajes;
- comportamiento ante reconexión;
- calidad de la red y exposición de puertos;
- capacidad para conservar el timestamp original.
Un medidor que envía un consolidado cada quince minutos no necesita el mismo tratamiento que un estado de máquina que cambia varias veces por segundo.
Gateway para fuentes industriales
ThingsBoard IoT Gateway es un puente de protocolos. Sus conectores pueden leer OPC UA, Modbus, BACnet, S7, CAN, BLE y otras fuentes, y mapear la información a dispositivos, atributos y telemetría de ThingsBoard. El conector OPC UA, por ejemplo, permite seleccionar nodos, trabajar por suscripción o sondeo y configurar autenticación y políticas de seguridad compatibles con el servidor.
El gateway no elimina la necesidad de diseñar el mapeo. Hay que decidir qué nodo representa cada activo, cómo se transforma el valor, qué nombre tendrá la clave y qué tasa de reporte se conserva. En OPC UA también se debe verificar el endpoint, la política de seguridad, certificados, permisos de lectura o escritura y comportamiento de las suscripciones.
La documentación distingue además las Platform Integrations, que conectan servicios o backends del lado servidor y han tenido diferencias de disponibilidad según edición y versión. Para una fuente dentro de la red OT, un gateway local suele ofrecer una frontera más explícita; la elección final depende de edición, conectividad y política de seguridad.
En el paquete real de monitoreo de vuelco de efluentes, un conjunto de sensores por planta converge en un tablero local de adquisición y control. El tablero también ofrece visualización local; una conexión celular lleva los datos y MQTT los publica hacia ThingsBoard. El antecedente muestra la función de cada tramo sin fijar las variables definidas para cada instalación ni la frecuencia de reporte.
Las funciones de medición del caso abarcan pH con temperatura y conductividad, oxígeno disuelto, turbidez, demanda química de oxígeno (DQO) y caudal/nivel. Son funciones, no una declaración sobre cantidad física de instrumentos. Cada clave necesita identidad, unidad, timestamp y estado de calidad propios; no corresponde mezclar un valor instantáneo de campo con un cálculo, una compensación o un dato vencido sin distinguirlos.
También importa distinguir el recorrido del valor. La lectura cruda es la señal recibida del instrumento; el valor escalado aplica rango y unidad; la variable de proceso puede incorporar compensación, validación o un cálculo. En una función hidráulica, por ejemplo, el caudal puede estimarse indirectamente desde nivel o altura mediante una curva o tabla de conversión. Si esa relación está mal parametrizada, el resultado puede parecer plausible y seguir siendo incorrecto. Por eso el diccionario de datos debe registrar origen, transformación, versión y calidad, no sólo el nombre que llega al dashboard.
La calibración agrega otro estado al dato. Una intervención puede quedar pendiente, aceptada o en error según estabilidad, patrón, secuencia y criterio configurados. Esos estados no deben confundirse con la calidad instantánea de la medición. Las pantallas de mantenimiento requieren acceso restringido, y una función sólo debería habilitarse cuando el instrumento correspondiente está físicamente conectado y en servicio. Algunas tareas exigen personal capacitado o asistencia especializada; una interfaz no reemplaza ese criterio.
La combinación responde al objetivo de monitoreo y debe validarse para cada vuelco, matriz, método y requerimiento aplicable. La puesta en marcha exige integrar señales, verificar montaje y calibración inicial, probar comunicación local y celular y confirmar que la publicación MQTT conserva identidad y tiempo. Eso no demuestra precisión, homologación, cumplimiento normativo ni validez ante una autoridad.
Qué ocurre cuando se corta el enlace
La documentación actual del Gateway describe almacenamiento local para guardar eventos antes de enviarlos. SQLite es la opción recomendada para la mayoría de los despliegues de producción; memoria no persiste ante reinicio y los backends tienen límites de capacidad y retención. Si se alcanza el máximo configurado, pueden descartarse datos nuevos.
Por eso “tiene buffer” no equivale a “no se pierde información”. Nodira debe dimensionar:
- volumen generado durante la desconexión máxima prevista;
- espacio local y política de rotación;
- tiempo de retención;
- orden y velocidad de reenvío al recuperar el enlace;
- impacto de datos tardíos sobre reglas y dashboards;
- alarmas técnicas del propio gateway.
También debe probarse el escenario: desconectar, generar datos, reiniciar cuando corresponda, reconectar y verificar cantidad, timestamps, duplicados y demora de recuperación.
Normalización antes de visualizar
Una convención útil incluye nombre estable, unidad explícita, tipo de dato, timestamp y estado de calidad. La plataforma almacena series temporales como pares clave-valor con marca de tiempo. Si el dispositivo no envía timestamp, el servidor puede asignarlo al recibir el mensaje; eso no siempre representa el momento de medición.
Para variables que alimentan alarmas o comparaciones, conviene documentar el origen temporal. También hay que separar valor cero, valor inválido y ausencia de actualización. Son condiciones distintas y pueden requerir respuestas distintas.
Durante la integración puede ser útil simular señales sin conectar el instrumento, siempre que el modo de prueba sea visible, tenga permisos acotados y no pueda confundirse con una medición real. La simulación permite verificar escalado, publicación, reglas y pantallas; la aceptación final exige repetir el recorrido con el instrumento en servicio.
El contrato que debe sobrevivir a una desconexión
ThingsBoard y su Gateway proporcionan conectores, almacenamiento y un modelo común. Nodira resuelve topología, credenciales, normalización y buffer, y verifica pérdida y recuperación. Operación confirma la frecuencia y calidad necesarias. El contrato debe seguir siendo válido después de una desconexión, no sólo durante la primera prueba.
Fuentes técnicas
Documentación oficial consultada.
Referencias utilizadas para verificar capacidades, límites y criterios técnicos desarrollados en este capítulo.
También podés consultar el centro de recursos técnicos de Nodira.
Evaluar una aplicación
Empecemos por un proceso y una decisión operativa concretos.
Contanos qué fuentes existen, cómo opera el proceso y qué debería ocurrir ante una desviación. Con ese contexto podemos definir un piloto proporcionado y verificable.
