Routeur industriel en ligne, MQTT à l’arrêt ? Vérifiez la tâche
Imaginons une station de pompage où le routeur industriel local acquiert des mesures de pression et de niveau d’eau, puis exécute lui-même une tâche de publication MQTT. Il envoie les données à un broker distant ; la plateforme les récupère par abonnement. Après une période de fonctionnement normal, les valeurs affichées ne se mettent plus à jour. Pourtant, le routeur indique toujours une connexion 4G/5G et répond à un test ping vers l’extérieur.
Dans cette configuration, le routeur est le client qui publie, pas le broker. Un client MQTT peut publier, s’abonner ou faire les deux. Le fait de se connecter à un broker ne signifie pas qu’il ne fait que recevoir. Voir les définitions de MQTT 3.1.1, §1.2.
La première distinction est la suivante : la tâche locale progresse-t-elle encore, ou tente-t-elle de publier sans y parvenir à cause de la connexion ou de la publication ? L’accès réseau ne répond pas à cette question.
Cette méthode concerne un appareil qui prend effectivement en charge l’acquisition et la publication MQTT locales et qui est configuré ainsi. Vérifiez d’abord la topologie réelle. Si le routeur ne fait que transporter le trafic d’une passerelle distincte, examinez la tâche sur cette passerelle. S’il joue le rôle de broker ou d’abonné, contrôlez le service correspondant.
Suivre un nouvel échantillon pour localiser la rupture
Choisissez une mesure facile à reconnaître. Notez l’heure, l’identifiant et le sujet MQTT d’un nouvel échantillon. Recherchez des preuves à trois points :
Nouvel échantillon produit → tentative de publication par la tâche locale → même nouveau message présent sur le sujet cible du broker distant.
Preuve disponible | Vérification suivante |
|---|---|
Un nouvel échantillon existe, mais aucune tentative de publication n’est observée | Le transfert de l’acquisition vers la publication, puis la tâche locale |
La tâche continue d’essayer, mais les journaux signalent un échec de connexion ou de publication | La connexion, l’authentification et le résultat de publication du client MQTT réel vers le broker distant |
Le même nouveau message apparaît sur le sujet cible du broker | L’abonnement et le traitement par la plateforme |
Si aucun nouvel échantillon n’est produit, revenez à la source des données et à l’acquisition. Si aucune tentative n’est visible, ne concluez pas tout de suite que la tâche s’est arrêtée : activez les diagnostics disponibles sur l’appareil pour établir si cette étape a eu lieu.
Avant toute modification, conservez les journaux de l’incident, la durée de fonctionnement du client, l’adresse et le port du broker, l’identifiant client et le sujet. Notez tout décalage entre les horloges pour rapprocher les traces d’une même tentative.
Échantillons récents, mais pas de tentative : examiner la tâche locale
Commencez par vérifier si le service de publication s’exécute. Si le processus s’est arrêté, relevez l’heure, l’erreur et l’historique des redémarrages, puis rétablissez-le selon la procédure de maintenance prise en charge. Modifier les paramètres de connexion MQTT ne remettra pas en marche un service arrêté.
Si le processus existe encore, cherchez sa dernière étape accomplie. L’échantillon a-t-il été transmis à la tâche de publication ? Son encodage est-il terminé ? La file d’envoi ou les appels de publication avancent-ils ? Un processus actif ne prouve pas que sa tâche progresse. Elle peut attendre des données, une connexion, un enregistrement ou une nouvelle tentative. Si elle attend le retour de la connexion, passez à la section suivante.
Décrivez ce que les traces montrent réellement. « Les échantillons se mettent à jour, mais aucun nouvel appel de publication n’est observé » oriente mieux le diagnostic que « MQTT ne fonctionne pas ». Cela ne constitue toujours pas une cause racine ; examinez l’état et les erreurs de la tâche.
Les tentatives continuent, mais échouent : vérifier la connexion réelle
Prenez la dernière tentative de publication en échec. Relevez l’adresse et le port du broker effectivement utilisés, le résultat de connexion et les journaux du broker à la même heure.
Si la connexion ne s’est pas établie, partez de l’étape d’échec : résolution du nom, TCP, puis TLS s’il est activé. Pour TLS, vérifiez l’heure de l’appareil, la chaîne de confiance et le nom du serveur. Désactiver la vérification du certificat n’est pas une preuve de réparation. Un ping réussi ne valide ni le port MQTT ni la négociation TLS.
Si le broker refuse la connexion MQTT, comparez les identifiants réellement employés à sa réponse. Si la session est ouverte mais que la publication échoue, vérifiez le sujet, les droits de publication et l’erreur signalée par le client. Associez chaque échec à une vérification précise plutôt que de modifier plusieurs réglages à la fois. Pour les couches alimentation, cellulaire et IP, voir le guide de diagnostic par couches de Wavetel.
Testez aussi avec la sortie réseau et les paramètres du service local. Un client de test installé sur un ordinateur portable ne prouve que la réussite de ce test ; il ne garantit pas que la tâche du routeur utilise le même trajet, la même identité, le même sujet ou la même source.
Enfin, distinguez l’accusé de réception reçu par le client d’un nouveau message visible sur le sujet cible du broker. MQTT 3.1.1 ne prévoit pas d’accusé de publication pour QoS 0. Pour QoS 1, un PUBACK ne prouve à lui seul ni l’autorisation de publier ni le traitement par la plateforme. La norme permet au broker d’accuser réception selon les règles QoS habituelles d’une publication non autorisée, ou de fermer la connexion. Contrôlez les messages du sujet sur le broker, ou observez le même nouvel échantillon avec un abonnement de diagnostic autorisé. Voir MQTT 3.1.1, §§3.3.4, 3.3.5 et 4.3.2.
Démontrer la reprise avec un nouvel échantillon
Après avoir conservé les traces, rétablissez le service ou la connexion dont le défaut a été localisé, dans le cadre de maintenance autorisé. Ne vous arrêtez pas aux statuts « en ligne » ou « connecté ». Suivez un échantillon produit après la reprise :
Confirmez son acquisition locale et la tentative de publication correspondante.
Retrouvez le même message sur le sujet cible du broker distant, avec heure de mesure et identifiant concordants.
Vérifiez que les envois se poursuivent à la fréquence attendue et consignez toute autre intervention manuelle.
Il s’agit d’une méthode de vérification recommandée, pas d’un essai matériel déjà réalisé. Si le broker a reçu le nouvel échantillon mais que la plateforme affiche encore une ancienne valeur, le tronçon local-vers-broker dispose de preuves. Poursuivez sur l’abonnement et le traitement de la plateforme au lieu de redémarrer à répétition le service local.
Une transmission utile au prochain intervenant précise la limite observée : « Les échantillons locaux sont récents, mais la tâche n’a plus émis d’appel de publication », ou « La tâche essaie encore, mais TLS empêche la connexion ». Joignez les traces et le résultat de reprise réellement vérifié.
FAQ
Un routeur connecté à un broker externe est-il forcément récepteur ?
Non. Un client peut publier, s’abonner ou faire les deux. Ici, le routeur publie des données acquises vers un broker distant. Tout rôle d’abonné supplémentaire doit être confirmé dans la configuration réelle.
Pourquoi un client de test publie-t-il alors que la tâche locale n’y parvient pas ?
Les deux clients peuvent employer des sorties réseau, identités, sujets ou sources différentes. Revenez à la tâche locale : vérifiez qu’un nouvel échantillon déclenche une tentative, puis contrôlez son résultat de connexion et de publication.
Si un redémarrage rétablit les données, peut-on clore l’incident ?
Le trajet fonctionne de nouveau, mais la cause de l’arrêt reste à établir. Conservez les traces d’avant redémarrage, vérifiez que les nouveaux échantillons continuent d’arriver et consignez toute récidive.
