Guías de ThinkLink / Operación en campo
Validar recuperación MQTT en ThinkLink: suscripción, huecos y duplicados
Además de configurar conexiones, pruebe suscripciones, disponibilidad del destino y resultados reales del consumidor tras interrupciones.
Conexión, confirmación de suscripción, recepción y almacenamiento son resultados separados. Las mejoras de reconexión no añaden garantía de búfer sin conexión, reposición ni procesamiento exactamente una vez.
Dibujar la ruta completa
Enumere Broker origen, tema, transformación, Broker destino y consumidor final. AS aporta mensajes de subida originales y ThinkLink mensajes procesados; sus cantidades no son directamente comparables. Defina temas, campos y responsable de almacenamiento. Use un equipo o tema de prueba con identificadores de negocio rastreables. Igual cantidad no demuestra ausencia de pérdidas o duplicados, y varios equipos enviando en el mismo segundo no constituyen necesariamente un único evento.
Confirmar conexión y suscripción
RUNNING indica conexión, no suscripción confirmada ni consumo. La documentación distingue registro de suscripción y SUBACK; si el origen está desconectado, la confirmación espera su recuperación. Compruebe habilitación, tema y confirmación y envíe una muestra conocida. Un destino conectado no demuestra que el script devolvió un mensaje. Inspeccione una muestra mínima autorizada antes y después de transformar, sin exportar datos ajenos de la organización para depurar.
Explicar el contrato durante la caída
La documentación no añade garantía de almacenamiento temporal o reposición cuando el destino falla. Recibir mensajes nuevos no rellena el intervalo perdido. Para continuidad histórica se necesita fuente consultable, compensación y deduplicación, verificando periodos y campos. client_id fijo no garantiza restaurar sesiones ni fiabilidad; identificadores repetidos pueden sustituir conexiones. Cambiarlo reconecta, por lo que debe registrarse y probarse en una ventana adecuada. Reconexión automática no significa datos sin pérdidas.
Probar tres interrupciones
Establezca una base y detenga por separado origen, destino y consumidor. Tras cada recuperación, compare conexión, suscripción, mensajes y registros de negocio y enumere identificadores ausentes o repetidos. Evitar oyentes duplicados no elimina reentregas MQTT ni reintentos del emisor. Defina deduplicación mediante identidad de dispositivo e identificadores o secuencias adecuados; filtrar solo por hora puede descartar datos legítimos del mismo segundo. Declare capas recuperadas, huecos pendientes y partes no observables.
- Crear muestras base rastreables.
- Interrumpir origen, destino y consumidor por separado.
- Comprobar SUBACK, mensajes y registros.
- Asignar tratamiento de huecos y duplicados.
Entregar un procedimiento al consumidor
Documente temas, contrato de campos, responsables, muestras, reconexión, huecos y duplicados. Los atributos pueden ser subconjuntos que requieren combinación por campo. Los eventos de estado no contienen telemetría ordinaria y pueden perderse con filtros exclusivos de telemetry_data. Revise filtros y lógica destino al añadir tipos. La aceptación termina en el consumidor de negocio, no en la luz de conexión. Reposición histórica, orden de eventos y auditoría fiable necesitan diseño y validación propios.
Preguntas frecuentes
¿RUNNING significa que el negocio recibió los datos?
No. Verifique suscripción, transformación, recepción y procesamiento.
¿client_id fijo garantiza reponer la caída?
No. Valide sesión, Broker y recuperación de negocio por separado.
Referencias y lecturas adicionales
Esta guía se basa en las fuentes oficiales siguientes. Los diagramas explican el método; consulte la documentación de su versión para menús, campos y funciones exactos. Las fuentes enlazadas están en chino.