Router industrial en línea, ¿MQTT no publica? Revise la tarea
Supongamos que, en una estación de bombeo, el router industrial local adquiere datos de presión y nivel de agua y ejecuta una tarea de publicación MQTT. Envía las lecturas a un broker remoto; una plataforma las obtiene mediante una suscripción. Tras un periodo de funcionamiento continuo, los valores de la plataforma dejan de actualizarse. Sin embargo, el router sigue mostrando conexión 4G/5G y responde a un ping externo.
En esta configuración, el router es el cliente que publica, no el broker. Un cliente MQTT puede publicar, suscribirse o hacer ambas cosas. Conectarse a un broker no significa que sea solo receptor. Véanse las definiciones de MQTT 3.1.1, §1.2.
La primera pregunta es si la tarea local sigue avanzando o si intenta enviar y falla durante la conexión o la publicación. Tener acceso a la red solo confirma una parte del trayecto; no responde a esa pregunta.
Este procedimiento se aplica a equipos que realmente admiten adquisición y publicación MQTT locales y están configurados de ese modo. Confirme primero la topología. Si el router únicamente transporta el tráfico de una pasarela independiente, revise la tarea de publicación en esa pasarela. Si actúa como broker o suscriptor, examine el servicio correspondiente. Para conocer las funciones y la ruta de datos, consulte la introducción a MQTT de Wavetel.
Seguir una muestra nueva para localizar el tramo afectado
Elija una medida que pueda identificar con facilidad. Anote la hora, el identificador y el tema MQTT de una muestra nueva. Busque pruebas en tres puntos:
Se genera una muestra nueva → la tarea local inicia un intento de publicación → el mismo mensaje nuevo aparece en el tema de destino del broker remoto.
Prueba observada | Qué comprobar después |
|---|---|
Hay una muestra nueva, pero no se observa un intento posterior de publicación | La entrega de los datos desde la adquisición y la tarea local de publicación |
La tarea sigue intentándolo, pero los registros indican un fallo de conexión o publicación | La conexión real del cliente MQTT al broker remoto, la autenticación y el resultado del envío |
El mismo mensaje nuevo aparece en el tema de destino del broker | La suscripción y el procesamiento de la plataforma |
Si ni siquiera se genera una muestra nueva, vuelva a la fuente de datos y a la tarea de adquisición. Si no hay registro visible de un intento, no concluya inmediatamente que la tarea se ha detenido: utilice los diagnósticos disponibles en el equipo para confirmar si ese paso ocurrió.
Antes de modificar nada, conserve los registros anteriores y posteriores al fallo, el tiempo de ejecución del cliente, la dirección y el puerto del broker, el ID de cliente y el tema. Anote cualquier desfase entre los relojes del equipo y del broker para correlacionar el mismo intento.
Hay muestras nuevas, pero no intentos de publicación: revisar la tarea local
Compruebe primero si el servicio de publicación sigue en ejecución. Si el proceso terminó, registre la hora, el error y los reinicios, y restablezca el servicio mediante el procedimiento de mantenimiento admitido. Cambiar parámetros de conexión MQTT no reactivará un servicio que ya no se está ejecutando.
Si el proceso continúa activo, determine hasta dónde llegó: ¿recibió la tarea la muestra nueva?, ¿terminó la codificación?, ¿avanzan la cola de envío o las llamadas de publicación? Un proceso en ejecución no equivale a una tarea que progresa. Puede estar esperando datos, una conexión, un registro concreto o un reintento. Si espera que se restablezca la conexión, continúe con la siguiente sección.
Describa el punto preciso respaldado por los registros. «Las muestras se actualizan, pero no se observa ninguna llamada nueva de publicación» orienta mejor que «MQTT falla». Tampoco es todavía una causa raíz: examine el estado y los errores de la tarea.
Continúan los intentos, pero fallan: revisar la conexión utilizada
Tome el intento de publicación fallido más reciente. Compruebe la dirección y el puerto del broker que utilizó realmente el cliente, el resultado de la conexión y el registro del broker a la misma hora.
Si no se estableció la conexión, parta de la fase del fallo: resolución de nombres, TCP y TLS cuando esté habilitado. Para TLS, compruebe la hora del equipo, la cadena de confianza y el nombre del servidor. Desactivar la validación del certificado no demuestra que se haya reparado el problema. Un ping correcto no confirma el acceso al puerto MQTT ni el intercambio TLS.
Si el broker rechaza la conexión MQTT, contraste las credenciales realmente usadas con su respuesta. Si hay conexión pero falla la publicación, revise el tema, los permisos de publicación y el error del cliente. Vincule cada fallo con una comprobación concreta en lugar de cambiar varios parámetros a la vez. Para revisar alimentación, red celular y ruta IP de forma más amplia, consulte la guía de diagnóstico por capas de Wavetel.
Haga las pruebas con la salida de red y la configuración reales del servicio local. Que un cliente de prueba en un portátil publique correctamente solo demuestra el éxito de esa prueba; no confirma que la tarea del router use la misma ruta, identidad, tema o fuente de datos.
Por último, distinga una confirmación recibida por el cliente de un mensaje nuevo visible en el tema de destino del broker. MQTT 3.1.1 no prevé confirmación de publicación para QoS 0. En QoS 1, un PUBACK por sí solo no prueba que la publicación estuviera autorizada ni que la plataforma procesara los datos. La especificación permite que el broker confirme positivamente una publicación no autorizada según las reglas QoS normales o cierre la conexión. Revise el registro de mensajes del tema en el broker, u observe la misma muestra con una suscripción de diagnóstico autorizada. Véase MQTT 3.1.1, §§3.3.4, 3.3.5 y 4.3.2.
Demostrar la recuperación con una muestra nueva
Después de conservar los registros del incidente, restablezca el servicio o la conexión cuyo fallo se haya localizado, dentro del mantenimiento permitido. No se quede en los estados «en línea» o «conectado». Siga una muestra generada después de la recuperación:
La adquisición local registra la muestra e inicia el intento de publicación correspondiente.
El mismo mensaje aparece en el tema de destino del broker remoto, con hora e identificador de datos coincidentes.
Los envíos siguen al intervalo previsto; se documenta cualquier intervención manual adicional.
Son pasos recomendados para verificar el resultado, no una afirmación de que ya se probó un equipo real. Si el broker recibió la muestra nueva pero la plataforma sigue mostrando un valor antiguo, hay pruebas del tramo local-broker. Continúe con la suscripción y el procesamiento de la plataforma, en vez de reiniciar repetidamente un servicio local que ya completó el envío.
Un relevo útil indica el límite observado: «Hay muestras locales nuevas, pero la tarea no ha vuelto a llamar a publicar» o «La tarea sigue intentándolo, pero la conexión falla en TLS». Adjunte los registros correspondientes y el resultado de recuperación que sí haya verificado.
FAQ
Si el router se conecta a un broker externo, ¿es necesariamente receptor?
No. Un cliente puede publicar, suscribirse o ambas cosas. En este ejemplo, el router publica datos adquiridos hacia un broker remoto. Cualquier función adicional de suscriptor debe comprobarse en la configuración real.
¿Por qué puede publicar un cliente de prueba mientras la tarea local no lo hace?
Pueden utilizar salidas de red, identidades, temas o fuentes de datos diferentes. Vuelva a la tarea local: confirme que una muestra nueva inició el intento y revise el resultado real de conexión y publicación.
Si un reinicio restablece los envíos, ¿queda resuelto el incidente?
El trayecto vuelve a funcionar, pero eso no explica por qué se detuvo. Conserve los registros previos al reinicio, confirme que las muestras nuevas siguen llegando al intervalo esperado y documente si el síntoma se repite.
