Recherche de codes de raison MQTT
Vous avez reçu un 0x87, un 135 ou « Connection refused: not authorized » ? Recherchez parmi tous les reason codes MQTT 5 et return codes MQTT 3.1.1 pour savoir ce qu’ils signifient et comment corriger le problème.
- CONNACK
Le serveur a rejeté le nom d’utilisateur ou le mot de passe.
Comment corriger : Vérifiez les identifiants (attention aux espaces en fin de chaîne et à la casse) et confirmez que l’utilisateur existe dans le fichier de mots de passe ou le backend d’authentification du broker.
Astuce : les identifiants par utilisateur et les ACL par topic sont plus faciles à maîtriser quand vous contrôlez le broker — ConnectMQ vous permet de gérer les deux depuis un tableau de bord.
- CONNACKPUBACKPUBRECSUBACKUNSUBACKDISCONNECT
Le client n’a pas le droit d’effectuer cette action : se connecter, publier sur ce topic ou s’abonner à ce filtre.
Comment corriger : Vérifiez l’ACL du broker pour cet utilisateur et ce topic. Sur un CONNACK, cela signifie souvent que l’accès anonyme est désactivé et qu’aucun identifiant n’a été envoyé.
Astuce : les identifiants par utilisateur et les ACL par topic sont plus faciles à maîtriser quand vous contrôlez le broker — ConnectMQ vous permet de gérer les deux depuis un tableau de bord.
- CONNACK
Le client ID est bien formé, mais le serveur ne l’accepte pas (trop long, caractères interdits, ou vide alors que ce n’est pas autorisé).
Comment corriger : Utilisez un client ID alphanumérique court (23 caractères maximum, c’est toujours sûr) ou laissez le broker en attribuer un en envoyant un ID vide avec clean start.
- DISCONNECT
Une autre connexion avec le même client ID s’est connectée : celle-ci a donc été éjectée.
Comment corriger : Attribuez un client ID unique à chaque appareil et à chaque onglet de navigateur. Deux clients partageant un même ID se déconnectent mutuellement en boucle.
- DISCONNECT
Aucun paquet n’a été reçu pendant 1,5 × l’intervalle keep alive : la connexion a donc été fermée.
Comment corriger : Vérifiez que la boucle de votre client tourne (envoi des PINGREQ), évitez de bloquer le thread réseau, ou augmentez l’intervalle keep alive.
- CONNACKPUBACKPUBRECSUBACKUNSUBACKDISCONNECT
Quelque chose a échoué et le serveur ne veut pas (ou ne peut pas) dire quoi.
Comment corriger : Consultez les logs du broker : ils contiennent généralement la vraie cause. Regardez aussi la propriété Reason String si elle a été envoyée.
- CONNACKPUBACKPUBRECSUBACKDISCONNECT
Un quota technique ou administratif a été dépassé (messages, connexions, stockage…).
Comment corriger : Vérifiez votre offre ou les quotas du broker, réduisez le volume de messages, ou demandez à l’opérateur de relever la limite.
Astuce : les identifiants par utilisateur et les ACL par topic sont plus faciles à maîtriser quand vous contrôlez le broker — ConnectMQ vous permet de gérer les deux depuis un tableau de bord.
- 5Connection Refused, not authorized · Connexion refusée, non autoriséMQTT 3.1.1 · code de retour CONNACKCONNACK
Le client n’est pas autorisé à se connecter.
Comment corriger : Envoyez des identifiants si l’accès anonyme est désactivé, et vérifiez l’ACL du broker pour cet utilisateur.
Astuce : les identifiants par utilisateur et les ACL par topic sont plus faciles à maîtriser quand vous contrôlez le broker — ConnectMQ vous permet de gérer les deux depuis un tableau de bord.
Comment fonctionnent les codes de raison MQTT
Un code de raison (reason code) est un octet unique que le broker (ou le client) renvoie pour indiquer le résultat d’une opération. En MQTT 5, il apparaît dans CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT et AUTH. La règle est simple : les valeurs inférieures à 0x80 signifient un succès (parfois avec une information supplémentaire, comme 0x10 No matching subscribers), et les valeurs de 0x80 et plus signifient un échec. Un même nombre a la même signification dans tous les paquets où il est autorisé : 0x87 veut donc toujours dire « Not authorized », qu’il soit renvoyé lors d’une connexion, d’une publication ou d’un abonnement.
MQTT 3.1.1 est bien moins bavard. Seul CONNACK transporte un code de retour (0 à 5), et SUBACK peut seulement indiquer « QoS 0/1/2 accordée » ou 0x80 Failure. Une publication QoS 0 refusée est ignorée silencieusement, et beaucoup de brokers ferment simplement la connexion TCP en cas d’erreur : le log du broker est alors souvent votre seul indice. Si vous avez besoin de remontées d’erreurs précises, passer à MQTT 5 en vaut la peine.
Lire les codes affichés par votre bibliothèque
Les bibliothèques clientes affichent les codes de différentes manières. Paho Python montre des valeurs décimales (rc=135), MQTT.js affiche généralement le nombre décimal accompagné d’un message, et les outils en ligne de commande de Mosquitto impriment un texte comme « Connection Refused: not authorised ». Le champ de recherche ci-dessus accepte toutes ces formes : tapez 135, 0x87, 87 ou une expression comme keep alive. En MQTT 5, le broker peut aussi inclure une propriété Reason String avec une explication lisible : enregistrez-la dans vos logs, car elle est souvent plus précise que le code lui-même.
Les erreurs que vous rencontrerez le plus souvent
- 0x86 / code de retour 4 — identifiant ou mot de passe incorrect. Vérifiez les fautes de frappe, les espaces en fin de chaîne et la casse. Consultez le guide d’authentification Mosquitto pour configurer les fichiers de mots de passe.
- 0x87 / code de retour 5 — non autorisé. Les identifiants sont peut-être corrects, mais l’ACL bloque le topic, ou le broker refuse les clients anonymes.
- 0x8E — session reprise par un autre client. Deux clients partagent le même client ID. Générez des identifiants uniques avec le générateur de Client ID.
- 0x8D — délai keep alive dépassé. Le client a cessé d’envoyer des paquets. Découvrez comment fonctionne le keep alive MQTT.
- 0x95 — paquet trop volumineux. Vérifiez la taille de vos messages avec le calculateur de taille de paquet.
Beaucoup de problèmes de connexion n’arrivent jamais jusqu’au code de raison : les échecs DNS, les mauvais ports et les erreurs de handshake TLS surviennent avant même que MQTT ne démarre. Pour ces cas, consultez les erreurs de connexion MQTT courantes et la référence des ports MQTT, ou reproduisez le problème dans le client MQTT en ligne, qui affiche le résultat du CONNACK dans son journal.
Tous les codes de raison MQTT 5
Tous les reason codes définis dans la section 2.4 de la spécification OASIS MQTT 5.0. Créez un lien vers un code avec #0x87.
| Code | Nom | Paquets | Signification et solution |
|---|---|---|---|
| 0x00 déc. 0 | Success Succès | CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, UNSUBACK, AUTH | L’opération s’est terminée avec succès. Solution : Rien à corriger : c’est le résultat normal. |
| 0x00 déc. 0 | Normal disconnection Déconnexion normale | DISCONNECT | La connexion a été fermée volontairement et le Will Message n’est pas envoyé. Solution : Rien à corriger. Si vous ne vous attendiez pas à cette déconnexion, vérifiez quel côté l’a envoyée et pourquoi. |
| 0x00 déc. 0 | Granted QoS 0 QoS 0 accordée | SUBACK | L’abonnement a été accepté avec une QoS maximale de 0. Solution : Si vous aviez demandé une QoS 1 ou 2, le broker l’a rétrogradée : vérifiez son paramètre de QoS maximale. |
| 0x01 déc. 1 | Granted QoS 1 QoS 1 accordée | SUBACK | L’abonnement a été accepté avec une QoS maximale de 1. Solution : Si vous aviez demandé une QoS 2, le broker plafonne la QoS à 1 : concevez votre application pour une livraison « au moins une fois » (traitements idempotents). |
| 0x02 déc. 2 | Granted QoS 2 QoS 2 accordée | SUBACK | L’abonnement a été accepté avec une QoS maximale de 2. Solution : Rien à corriger : vous obtenez bien la livraison « exactement une fois » demandée. |
| 0x04 déc. 4 | Disconnect with Will Message Déconnexion avec Will Message | DISCONNECT | Le client veut se déconnecter, mais demande au serveur de publier quand même son Will Message. Solution : Rien à corriger : c’est un choix délibéré du client. |
| 0x10 déc. 16 | No matching subscribers Aucun abonné correspondant | PUBACK, PUBREC | Le message a été accepté, mais personne n’est actuellement abonné à ce topic. Solution : Ce n’est pas une erreur. Vérifiez que l’abonné est connecté et que son filtre de topic correspond exactement au topic (sensible à la casse). |
| 0x11 déc. 17 | No subscription existed Aucun abonnement existant | UNSUBACK | Le client a tenté de se désabonner d’un filtre de topic auquel il n’était pas abonné. Solution : Assurez-vous que le filtre de désabonnement est identique, octet pour octet, à celui utilisé lors de l’abonnement. |
| 0x18 déc. 24 | Continue authentication Poursuivre l’authentification | AUTH | Une authentification étendue est en cours et une nouvelle étape AUTH est nécessaire. Solution : Votre client doit répondre avec un paquet AUTH contenant l’étape suivante de la méthode d’authentification. |
| 0x19 déc. 25 | Re-authenticate Réauthentification | AUTH | Le client demande à relancer l’authentification étendue sur une connexion existante. Solution : Rien à corriger : sert à renouveler des identifiants, comme des jetons qui expirent. |
| 0x80 déc. 128 | Unspecified error Erreur non spécifiée | CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT | Quelque chose a échoué et le serveur ne veut pas (ou ne peut pas) dire quoi. Solution : Consultez les logs du broker : ils contiennent généralement la vraie cause. Regardez aussi la propriété Reason String si elle a été envoyée. |
| 0x81 déc. 129 | Malformed Packet Paquet malformé | CONNACK, DISCONNECT | Le paquet reçu ne respecte pas la spécification MQTT et n’a pas pu être analysé. Solution : Mettez à jour votre bibliothèque cliente, vérifiez que la version du protocole correspond, et assurez-vous de ne pas parler MQTT à un port non MQTT (ou TCP en clair à un port TLS). |
| 0x82 déc. 130 | Protocol Error Erreur de protocole | CONNACK, DISCONNECT | Le paquet a été analysé correctement mais enfreint une règle du protocole, par exemple un second CONNECT ou une propriété en double. Solution : Il s’agit généralement d’un bug de la bibliothèque cliente ou de code de paquets maison. Mettez à jour la bibliothèque et évitez d’envoyer des paquets dans le désordre. |
| 0x83 déc. 131 | Implementation specific error Erreur propre à l’implémentation | CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT | Le paquet est valide, mais le serveur le rejette pour une raison propre au broker. Solution : Lisez la Reason String ainsi que la documentation et les logs du broker : la cause dépend du broker (plugins, limites, politiques). |
| 0x84 déc. 132 | Unsupported Protocol Version Version du protocole non prise en charge | CONNACK | Le serveur ne prend pas en charge la version du protocole MQTT demandée par le client. Solution : Passez le client en MQTT 3.1.1 (protocol level 4) ou mettez à niveau vers un broker qui prend en charge MQTT 5. |
| 0x85 déc. 133 | Client Identifier not valid Identifiant client non valide | CONNACK | Le client ID est bien formé, mais le serveur ne l’accepte pas (trop long, caractères interdits, ou vide alors que ce n’est pas autorisé). Solution : Utilisez un client ID alphanumérique court (23 caractères maximum, c’est toujours sûr) ou laissez le broker en attribuer un en envoyant un ID vide avec clean start. |
| 0x86 déc. 134 | Bad User Name or Password Identifiant ou mot de passe incorrect | CONNACK | Le serveur a rejeté le nom d’utilisateur ou le mot de passe. Solution : Vérifiez les identifiants (attention aux espaces en fin de chaîne et à la casse) et confirmez que l’utilisateur existe dans le fichier de mots de passe ou le backend d’authentification du broker. |
| 0x87 déc. 135 | Not authorized Non autorisé | CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT | Le client n’a pas le droit d’effectuer cette action : se connecter, publier sur ce topic ou s’abonner à ce filtre. Solution : Vérifiez l’ACL du broker pour cet utilisateur et ce topic. Sur un CONNACK, cela signifie souvent que l’accès anonyme est désactivé et qu’aucun identifiant n’a été envoyé. |
| 0x88 déc. 136 | Server unavailable Serveur indisponible | CONNACK | Le serveur MQTT n’est pas disponible pour le moment. Solution : Réessayez avec un backoff exponentiel. Si le problème persiste, vérifiez l’état du broker, du cluster et les fenêtres de maintenance. |
| 0x89 déc. 137 | Server busy Serveur occupé | CONNACK, DISCONNECT | Le serveur est surchargé et refuse l’opération ; réessayez plus tard. Solution : Patientez et réessayez avec un délai aléatoire (jitter), pour que des milliers d’appareils ne se reconnectent pas au même instant. |
| 0x8A déc. 138 | Banned Banni | CONNACK | Ce client a été banni par une action administrative. Solution : Contactez l’opérateur du broker. Des échecs de connexion répétés ou un trafic abusif sont des causes fréquentes de bannissement. |
| 0x8B déc. 139 | Server shutting down Arrêt du serveur en cours | DISCONNECT | Le serveur est en train de s’arrêter. Solution : Reconnectez-vous avec un backoff ; utilisez une session persistante pour que les abonnements et les messages QoS 1/2 en file d’attente soient conservés. |
| 0x8C déc. 140 | Bad authentication method Méthode d’authentification incorrecte | CONNACK, DISCONNECT | La méthode d’authentification indiquée dans CONNECT n’est pas prise en charge ou ne correspond pas à celle en cours d’utilisation. Solution : Supprimez la propriété Authentication Method ou indiquez une méthode prise en charge par le broker (par ex. SCRAM-SHA-256). |
| 0x8D déc. 141 | Keep Alive timeout Délai keep alive dépassé | DISCONNECT | Aucun paquet n’a été reçu pendant 1,5 × l’intervalle keep alive : la connexion a donc été fermée. Solution : Vérifiez que la boucle de votre client tourne (envoi des PINGREQ), évitez de bloquer le thread réseau, ou augmentez l’intervalle keep alive. |
| 0x8E déc. 142 | Session taken over Session reprise par une autre connexion | DISCONNECT | Une autre connexion avec le même client ID s’est connectée : celle-ci a donc été éjectée. Solution : Attribuez un client ID unique à chaque appareil et à chaque onglet de navigateur. Deux clients partageant un même ID se déconnectent mutuellement en boucle. |
| 0x8F déc. 143 | Topic Filter invalid Filtre de topic non valide | SUBACK, UNSUBACK, DISCONNECT | Le filtre de topic est bien formé, mais n’est pas accepté par ce serveur. Solution : Vérifiez la position des wildcards (+ doit occuper un niveau entier, # doit être en dernier) et les éventuelles limites du broker sur la profondeur ou la longueur des topics. |
| 0x90 déc. 144 | Topic Name invalid Nom de topic non valide | CONNACK, PUBACK, PUBREC, DISCONNECT | Le nom de topic est bien formé, mais n’est pas accepté par le client ou le serveur. Solution : Ne publiez jamais sur un topic contenant + ou #, évitez les topics vides et vérifiez les limites de longueur et de profondeur des topics du broker. |
| 0x91 déc. 145 | Packet Identifier in use Identifiant de paquet déjà utilisé | PUBACK, PUBREC, SUBACK, UNSUBACK | L’identifiant de paquet est déjà utilisé par un autre échange en cours. Solution : Il s’agit généralement d’un bug de la bibliothèque cliente ou d’une session restaurée de manière incohérente. Mettez à jour la bibliothèque ou démarrez une session propre (clean session). |
| 0x92 déc. 146 | Packet Identifier not found Identifiant de paquet introuvable | PUBREL, PUBCOMP | L’identifiant de paquet est inconnu : l’état du flux QoS 2 a été perdu. Solution : Se produit après une perte de l’état de session (par ex. clean start ou redémarrage du broker sans persistance). Activez la persistance sur le broker. |
| 0x93 déc. 147 | Receive Maximum exceeded Receive Maximum dépassé | DISCONNECT | Plus de paquets PUBLISH QoS 1/2 non acquittés ont été envoyés que ce que le destinataire autorise. Solution : Respectez le Receive Maximum indiqué dans CONNACK/CONNECT ; limitez le nombre de messages en vol dans les paramètres de votre client. |
| 0x94 déc. 148 | Topic Alias invalid Topic Alias non valide | DISCONNECT | Un topic alias valait 0, dépassait le Topic Alias Maximum ou a été utilisé avant d’être défini. Solution : Respectez le Topic Alias Maximum annoncé par l’autre partie, ou désactivez les topic aliases. |
| 0x95 déc. 149 | Packet too large Paquet trop volumineux | CONNACK, DISCONNECT | Le paquet dépasse la taille maximale de paquet autorisée par le destinataire. Solution : Réduisez le payload (compression, découpage ou envoi d’une référence) ou augmentez la taille maximale des messages sur le broker. |
| 0x96 déc. 150 | Message rate too high Débit de messages trop élevé | DISCONNECT | Le client publie plus vite que le serveur ne l’autorise. Solution : Limitez le rythme des publications, regroupez les mesures dans moins de messages, ou augmentez la limite de débit sur le broker. |
| 0x97 déc. 151 | Quota exceeded Quota dépassé | CONNACK, PUBACK, PUBREC, SUBACK, DISCONNECT | Un quota technique ou administratif a été dépassé (messages, connexions, stockage…). Solution : Vérifiez votre offre ou les quotas du broker, réduisez le volume de messages, ou demandez à l’opérateur de relever la limite. |
| 0x98 déc. 152 | Administrative action Action administrative | DISCONNECT | La connexion a été fermée par un administrateur. Solution : Contactez l’opérateur du broker : quelqu’un a éjecté ce client manuellement ou via une API d’administration. |
| 0x99 déc. 153 | Payload format invalid Format de payload non valide | CONNACK, PUBACK, PUBREC, DISCONNECT | Le payload ne correspond pas au Payload Format Indicator (par ex. marqué UTF-8 mais pas en UTF-8 valide). Solution : Ne définissez Payload Format Indicator = 1 que si le payload est du texte UTF-8 valide ; envoyez les données binaires sans cet indicateur. |
| 0x9A déc. 154 | Retain not supported Retain non pris en charge | CONNACK, DISCONNECT | Le serveur ne prend pas en charge les messages retenus, mais le client en a envoyé un. Solution : Retirez le flag retain des publications et du Will Message, ou utilisez un broker qui prend en charge retain. |
| 0x9B déc. 155 | QoS not supported QoS non prise en charge | CONNACK, DISCONNECT | Le client a utilisé une QoS supérieure à la Maximum QoS annoncée par le serveur dans CONNACK. Solution : Lisez la Maximum QoS dans CONNACK et publiez (et réglez la Will QoS) à ce niveau ou en dessous. |
| 0x9C déc. 156 | Use another server Utiliser un autre serveur | CONNACK, DISCONNECT | Le client doit utiliser temporairement un autre serveur. Solution : Lisez la propriété Server Reference et connectez-vous à ce serveur ; prenez en charge la redirection dans votre client si vous exploitez des clusters. |
| 0x9D déc. 157 | Server moved Serveur déplacé | CONNACK, DISCONNECT | Le serveur a été déplacé définitivement ; le client doit utiliser un autre serveur. Solution : Mettez à jour le nom d’hôte du broker dans votre configuration à l’aide de la propriété Server Reference. |
| 0x9E déc. 158 | Shared Subscriptions not supported Abonnements partagés non pris en charge | SUBACK, DISCONNECT | Le serveur ne prend pas en charge les abonnements partagés $share/…. Solution : Utilisez des abonnements classiques, ou un broker qui prend en charge les abonnements partagés pour répartir la charge entre consommateurs. |
| 0x9F déc. 159 | Connection rate exceeded Fréquence de connexion dépassée | CONNACK, DISCONNECT | Le client se connecte trop souvent ; la limite de fréquence de connexion a été atteinte. Solution : Ajoutez un backoff exponentiel avec jitter aux reconnexions et cherchez une boucle de reconnexion (souvent causée par des client IDs en double). |
| 0xA0 déc. 160 | Maximum connect time Durée de connexion maximale | DISCONNECT | La durée de connexion maximale autorisée pour ce client a été atteinte. Solution : Reconnectez-vous ; envisagez une session persistante pour ne rien perdre pendant la brève reconnexion. |
| 0xA1 déc. 161 | Subscription Identifiers not supported Subscription Identifiers non pris en charge | SUBACK, DISCONNECT | Le serveur ne prend pas en charge la propriété Subscription Identifier. Solution : Retirez le Subscription Identifier du SUBSCRIBE et routez plutôt les messages selon leur topic. |
| 0xA2 déc. 162 | Wildcard Subscriptions not supported Abonnements avec wildcards non pris en charge | SUBACK, DISCONNECT | Le serveur ne prend pas en charge les abonnements contenant les wildcards + ou #. Solution : Abonnez-vous à des noms de topics exacts, ou utilisez un broker qui prend en charge les abonnements avec wildcards. |
Codes de retour MQTT 3.1.1
Les codes de retour CONNACK 0 à 5 et le code d’échec SUBACK de la spécification MQTT 3.1.1.
| Code | Nom | Paquets | Signification et solution |
|---|---|---|---|
| 0 déc. 0 | Connection Accepted Connexion acceptée | CONNACK | Le broker a accepté la connexion. Solution : Rien à corriger. |
| 1 déc. 1 | Connection Refused, unacceptable protocol version Connexion refusée, version de protocole inacceptable | CONNACK | Le broker ne prend pas en charge le niveau de protocole demandé par le client. Solution : Réglez le client sur MQTT 3.1.1 (niveau 4) ou 3.1 (niveau 3) pour correspondre au broker. |
| 2 déc. 2 | Connection Refused, identifier rejected Connexion refusée, identifiant rejeté | CONNACK | Le client ID est en UTF-8 valide, mais n’est pas autorisé par le broker. Solution : Utilisez 1 à 23 caractères parmi [0-9a-zA-Z], ou envoyez un ID vide avec clean session = true. |
| 3 déc. 3 | Connection Refused, server unavailable Connexion refusée, serveur indisponible | CONNACK | La connexion réseau a fonctionné, mais le service MQTT est indisponible. Solution : Réessayez avec un backoff et vérifiez l’état du broker. |
| 4 déc. 4 | Connection Refused, bad user name or password Connexion refusée, identifiant ou mot de passe incorrect | CONNACK | Le nom d’utilisateur ou le mot de passe est mal formé ou erroné. Solution : Vérifiez les identifiants et que l’utilisateur existe dans le backend d’authentification du broker. |
| 5 déc. 5 | Connection Refused, not authorized Connexion refusée, non autorisé | CONNACK | Le client n’est pas autorisé à se connecter. Solution : Envoyez des identifiants si l’accès anonyme est désactivé, et vérifiez l’ACL du broker pour cet utilisateur. |
| 0x80 déc. 128 | Failure Échec | SUBACK | L’abonnement a été rejeté, généralement à cause d’une ACL ou d’un filtre de topic non valide. Solution : Vérifiez la syntaxe du filtre et que l’utilisateur a le droit de s’y abonner. MQTT 3.1.1 ne donne aucun détail supplémentaire : consultez le log du broker. |
FAQ sur les codes de raison
Que signifie le code de raison MQTT 0x87 (135) ?
0x87 signifie Not authorized (non autorisé). Sur un CONNACK, le broker a refusé la connexion (souvent parce que l’accès anonyme est désactivé et qu’aucun identifiant n’a été envoyé). Sur un PUBACK, un SUBACK ou un DISCONNECT, cela signifie que l’utilisateur n’a pas la permission requise pour ce topic dans l’ACL du broker.
Quelle est la différence entre un reason code et un return code ?
MQTT 3.1.1 ne possède des codes de retour (return codes) que dans CONNACK (0 à 5) et SUBACK (0x00 à 0x02 et 0x80). MQTT 5 les a remplacés par des codes de raison (reason codes) présents dans presque tous les acquittements, dans DISCONNECT et dans AUTH ; une valeur de 0x80 ou plus indique toujours un échec.
Pourquoi mon client se déconnecte-t-il sans cesse avec 0x8E Session taken over ?
Deux connexions utilisent le même client ID. Lorsque la seconde se connecte, le broker déconnecte la première. Si les deux se reconnectent automatiquement, elles s’éjectent mutuellement en boucle. Attribuez un client ID unique à chaque appareil et à chaque onglet de navigateur.
Pourquoi est-ce que j’obtiens le code de retour 5 en MQTT 3.1.1 ?
Le code de retour 5 signifie Connection Refused, not authorized. Le broker exige une authentification, ou l’utilisateur est bloqué par ses règles d’accès. Envoyez un identifiant et un mot de passe valides, puis vérifiez l’ACL du broker ou le paramètre allow_anonymous.