Respuesta breve
Un gateway MQTT necesita una decisión explícita sobre qué conservar durante una desconexión. Historial de medidas, estado actual y órdenes tienen necesidades diferentes. Recuperar la conexión no demuestra que la aplicación haya retomado correctamente su trabajo.
Clasifique los mensajes por su significado
Decida por tipo si basta el último estado o si se necesita el historial completo. Establezca cuándo caduca la información. Una medida antigua puede servir para una serie histórica y resultar inadecuada para mostrar el estado actual.
Asigne identificadores al equipo y al evento. Aclare si la marca temporal corresponde a la medida o al envío. Si el reloj no es fiable tras reiniciar, esa incertidumbre debe quedar visible y no convertirse en una fecha aparentemente válida.
Separe protocolo y almacenamiento de aplicación
MQTT 5 distingue la caducidad de la sesión y la del mensaje. Esas opciones no crean automáticamente un almacenamiento local persistente para la aplicación. OASIS — MQTT Version 5.0
Describa por separado qué guardan dispositivo, biblioteca, broker y receptor. Revise la implementación y su configuración real. Un valor predeterminado sin documentar no constituye una garantía de comportamiento después de reiniciar el dispositivo o actualizar una biblioteca.
Calcule capacidad y política de desbordamiento
Una estimación inicial es tasa de mensajes × tiempo máximo desconectado × bytes almacenados por registro. Añada metadatos y reserva. Dos registros por segundo durante una hora representan 7.200 registros; el volumen final depende del formato de cada uno.
Defina qué ocurre al llenarse: sustituir datos antiguos, descartar ciertos mensajes o notificar un fallo. Limite el reenvío para atender nuevas medidas y funciones de control. En almacenamiento persistente, considere también la frecuencia prevista de escrituras.
Compruebe el efecto de extremo a extremo
El receptor debe reconocer mediante la identificación de aplicación los eventos ya procesados. Un mensaje repetido no debe ejecutar accidentalmente otra vez una orden. Para las órdenes defina además validez y confirmación del resultado.
Ensaye por separado corte de red, reinicio del broker y reinicio del dispositivo. Al volver, revise cantidad, orden, antigüedad y procesamiento duplicado. El criterio de éxito es el efecto esperado en la aplicación, no únicamente un indicador de conexión encendido.
Decisiones para el funcionamiento sin red
- Separar historial, estado y órdenes.
- Definir antigüedad admisible y duración del corte.
- Calcular búfer y comportamiento al llenarse.
- Establecer identificadores y tratamiento de duplicados.
- Probar fallos de red, broker y dispositivo por separado.
Preguntas frecuentes
¿Un QoS mayor garantiza una única operación de negocio?
No por sí solo. La aplicación debe definir cómo se relacionan recepción, almacenamiento y procesamiento, y cómo reconoce los eventos repetidos.
¿Debe guardarse permanentemente cada medida?
Solo si lo exige el uso. Para algunos indicadores basta el último estado, mientras que un historial puede necesitar conocer las pérdidas. La decisión debe figurar en los requisitos.
Fuentes técnicas
Servicio relacionado