MQTT es un protocolo de mensajería en el que los publicadores envían mensajes y los suscriptores reciben los de los temas pertinentes. Puede conectar un recopilador industrial con aplicaciones. No define cómo se mide un sensor, qué unidad usa un valor ni qué dispara una alarma: esas decisiones pertenecen al contrato de datos de la aplicación.
Broker y diseño de temas
Un broker distribuye los mensajes publicados a los suscriptores. Los publicadores no necesitan conocer directamente a cada receptor, pero el acceso, la capacidad, los permisos y la salud de la conexión del broker se convierten en responsabilidades operativas. Permitir que cualquier dispositivo publique en cualquier tema no es una opción predeterminada adecuada.
Los temas deben reflejar una jerarquía de equipos clara. site-a/line-2/machine-7/state es un nombre ilustrativo, no una dirección real. Separa identidad estable y nombre visible para que renombrar una máquina no fragmente su historial. Evita secretos y datos personales en los temas.
El contenido del mensaje puede incluir valor, unidad, hora de origen, calidad y versión del esquema. Documenta límites de tamaño y campos opcionales. Los consumidores deben interpretar el mismo mensaje de forma coherente, sin adivinar cada uno el significado del registro de origen.
Qué cubre realmente QoS
La norma OASIS MQTT 5.0 define tres niveles QoS. Su comportamiento de entrega corresponde al tramo de comunicación del protocolo pertinente. No garantizan automáticamente una sola escritura en base de datos ni una acción física realizada una única vez.
| Nivel | Entrega en el protocolo | Pregunta de la aplicación |
|---|---|---|
| QoS 0 | Como máximo una vez | ¿Puede perderse esta observación? |
| QoS 1 | Como mínimo una vez | ¿Cómo se reconocen registros repetidos? |
| QoS 2 | Exactamente una vez en el tramo del protocolo | ¿Qué sucede en los servicios posteriores? |
Un suscriptor puede procesar el mensaje y perder después la confirmación de su base de datos. Reintentar puede repetir la operación. Por eso importan identidades estables de evento, restricciones de unicidad y límites de transacción más allá de MQTT. QoS 2 no garantiza ilimitadamente operaciones empresariales únicas de extremo a extremo.
Retenido no significa actual
Un mensaje retenido puede proporcionar a un nuevo suscriptor el último mensaje almacenado de un tema. El valor puede ser antiguo. La interfaz debe comprobar la marca temporal y la política de vigencia. Recibir un mensaje justo al conectar no demuestra que el dispositivo esté funcionando ahora.
Last Will puede señalar una pérdida de conexión, pero no diagnostica todos los fallos de campo. Un recopilador conectado puede haber perdido acceso a un sensor. Mantén diferenciadas disponibilidad del dispositivo, salud del recopilador y conectividad de la aplicación.
Flujo ilustrativo de temperatura
Supongamos que el recopilador almacena lecturas con fecha mientras pierde la conexión de subida. Al reconectar, las envía con sus identidades de evento originales. La aplicación elimina duplicados, sitúa las mediciones tardías en el historial y evita que un punto antiguo reenviado sustituya la lectura actual.
La cola tiene capacidad finita. Define duración de interrupción cubierta, alarmas de almacenamiento y comportamiento ante fallos. Prueba muchas reconexiones simultáneas y limita el reenvío para mantener utilizables las mediciones actuales y las consultas de campo. Un retroceso acotado entre intentos evita empeorar la recuperación de la red.
Preguntas para el análisis inicial
- ¿Dónde funcionará el broker y quién lo operará?
- ¿Cómo se gestionan identidades y permisos de los temas?
- ¿Qué campos exige un mensaje válido?
- ¿Cómo se prueban almacenamiento temporal, reenvíos y duplicados?
- ¿Qué ocurre al renovar credenciales o certificados?
MQTT no sustituye un buen modelo de datos ni un plan operativo. Valida un flujo pequeño en funcionamiento normal, desconexión y entrega duplicada antes de ampliarlo.
Ejemplo de duplicación en la aplicación
Imagina una observación de temperatura con identificador observation-1042. La aplicación receptora la almacena, pero la confirmación de procesamiento no llega al recopilador. Este reintenta usando el mismo identificador y la hora original. El receptor puede reconocer el registro existente en vez de añadir otra muestra. Asignar un identificador nuevo al reintento eliminaría la evidencia de que las dos entregas pertenecen a una misma observación.
Otro consumidor puede evaluar una alarma a partir del registro. También debe considerarse su estado de procesamiento: impedir mediciones duplicadas no impide automáticamente notificaciones duplicadas. Guarda la relación entre evento de entrada, transición de alarma y tarea de notificación. Si el proveedor agota el tiempo de respuesta, conserva un resultado incierto en vez de afirmar que no se envió nada. Es un ejemplo de diseño de aplicación, no una promesa adicional del protocolo MQTT.
Define igualmente el tratamiento de mensajes rechazados. Una versión de esquema desconocida, una unidad inválida o una identidad de equipo imposible deben poder diagnosticarse. Reintentar sin límite un mensaje permanentemente mal formado consume recursos sin producir datos útiles. Ofrece un proceso de rechazo acotado y una vista operativa de la fuente afectada. No incluyas credenciales ni cuerpos de mensaje sin restricción en los registros de error para simplificar la depuración.
Verifica permisos y recuperación
Prueba cada identidad contra los temas donde puede publicar y suscribirse. Intenta acceder fuera de ese ámbito y verifica el rechazo. Prueba credenciales sustituidas y dispositivos retirados por separado de una reconexión normal. Estas comprobaciones demuestran si funcionan los límites previstos; una conexión correcta dice poco sobre sus restricciones.
Para probar la recuperación, interrumpe la subida mientras continúa la recopilación y reconecta con observaciones históricas y actuales. Comprueba marcas temporales originales, identidades y antigüedad mostrada. Inspecciona qué sucede si el almacenamiento local alcanza su límite. La condición de lleno debe seguir siendo visible aunque el broker vuelva a estar disponible. Documenta versión MQTT, comportamiento de sesión y reglas de confirmación de la aplicación junto a la configuración real de cliente y broker. Lleva ese registro operativo, un mensaje de ejemplo y la jerarquía propuesta de temas a la revisión de integración: permiten valorar los límites de fiabilidad sin afirmar que una selección QoS resuelve todos los problemas de entrega.