Anglais
Chinois
Espagnol
Russe
Portugais
Allemand
Indonésien
Thaï
Vietnamien
Arabe
Italien
Turc
Polonais
Japonais
Les échecs de connexion MQTT doivent être examinés à la première étape défaillante : résolution de destination, connexion réseau, TLS si requis, acceptation du broker ou permission de message. Modifier un sujet ne répare pas une négociation TLS en échec. Conservez l’erreur client et le journal correspondant du broker pour que l’essai suivant cible la bonne étape.
Confirmer ce qu’exécute la passerelle installée
La passerelle METRAVON TG451 mentionne MQTT dans ses fonctions logicielles, mais le mode de micrologiciel requis et la conception des messages plateforme restent à confirmer. Consignez version du micrologiciel, version MQTT, transport, nom d’hôte du broker, port de service et identité affectée à cette installation.
Vérifiez les spécifications réelles du service pour TCP non chiffré, TLS ou un autre transport pris en charge. Ne déduisez pas le port d’une valeur par défaut mémorisée. Confirmez que la destination est bien le point d’accès du broker, pas une console web ni une route d’équilibrage destinée à un autre service.
Localiser les échecs MQTT dans les journaux
| Résultat | Étape probable | Preuves utiles |
|---|---|---|
| Échec du nom | La résolution n’a pas fourni d’adresse exploitable. | Consigner nom d’hôte, résultat du résolveur et trajet réseau actif sans changer les identifiants. |
| Échec du port | La connexion au service demandé n’est pas établie. | Comparer la tentative aux journaux du service en écoute et du pare-feu. |
| Échec TLS | La session sécurisée n’a pas été établie. | Conserver l’erreur de négociation et vérifier heure, nom d’hôte et certificats requis. |
| Rejet du broker | Le serveur a retourné un résultat de connexion MQTT. | Interpréter ce résultat selon la version négociée et le journal du broker. |
| Aucune donnée utile | L’acceptation de connexion n’a pas produit le résultat applicatif attendu. | Inspecter droits sur les sujets, traitement de la charge utile et journal des enregistrements acceptés. |
Corriger confiance et identité sans les contourner
Pour TLS, confirmez horloge de la passerelle, validité du certificat et nom d’hôte. Une autorité privée exige une configuration de confiance adaptée. Si TLS mutuel est requis, établissez que certificat client et clé privée correspondent et appartiennent à l’appareil prévu.
Ne versez pas de clés privées dans les tickets d’assistance et ne désactivez pas la vérification des certificats pour effacer l’erreur. Demandez au responsable du service la chaîne de confiance attendue et les paramètres pris en charge, puis appliquez-les par le processus autorisé.
L’identité du client MQTT et les droits de publication sont distincts. Un broker peut accepter une connexion et rejeter une opération non autorisée. Vérifiez sujet exact, casse et règles du compte. Avec MQTT 3.1.1, si un broker accepte une nouvelle connexion avec un identifiant client déjà connecté, il déconnecte le client existant. Deux passerelles partageant cet identifiant peuvent donc s’évincer à chaque reconnexion. Comparez identifiants clients et heures de connexion du broker avant de changer antennes ou maintien de connexion.
Distinguer publication réussie et mesure correcte
Le broker transporte une charge utile ; il n’en valide pas intrinsèquement le sens physique. Comparez un message capturé au schéma convenu et à une mesure source vérifiée. Vérifiez unités, échelle, identité source et heure d’acquisition avant d’attribuer l’absence de tendance à la connectivité.
Un PUBACK QoS 1 confirme que le récepteur MQTT a accepté la responsabilité du message, pas que la base finale a stocké la mesure. QoS 1 peut livrer des doublons ; QoS 2 empêche la livraison en double dans son échange protocolaire, mais ne certifie pas le traitement ultérieur en base. Vérifiez le QoS pris en charge par le micrologiciel et le service, puis définissez comment l’application identifie et rapproche les enregistrements répétés. Un message conservé n’est pas une archive chronologique ; une session existante ne prouve pas la disponibilité de toutes les mesures antérieures.
Pour des sessions instables, comparez réglage de maintien de connexion, interruptions réseau et causes de fermeture côté serveur. Définissez reprises et maintien selon les exigences du service et les conditions observées. Des boucles de reprise agressives peuvent masquer l’erreur d’origine et surcharger la destination.
Utiliser un client d’essai isolé pour une question précise
Un client approuvé sur le même réseau peut aider à distinguer accessibilité du service et configuration de passerelle. Donnez-lui une identité distincte et un sujet d’essai autorisé. Ne dupliquez pas une identité en service et ne publiez pas de valeurs d’essai dans les mesures de production.
Consignez le point d’accès, le transport et la catégorie d’identifiants testés. Une connexion réussie depuis un portable sur un autre réseau est utile, mais ne vérifie ni la route, ni l’horloge, ni le magasin de confiance de la passerelle.
Questions d’intégration MQTT
Q1. Faut-il changer les sujets si le broker n’accepte jamais la session ?
Résolvez d’abord l’étape de connexion défaillante. La correspondance des sujets télémétriques ordinaires intervient après acceptation, même si certaines fonctions liées à la connexion ont leurs propres exigences de politique. Utilisez le rejet réel du broker plutôt que de modifier des champs sans rapport.
Q2. Une authentification réussie prouve-t-elle le droit de publier ?
Non. Confirmez les opérations autorisées et les chemins exacts des sujets du compte. Vérifiez ensuite la charge utile acceptée par l’application aval ; autorisation de transport et validation applicative sont distinctes.
Q3. Que joindre à une demande d’assistance MQTT ?
Envoyez modèle et micrologiciel, version du protocole, transport, point d’accès, heure d’erreur et résultats client/broker expurgés. Incluez un exemple expurgé de sujet et de charge utile si la session fonctionne sans données exploitables. Excluez mots de passe, jetons et clés privées.
Synthèse
Diagnostiquez l’étape de connexion en échec, puis vérifiez séparément les permissions de message et les données physiques. Demandez une étude de configuration MQTT METRAVON avec l’erreur consignée et les spécifications du service, pas seulement une capture indiquant un état hors ligne.
