MQTT y Modbus suelen responder a preguntas distintas en un sistema industrial. Modbus permite leer áreas de datos del dispositivo; MQTT distribuye los registros obtenidos por un recopilador. No tienen por qué ser alternativas: una pasarela puede conectarlos como capas distintas de un mismo flujo.
Asigna a cada protocolo su función
Un cliente Modbus solicita datos concretos y recibe la respuesta del dispositivo. Un publicador MQTT envía mensajes a un tema y el broker los distribuye a suscriptores. El puente suele hacer más que mover bytes: debe definir el significado del valor de campo.
Si un registro contiene 184, que represente 18,4 °C depende de la documentación del dispositivo. El recopilador aplica escala, unidades y calidad verificadas. Sin transformación documentada, distintos servicios pueden interpretar el mismo registro de forma diferente.
Responsabilidades por capa
| Pregunta | Dispositivo / Modbus | Mensajería / MQTT |
|---|---|---|
| ¿De dónde sale el valor? | Registro y mapa del equipo | Tema e identidad del publicador |
| ¿Cómo se conoce la unidad? | Definición del fabricante | Contrato del contenido del mensaje |
| ¿Qué sucede al desconectar? | Tiempo de espera y calidad de lectura | Sesión, almacenamiento temporal y reenvío |
| ¿Cómo se reconocen repeticiones? | Modelo de medición o evento | Identidad de evento en la aplicación |
Separar responsabilidades mejora también el diagnóstico. Que falte un mensaje del broker no demuestra un fallo del sensor Modbus. Examina por separado enlace serie, recopilador, conexión al broker y servicio de registros. Cada uno necesita un indicador significativo de su última operación correcta.
Flujo combinado ilustrativo
Un módulo de medición de cámara frigorífica se lee mediante Modbus RTU. La pasarela convierte el valor a la unidad acordada, añade identidad y tiempo de origen y publica por MQTT. La aplicación valida el registro y guarda el historial. El panel lo utiliza para presentar una tendencia.
La recopilación serie puede continuar mientras falla la red de subida. La pasarela conserva registros en un almacenamiento temporal limitado. Al reconectar mantienen sus marcas temporales e identificadores. El servidor los coloca en el historial, sin mostrarlos como mediciones nuevas; las entregas repetidas no crean otra observación.
Por qué no basta un conversor de protocolos
Una lectura Modbus fallida, un fallo de sensor informado por el equipo y un broker inaccesible son condiciones diferentes. Convertirlas todas en cero o en un nulo indiferenciado dificulta el diagnóstico. Conserva la categoría de calidad, la hora de la última medición válida y el estado de la fuente cuando estén disponibles.
Elegir QoS tampoco asegura una única escritura en la base de datos posterior. Aceptación del mensaje, procesamiento del registro y evaluación de alarmas son límites distintos. Las reglas de entrega MQTT de OASIS no deben confundirse con las transacciones y la eliminación de duplicados de la aplicación.
Valida las dos conexiones
El análisis debe establecer mapa de registros, señales que son eventos frente a observaciones periódicas, pérdida admisible, gestión de relojes y permisos de temas. Hay que conocer la capacidad finita de la pasarela y su comportamiento al llenarse. Más almacenamiento temporal no recrea mediciones que nunca se recopilaron.
Las pruebas deben interrumpir tanto dispositivo-pasarela como pasarela-servidor. Registra calidad esperada, orden de reenvío y tratamiento de duplicados. Prueba también un valor de dispositivo inválido y un mensaje mal formado. El resultado debe ser un flujo explicable con límites visibles, no dos protocolos que simplemente parecen conectados.
Escribe el contrato del puente antes de configurar temas
En el ejemplo frigorífico, vincula cada campo normalizado con su origen. La temperatura procede de una magnitud documentada; la unidad, de una conversión verificada; la identidad, del inventario de configuración. El tiempo puede proporcionarlo el dispositivo o asignarlo el recopilador al leer. Son evidencias distintas que no deben fusionarse en una marca ambigua etiquetada como «en directo».
La pasarela también necesita una regla para crear identidades de observación. Una lectura nueva puede originar otra observación aunque el número no cambie. Reenviar una observación anterior tras una desconexión debe conservar su identidad. De lo contrario, la aplicación no distinguirá de forma fiable entre temperatura constante y entrega duplicada. Documenta si los valores iguales se conservan, resumen o suprimen, porque afecta al historial y a las comprobaciones de vigencia.
Trata los cambios de mapeo como eventos con versión. Si un técnico corrige un factor de escala, los mensajes futuros y registros históricos deben seguir siendo interpretables. Aplicar silenciosamente el factor nuevo a una mezcla de valores brutos y ya normalizados puede corromper un informe. Define dónde se transforma el dato y si una corrección histórica crea una revisión o un recálculo documentado aparte.
Prueba de interrupción en ambos lados
Primero desconecta la fuente Modbus y mantén disponible el broker. El resultado esperado es un problema de origen en campo; que sigan llegando mensajes no demuestra una medición actual válida. Después restablece el campo e interrumpe solo el camino al broker. La recopilación puede continuar localmente si el equipo lo admite. Las observaciones históricas deben llegar después con su tiempo y calidad originales.
Por último, interrumpe una confirmación después de almacenar una observación. Comprueba que el reenvío no genera una segunda muestra ni una secuencia ilimitada de alarmas repetidas. Incluye un mensaje mal formado y un fallo de calidad en el mismo plan: ninguno debe acabar como cero inexplicable en la curva. Registra el resultado en pasarela, receptor y pantalla para que el futuro responsable pueda identificar el límite fallido.
El ejercicio demuestra que elegir protocolos es solo una parte de la integración. Una entrega útil incluye mapa del dispositivo, mensaje de ejemplo, reglas de identidad y calidad, permisos de temas y recuperación. Comparte esos elementos al estudiar el puente entre equipos existentes y una aplicación de supervisión, sin suponer que un conversor aporta por sí solo todo el modelo operativo.