Inglés
Chino
Ruso
Portugués
Francés
Alemán
Indonesio
Tailandés
Vietnamita
Árabe
Italiano
Turco
Polaco
Japonés
Los fallos de conexión de una pasarela MQTT deben investigarse en la primera etapa que falla: resolución del destino, conexión de red, TLS cuando se requiera, aceptación del bróker o permiso de mensajes. Cambiar un tema no repara una negociación TLS fallida. Conserve el error del cliente y el registro correspondiente del bróker para que la siguiente prueba examine la etapa correcta.
Confirme qué ejecuta la pasarela instalada
La pasarela METRAVON TG451 incluye MQTT entre sus funciones de software, pero aún deben confirmarse el modo de firmware requerido y el diseño de mensajes de plataforma. Registre versión de firmware, versión MQTT, transporte, nombre de host del bróker, puerto de servicio e identidad asignada a esta instalación.
Compruebe la especificación real del servicio para TCP sin cifrar, TLS u otro transporte compatible. No deduzca el puerto correcto de un valor predeterminado recordado. Confirme que el destino configurado es el extremo del bróker, no una dirección de consola web ni una ruta de equilibrador destinada a otro servicio.
Localice los fallos de conexión MQTT en los registros
| Resultado | Etapa probable | Evidencia útil |
|---|---|---|
| Falla la resolución | La resolución del destino no ha producido una dirección utilizable. | Registre nombre de host, resultado de resolución y trayecto de red activo sin cambiar credenciales. |
| Sin acceso al puerto | La conexión al servicio solicitado no está establecida. | Compare el intento con los registros del servicio de escucha del servidor y del cortafuegos. |
| Falla TLS | La sesión segura no se ha establecido. | Conserve el error de negociación y verifique hora, nombre de host y certificados requeridos. |
| El bróker rechaza | El servidor ha devuelto un resultado de conexión MQTT. | Interprete el resultado según la versión de protocolo negociada y el registro del bróker. |
| Sin datos útiles | La aceptación de conexión no ha producido el resultado de aplicación esperado. | Inspeccione permisos de temas, tratamiento de carga útil y registro de datos aceptados de la plataforma. |
Corrija la confianza y la identidad sin omitir sus comprobaciones
Para TLS, confirme reloj de la pasarela, validez del certificado y nombre de host. Una autoridad de certificación privada requiere la configuración de confianza adecuada. Cuando se exija TLS mutuo, establezca que el certificado de cliente y la clave privada corresponden entre sí y al dispositivo previsto.
No suba claves privadas a solicitudes de soporte ni desactive la verificación de certificados para hacer desaparecer el error. Pida al responsable del servicio la cadena de confianza prevista y los ajustes de conexión compatibles, y aplíquelos mediante el proceso de configuración autorizado.
La identidad de cliente MQTT y los permisos de publicación son asuntos separados. Un bróker puede aceptar una conexión y rechazar una operación no autorizada. Compruebe el tema exacto, las mayúsculas y minúsculas y la política de la cuenta. Con MQTT 3.1.1, cuando un bróker acepta una conexión nueva con un identificador de cliente ya conectado, desconecta al cliente existente. Por tanto, dos pasarelas con ese identificador pueden desplazarse repetidamente al reconectarse. Compare identificadores de cliente y horas de conexión del bróker antes de cambiar antenas o ajustes de mantenimiento de conexión.
Separe una publicación correcta de una medición correcta
El bróker transporta una carga útil; no valida por sí mismo el significado técnico del valor de un sensor. Compare un mensaje capturado con el esquema acordado y una lectura de origen comprobada. Verifique unidades, escalado, identidad de fuente y hora de adquisición antes de diagnosticar la ausencia de una tendencia como un problema de conectividad.
Un PUBACK de QoS 1 confirma que el receptor MQTT ha aceptado la responsabilidad del mensaje, no que la base de datos final haya almacenado la medición. QoS 1 puede entregar duplicados; QoS 2 evita entregas duplicadas dentro de su intercambio de protocolo, pero no certifica el procesamiento posterior de la base de datos. Compruebe los QoS compatibles con el firmware instalado y el servicio receptor, y defina cómo identifica y concilia la aplicación los registros repetidos. Un mensaje retenido no es un archivo de series temporales, y la existencia de una sesión no demuestra que todas las mediciones anteriores sigan disponibles.
Para sesiones inestables, compare la configuración de mantenimiento de conexión, las interrupciones de red y los motivos de cierre del servidor. Defina reintentos y mantenimiento de conexión según los requisitos del servicio y las condiciones observadas. Los bucles de reintento agresivos pueden ocultar el error original y sobrecargar el destino.
Utilice un cliente de prueba aislado solo para responder una pregunta concreta
Un cliente de prueba aprobado en la misma red puede ayudar a distinguir accesibilidad del servicio de un problema de configuración de pasarela. Asígnele una identidad distinta y un tema de prueba permitido. No duplique la identidad de un dispositivo activo ni publique valores de prueba en mediciones de producción.
Conserve un registro del destino, transporte y clase de credenciales probados. Una conexión satisfactoria desde un portátil por otra red es evidencia útil, pero no verifica ruta, reloj ni almacén de confianza de la pasarela.
Preguntas de integración MQTT
P1. ¿Deben cambiarse los temas cuando el bróker nunca acepta la sesión?
Resuelva primero la etapa de conexión fallida. El mapeo normal de temas de telemetría es relevante después de la aceptación, aunque las funciones asociadas a conexión pueden tener sus propios requisitos de política. Utilice el resultado real de rechazo del bróker en lugar de cambiar campos no relacionados.
P2. ¿La autenticación satisfactoria demuestra permiso para publicar?
No. Confirme las operaciones autorizadas y las rutas exactas de temas para la cuenta. Después compruebe la carga útil aceptada por la aplicación posterior; permiso de transporte y validación de aplicación son distintos.
P3. ¿Qué debe incluir una solicitud de soporte MQTT?
Envíe modelo y firmware, versión de protocolo, transporte, destino, hora del error y resultados del cliente y bróker sin información sensible. Incluya un tema y una carga útil de ejemplo sin datos sensibles si la sesión funciona pero los datos fallan. Excluya contraseñas, tokens y claves privadas.
Resumen
Diagnostique la etapa de conexión que falla y después verifique por separado permisos de mensajes y datos técnicos. Solicite una revisión de configuración MQTT a METRAVON con el error registrado y la especificación del servicio, no solo una captura que indique desconexión.
