Cette page vous aide lorsqu’un appareil ne peut pas se connecter à Hermetry, est refusé à la connexion ou perd sa connexion en permanence. Elle couvre MQTT et l’API HTTP des appareils. Pour les appareils LoRaWAN, voir Résolution des problèmes de jointure ; pour les appareils en interrogation, voir Intervalles d’interrogation, temporisation et quota.
Où chercher en premier
| Emplacement | Affiche |
|---|---|
| L’onglet Log de l’appareil | Chaque refus de connexion avec sa raison, et chaque déconnexion avec sa raison. La raison d’un refus n’est jamais envoyée à l’appareil : elle n’est disponible qu’ici. |
| La carte Connection details de l’appareil | Le nom d’hôte du broker et les ports que votre appareil doit utiliser |
| Le journal propre au client | Le code CONNACK ou le statut HTTP reçu, ou l’erreur TLS |
Étape 1 : l’appareil peut-il joindre le broker ?
| Symptôme sur l’appareil | Cause | Correction |
|---|---|---|
| La résolution DNS échoue, ou la connexion expire | Mauvais hôte, ou un pare-feu bloque le port sortant | Utilisez l’hôte indiqué dans la carte Connection details, pour la région de votre organisation. Autorisez le TCP sortant 8883 (et 443 pour HTTPS). |
| La négociation TLS échoue | L’appareil se connecte par adresse IP (SNI est requis), n’a pas de bundle d’autorités de certification, ou son horloge est très décalée, de sorte que le certificat semble invalide | Connectez-vous par nom d’hôte ; utilisez le magasin d’autorités de certification du système ; réglez l’horloge (NTP) |
| TLS échoue sur un appareil très petit | Il ne prend en charge que d’anciennes suites de chiffrement ou TLS 1.0/1.1 | TLS 1.2 est le minimum, avec des suites ECDHE et GCM ou ChaCha20. Mettez à jour la bibliothèque TLS. |
| Le port 1883 est refusé | Le profil est TLS only (port 8883), la valeur par défaut | Utilisez 8883 ou, uniquement sur un réseau privé, autorisez le MQTT non chiffré sur le profil |
| Un certificat client est rejeté pendant la négociation | Le certificat ne provient pas de l’autorité de certification des appareils Hermetry, ou il a été révoqué | Un certificat non approuvé met fin à la négociation ; il n’existe pas de repli vers un mot de passe. Voir Certificats des appareils. |
Voir Sécurité du transport des appareils.
Étape 2 : la connexion est-elle acceptée ?
MQTT répond au CONNECT par un code CONNACK :
| CONNACK | Signification | Causes habituelles |
|---|---|---|
| 1 | Version de protocole non prise en charge | Le client envoie MQTT 5. Hermetry parle MQTT 3.1.1. |
| 2 | Identifiant client rejeté | L’identifiant client est vide, dépasse 64 caractères ou contient des caractères hors de A–Z a–z 0–9 . _ : - |
| 3 | Serveur indisponible | Le service démarre ou est occupé, ou votre adresse est brièvement bloquée après des connexions échouées répétées. Espacez les tentatives et réessayez avec une gigue aléatoire. |
| 4 | Nom d’utilisateur ou mot de passe incorrect | Le jeton ou le mot de passe est erroné, a été renouvelé ou révoqué ; un nom d’utilisateur sans mot de passe est lu comme un jeton d’accès |
| 5 | Non autorisé | Voir le tableau ci-dessous. La raison exacte figure dans l’onglet Log de l’appareil. |
| Raison du CONNACK 5 | Correction |
|---|---|
| L’appareil est désactivé | Activez-le depuis la page de l’appareil |
| Le certificat est révoqué ou expiré | Laissez l’appareil le renouveler, ou récupérez-le. Voir Certificats des appareils. |
| Le profil n’autorise pas ce type de connexion | Allowed authentication dans l’onglet Transport & auth du profil |
| L’adresse de l’appareil est en dehors des Allowed networks du profil | Ajoutez le réseau, ou vérifiez quelle adresse publique votre site utilise réellement (NAT, opérateur mobile) |
| MQTT non chiffré sur un profil TLS uniquement | Utilisez le port 8883 |
| L’organisation est suspendue | Demandez à un propriétaire de l’organisation. Voir Organisations et locataires. |
| La limite d’appareils ou d’appareils connectés du forfait est atteinte | Voir Forfaits et l’extension IoT |
En HTTP, les mêmes contrôles répondent 401 (jeton absent ou inconnu), 403 (désactivé, suspendu, en dehors des réseaux autorisés, ou une interrogation de commandes en HTTP non chiffré que le profil n’autorise pas : tls_required) ou 404 (un jeton dans l’URL sur un profil sans Token in the URL). Voir API HTTP des appareils.
Rappels de connexion
| Identifiant | Client ID | Nom d’utilisateur | Mot de passe |
|---|---|---|---|
| Jeton d’accès | tout ID valide | le jeton | vide |
| MQTT basique | au choix, ou celui épinglé | le nom d’utilisateur | le mot de passe |
| Certificat X.509 | le numéro de série de l’appareil, égal au CN du certificat | ignoré | vide |
Le secret d’un identifiant n’est affiché qu’une seule fois, à sa création ou à son renouvellement. S’il a été perdu, renouvelez-le et mettez à jour l’appareil. Voir Identifiants des appareils.
Étape 3 : l’appareil se connecte, puis se déconnecte
L’onglet Log indique la raison de la déconnexion :
| Raison | Signification | Correction |
|---|---|---|
keepalive_timeout | Rien n’est arrivé dans le délai de keepalive | Utilisez un keepalive de 30 à 300 secondes et envoyez PINGREQ ; vérifiez la liaison mobile |
takeover | Une seconde connexion du même appareil a pris le relais | Deux appareils partagent un identifiant, ou un client se reconnecte sans fermer l’ancien socket. Donnez à chaque appareil son propre identifiant. |
auth_revoked | L’identifiant, l’appareil ou l’organisation n’est plus autorisé | Les sessions sont revérifiées environ toutes les 60 secondes ; un identifiant renouvelé met fin à l’ancienne session |
rate_limit | L’appareil a continuellement dépassé sa limite de débit (plus de trois fois son allocation par minute rejetée en une minute) | Regroupez les mesures, envoyez moins souvent, ou augmentez les limites du profil |
inflight_exceeded | Trop de messages QoS 1 non acquittés (20 par défaut) | Attendez les PUBACK avant d’en envoyer davantage |
server_shutdown | Un nœud du broker a redémarré | Reconnectez-vous ; rien à corriger |
uplink_window_expired | La fenêtre en ligne Recent message s’est terminée | Normal pour les appareils qui ne se connectent que pour envoyer |
protocol_error, socket_error | Le client a enfreint le protocole, ou le réseau a échoué | Mettez à jour le client ; vérifiez la liaison |
Un appareil dont la session est reprise à plusieurs reprises depuis deux réseaux est temporairement mis en attente, et vos administrateurs reçoivent une notification « takeover fight ».
Étape 4 : l’appareil se connecte, mais apparaît hors ligne
| Cause | Vérification |
|---|---|
| La règle de présence du profil | Live connection, Recent message ou Last seen only déterminent ce que signifie « en ligne ». Voir État de connexion et activité. |
| Quarantaine | Un appareil auto-enregistré placé en quarantaine se connecte, mais ses données sont acquittées puis ignorées jusqu’à leur activation par un administrateur. Voir Quarantaine. |
| L’appareil est un enfant de passerelle | Son état provient des messages v1/gw/connect et v1/gw/disconnect de la passerelle. Voir Appareils derrière une passerelle. |
Un appareil mal configuré bloque les autres
Des échecs de connexion répétés depuis une même adresse bloquent cette adresse pendant un court moment, pour chaque appareil derrière elle. Plusieurs appareils derrière un même NAT ou routeur mobile sont alors tous refusés avec CONNACK 3 (HTTP 429). Trouvez l’appareil aux identifiants erronés (son onglet Log affiche les échecs), corrigez-le, et laissez les autres réessayer avec temporisation.
Comportement recommandé de l’appareil
- Connectez-vous en TLS par nom d’hôte, avec un keepalive compris entre 30 et 300 secondes.
- Après CONNACK 0, abonnez-vous aux topics de descente, demandez les attributs partagés, publiez les attributs client, puis envoyez les mesures mises en mémoire tampon.
- En cas de refus, espacez les tentatives : réessayez CONNACK 3 avec une gigue aléatoire ; attendez au moins 5 minutes après CONNACK 4 ; cessez de réessayer CONNACK 1 et 2 tant que la configuration n’a pas changé.
Voir MQTT.