Comprendre et résoudre les erreurs Azure IoT Hub

Cet article décrit les causes et solutions des codes d’erreur courants que vous pouvez rencontrer lors de l’utilisation d’IoT Hub.

400027 Connexion fermée de force sur la nouvelle connexion

Vous pouvez voir l’erreur 400027 ConnectionForcefullyClosedOnNewConnection si votre appareil se déconnecte et signale Communication_Error en tant que ConnectionStatusChangeReason à l’aide du kit SDK .NET et du type de transport MQTT. Votre opération sur le jumeau appareil-à-cloud (par exemple, lecture ou correction de propriétés signalées) ou votre appel de méthode directe échouent avec le code d’erreur 400027.

Cette erreur se produit lorsqu’un autre client a créé une connexion à IoT Hub avec la même identité. IoT Hub a donc fermé la connexion précédente. IoT Hub ne permet pas à plusieurs clients de se connecter avec la même identité.

Pour résoudre cette erreur, assurez-vous que chaque client se connecte à l’IoT Hub à l’aide de sa propre identité.

401003 IoT Hub non autorisé

Dans les journaux, vous constatez que les appareils se déconnectent en générant l'erreur 401003 IoTHubUnauthorized, suivie de l'erreur 404104 DeviceConnectionClosedRemotely, avant de se connecter avec succès peu de temps après.

Ou bien, les demandes adressées à IoT Hub échouent en générant l’un des messages d’erreur suivants :

• En-tête d’autorisation manquant
• L’IotHub « * » ne contient pas l’appareil spécifié « * »
• La règle d’autorisation « * » n’autorise pas l’accès pour « * »
• L’authentification a échoué pour cet appareil. Renouvelez le jeton ou le certificat, puis recommencez la connexion
• L’empreinte numérique ne correspond pas à la configuration : Empreinte : SHA1Hash=*, SHA2Hash=*; Configuration: PrimaryThumbprint=*, SecondaryThumbprint=*
• Le principal user@example.com n’est pas autorisé pour GET sur/exampleOperation en raison de l’absence d’autorisations affectées

Cette erreur se produit car pour MQTT, certains kits de développement logiciel (SDK) s’appuient sur l’IoT Hub pour déclenchent la déconnexion quand le jeton SAP expire pour savoir quand l’actualiser. Ainsi,

1. le jeton SAP expire
2. L’IoT Hub constate l’expiration et déconnecte l’appareil en générant l’erreur 401003 IoTHubUnauthorized
3. L’appareil se déconnecte en générant l’erreur 404104 DeviceConnectionClosedRemotely
4. Le Kit de développement logiciel (SDK) IoT génère un nouveau jeton SAP
5. L’appareil se reconnecte correctement à l’IoT Hub

Ou bien, l’IoT Hub n’a pas pu authentifier l’en-tête, la règle ou la clé d’autorisation. Peuvent être en cause toutes les raisons citées dans les symptômes.

Pour résoudre cette erreur, aucune action n’est nécessaire si vous utilisez le Kit de développement logiciel (SDK) IoT pour la connexion à l’aide de la chaîne de connexion de l’appareil. Le Kit de développement logiciel (SDK) IoT régénère le nouveau jeton pour se reconnecter lors de l’expiration du jeton SAP.

La durée de vie par défaut des jetons est de 60 minutes dans tous les kits de développement logiciel. Toutefois, pour certains d’entre eux, la durée de vie du jeton et le seuil de renouvellement de celui-ci sont configurables. En outre, les erreurs générées quand un appareil se déconnecte et se reconnecte lors d’un renouvellement de jeton diffèrent pour chaque Kit de développement logiciel (SDK). Pour plus d’informations sur la façon de déterminer le Kit de développement logiciel (SDK) que votre appareil utilise dans les journaux, consultez Comportement de déconnexion d’appareil MQTT avec les kits de développement logiciel (SDK) Azure IoT.

Pour les développeurs d’appareils, si le volume des erreurs pose problème, basculez vers le Kit de développement logiciel (SDK) C qui renouvelle le jeton SAP avant expiration. Pour AMQP, le jeton SAP peut s’actualiser sans déconnexion.

En général, le message d’erreur présenté doit expliquer comment corriger l’erreur. Si, pour une raison quelconque, vous n’avez pas accès au détail du message d’erreur, assurez-vous que :

• Le jeton de signature d’accès partagé (SAP) ou un autre jeton de sécurité que vous utilisez ne sont pas arrivés à expiration.
• Pour l’authentification par certificat X.509, le certificat d’appareil ou le certificat d’autorité de certification associé à l’appareil n’est pas arrivé à expiration. Pour savoir comment inscrire des certificats d’autorité de certification X.509 avec IoT Hub, consultez le Tutoriel : Créer et charger des certificats à des fins de test.
• Pour l’authentification par empreinte de certificat X.509, l’empreinte numérique du certificat d’appareil est inscrite auprès de IoT Hub.
• Les informations d’identification d’autorisation sont bien formées pour le protocole que vous utilisez. Pour plus d’informations, consultez Contrôle de l’accès à IoT Hub.
• La règle d’autorisation utilisée a l’autorisation pour l’opération demandée.
• Pour les derniers messages d’erreur commençant par « Le principal... », cette erreur peut être résolue en affectant le niveau d’autorisation Azure RBAC approprié à l’utilisateur. Par exemple, un propriétaire sur IoT Hub peut attribuer le rôle « Propriétaire des données IoT Hub », qui accorde toutes les autorisations. Essayez ce rôle pour résoudre le problème d’autorisation insuffisante.

Notes

Certains appareils peuvent rencontrer un problème d’écart temporel lorsque l’heure de l’appareil présente une différence supérieure à cinq minutes par rapport à celle du serveur. Cette erreur peut se produire lorsqu’un appareil se connecte à un hub IoT sans problème depuis des semaines, voire des mois, mais que sa connexion se met à être refusée continuellement. L’erreur peut également être propre à un sous-ensemble d’appareils connectés au hub IoT, car l’écart temporel peut varier selon le moment où l’appareil a été connecté ou allumé pour la première fois.

Souvent, une synchronisation NTP ou un redémarrage de l’appareil (qui peut effectuer automatiquement une synchronisation pendant la séquence de démarrage) résolvent le problème et permettent à l’appareil de se reconnecter. Pour éviter cette erreur, configurez l’appareil de manière à effectuer une synchronisation périodique à l’aide de NTP. Vous pouvez planifier une synchronisation quotidienne, hebdomadaire ou mensuelle en fonction de l’écart que connaît l’appareil. Si vous ne pouvez pas configurer une synchronisation NTP périodique sur votre appareil, planifiez un redémarrage périodique.

403002 IoT Hub quota dépassé

Vous pouvez voir les demandes que vous adressez à IoT Hub échouent avec l’erreur 403002 IoTHubQuotaExceeded. La liste d’appareils du hub IoT ne se charge pas dans le Portail Azure.

Cette erreur se produit généralement lorsque le quota de messages quotidien pour IoT hub est dépassé. Pour corriger cette erreur :

• Mettez à niveau ou augmentez le nombre d’unités sur le hub IoT ou attendez le jour UTC suivant que le quota quotidien soit actualisé.
• Pour comprendre la façon dont les opérations sont comptabilisées dans le quota, telles que les requêtes de jumeaux et les méthodes directes, consultez Comprendre la tarification d’IoT Hub.
• Pour configurer la surveillance de l’utilisation quotidienne du quota, configurez une alerte avec la métrique Nombre total de messages utilisés. Pour obtenir des instructions pas à pas, consultez Configurer des métriques et des alertes avec IoT Hub.

Cette erreur peut également être retournée par un travail d’importation en bloc lorsque le nombre d’appareils inscrits auprès de votre hub IoT approche ou dépasse la limite de quota pour le hub IoT. Pour en savoir plus, consultez Résolution des problèmes des travaux d'importation.

403004 Profondeur maximale de file d’attente du périphérique dépassée

Lorsque vous essayez d’envoyer un message cloud-à-appareil, vous pouvez voir que la demande échoue avec l’erreur 403004 ou DeviceMaximumQueueDepthExceeded.

La cause sous-jacente de cette erreur est que le nombre de messages mis en file d’attente pour l’appareil dépasse la limite de file d’attente.

La raison la plus probable pour laquelle vous atteignez cette limite est que vous utilisez le protocole HTTPs pour recevoir le message, ce qui entraîne une interrogation continue à l’aide de ReceiveAsync qui a pour effet qu’IoT Hub limite la demande.

Le modèle de prise en charge des messages cloud-à-appareil avec HTTPS est représenté par des appareils connectés par intermittence qui vérifient rarement les messages (moins de toutes les 25 minutes). Afin de réduire la probabilité d’atteindre la limite de file d’attente, basculez vers AMQP ou MQTT pour les messages cloud-à-appareil.

Vous pouvez également améliorer la logique côté appareil afin de traiter (compléter, rejeter ou abandonner) rapidement les messages en file d’attente, raccourcir leur durée de vie ou envisager d’envoyer moins de messages. Voir Durée de vie du message C2D.

Enfin, songez à utiliser l’API de purge de la file d’attente pour nettoyer périodiquement les messages en attente avant que la limite soit atteinte.

403006 Limite maximale de téléchargement de fichiers actifs de l’appareil dépassée

Vous pouvez voir que votre demande de chargement de fichier échoue en générant le code d’erreur 403006 DeviceMaximumActiveFileUploadLimitExceeded et le message « Le nombre de demandes de chargement de fichier actives ne peut pas être supérieur à 10 ».

Cette erreur se produit car chaque client d’appareil est limité pour les chargements de fichiers simultanés. Vous pouvez facilement dépasser la limite si votre appareil ne signale pas à IoT Hub l’achèvement des chargements de fichiers. Ce problème est généralement dû à un réseau non fiable côté appareil.

Pour résoudre cette erreur, assurez-vous que l’appareil peut avertir rapidement un achèvement du chargement du fichier IoT Hub. Ensuite, essayez de réduire la durée de vie du jeton SAP pour la configuration du chargement de fichiers.

404001 Appareil introuvable

Au cours d’une communication cloud-à-appareil (C2D) telle qu’un message C2D, une mise à jour de jumeau ou une méthode directe, vous pouvez voir que l’opération échoue en générant l’erreur 404001 DeviceNotFound.

L’opération a échoué, car IoT Hub ne trouve pas l’appareil. L’appareil n’est pas inscrit ou est désactivé.

Pour résoudre cette erreur, inscrivez l’ID d’appareil que vous avez utilisé, puis réessayez.

404103 Appareil n’est pas en ligne

Vous pouvez voir qu’une méthode directe d’accès à un appareil échoue en générant l’erreur 404103 DeviceNotOnline, même si l’appareil est en ligne.

Si vous savez que l’appareil est en ligne et continuez à recevoir l’erreur, l’erreur se produit probablement du fait que le rappel de méthode directe n’est pas inscrit sur l’appareil.

Pour configurer correctement votre appareil pour les rappels de méthode directe, voir Gérer une méthode directe sur un appareil.

404104 Connexion de l’appareil fermée à distance

Vous pouvez voir que les appareils se déconnectent à intervalles réguliers (toutes les 65 minutes, par exemple) et 404104 DeviceConnectionClosedRemotely apparaît dans les journaux de ressources IoT Hub. Parfois, 401003 IoTHubUnauthorized s'affiche, de même qu'un événement de connexion d'appareil réussie moins d'une minute plus tard.

Ou bien, les appareils se déconnectent de façon aléatoire et 404104 DeviceConnectionClosedRemotely apparaît dans les journaux de ressources IoT Hub.

Ou bien, de nombreux appareils se déconnectent en même temps et vous constatez une baisse au niveau des métriques des appareils connectés (connectedDeviceCount). De plus, les journaux Azure Monitor présentent un plus grand nombre d'erreurs 404104 DeviceConnectionClosedRemotely et d'erreurs internes 500xxx.

Cette erreur peut se produire car le jeton SAS utilisé pour se connecter à IoT Hub a expiré et dès lors, IoT Hub déconnecte l’appareil. La connexion est rétablie une fois le jeton actualisé par l’appareil. Par exemple, le jeton SAS expire toutes les heures par défaut pour le kit de développement logiciel (SDK) C, ce qui peut entraîner des déconnexions régulières. Pour plus d’informations, consultez 401003 IoTHubUnauthorized.

Voici quelques autres possibilités :

• L’appareil a perdu la connectivité réseau sous-jacente plus longtemps que MQTT keep-alive, ce qui se traduit par un délai d’inactivité distant. Le paramètre MQTT keep-alive peut être différent selon l’appareil.
• L’appareil a envoyé une réinitialisation au niveau TCP/IP, mais pas au niveau de l'application MQTT DISCONNECT. En fait, l’appareil a brusquement interrompu la connexion socket sous-jacente. Ce problème relève parfois de bogues dans les versions antérieures du kit de développement logiciel (SDK) Azure IoT.
• L'application côté appareil s'est bloquée.

Ou bien, IoT Hub peut rencontrer un problème temporaire. Consultez Erreur de serveur interne à IoT Hub.

Pour corriger cette erreur :

• Consultez les conseils relatifs aux erreurs 401003 IoTHubUnauthorized.
• Assurez-vous que l’appareil dispose d'une bonne connectivité à IoT Hub en testant la connexion. Si le réseau n’est pas fiable ou intermittent, nous vous déconseillons d'augmenter la valeur keep-alive car cela pourrait entraîner une détection plus longue (via les alertes Azure Monitor, par exemple).
• Utiliser les dernières versions des kits de développement logiciel (SDK) IoT.
• Consultez les conseils pour Erreurs de serveur interne IoT Hub.

Nous vous recommandons d’utiliser les kits Azure IoT device SDK pour gérer les connexions de manière fiable. Pour plus d'informations, consultez Gérer la connectivité et la messagerie fiable à l’aide des kits de développement logiciel (SDK) d’appareil Azure IoT Hub

409001 Appareil existe déjà

Lorsque vous tentez d'inscrire un appareil dans IoT Hub, vous pouvez voir que la requête échoue et vous recevez l'erreur 409001 DeviceAlreadyExists.

Cette erreur se produit car un autre appareil possède déjà la même identité dans IoT Hub.

Pour résoudre cette erreur, utilisez un ID d’appareil différent et réessayez.

409002 conflit de création de lien

L'erreur 409002 LinkCreationConflict peut apparaître dans les journaux, avec la déconnexion de l'appareil ou l'échec de message cloud-à-appareil.

En règle générale, cette erreur se produit quand IoT Hub détecte qu’un client a plusieurs connexions. En fait, quand une nouvelle demande de connexion arrive pour un appareil avec une connexion existante, IoT Hub ferme la connexion existante en générant cette erreur.

Le plus souvent, un problème distinct (par exemple, 404104 DeviceConnectionClosedRemotely) entraîne la déconnexion de l’appareil. L’appareil tente de rétablir la connexion immédiatement, mais IoT Hub continue de considérer que l’appareil est connecté. IoT Hub ferme la connexion précédente et journalise cette erreur.

Ou bien, une logique erronée côté appareil force celui-ci à établir la connexion quand une connexion est déjà ouverte.

Pour résoudre cette erreur, recherchez d’autres erreurs dans les journaux que vous pouvez résoudre, car cette erreur apparaît généralement comme un effet secondaire d’un problème temporaire différent. Sinon, veillez à émettre une nouvelle demande de connexion uniquement en cas d’abandon de la connexion précédente.

412002 Verrouillage des messages de l’appareil perdu

Lorsque vous essayez d’envoyer un message cloud-à-appareil, vous pouvez voir que la demande échoue avec l’erreur 412002 DeviceMessageLockLost.

Cette erreur se produit lorsqu’un appareil reçoit un message cloud vers appareil à partir de la file d’attente (par exemple, à l’aide de ReceiveAsync()), le message est verrouillé par IoT Hub pendant une minute. Si l’appareil tente de compléter le message au terme de ce délai de verrouillage, IoT Hub lève l'exception.

Si IoT Hub n’obtient pas la notification durant le délai de verrouillage d'une minute, il rétablit l’état du message sur En file d'attente. L’appareil peut tenter de recevoir à nouveau le message. Pour éviter que l’erreur ne se reproduise, implémentez la logique côté appareil afin de compléter le message dans un délai d’une minute après réception. Ce délai d’attente d’une minute ne peut pas être modifié.

429001 Exception de limitation

Vous pouvez voir que les demandes que vous adressez à IoT Hub échouent avec l’erreur 429001 ThrottlingException.

Cette erreur se produit lorsque les limites de limitation IoT Hub ont été dépassées pour l’opération demandée.

Pour résoudre cette erreur, vérifiez si vous avez atteint la limite de limitation en comparant votre métrique de tentatives d’envoi de messages de télémétrie aux limites spécifiées plus haut. Vous pouvez également vérifier la métrique Nombre d’erreurs de limitation. Pour plus d’informations sur ces métriques, consultez Métriques de télémétrie d’appareil. Pour plus d’informations sur l’utilisation des métriques pour vous aider à surveiller votre IoT Hub, consultez Surveiller IoT Hub.

IoT Hub ne retourne l’erreur 429 ThrottlingException qu’après que la limite a été violée pendant un laps de temps trop long. Cela a pour but de ne pas supprimer vos messages si votre IoT Hub reçoit du trafic en rafales. Dans le même temps, IoT Hub traite les messages en fonction du taux de limitation de l’opération, qui peut être lent en cas de trafic intense dans le backlog. Pour plus d’informations, voir Régulation de flux IoT Hub.

Si vous rencontrez des limites de quota ou de limitation, envisagez d’augmenter la taille des instances de votre IoT Hub.

500xxx Erreurs internes

Vous pouvez voir que votre demande adressée à IoT Hub échoue en générant une erreur commençant par 500 et/ou une sorte d’« erreur de serveur ». Voici quelques possibilités :

• 500001 ServerError : IoT Hub a rencontré un problème côté serveur.

• 500008 GenericTimeout : IoT Hub n’est pas parvenu à effectuer la demande de connexion avant l’expiration du délai de connexion.

• ServiceUnavailable (aucun code d’erreur)  : IOT Hub a rencontré une erreur interne.

• InternalServerError (aucun code d’erreur) : IOT Hub a rencontré une erreur interne.

Les causes d’une réponse d’erreur 500xxx peuvent être multiples. Dans tous les cas, le problème est très probablement temporaire. Bien que l’équipe IoT Hub s’efforce continuellement de respecter les termes du Contrat de niveau de service (SLA), de petits sous-ensembles de nœuds IoT Hub rencontrent parfois des erreurs temporaires. Lorsque votre appareil tente de se connecter à un nœud présentant un problème, vous recevez cette erreur.

Pour atténuer les erreurs 500xxx, effectuez une nouvelle tentative à partir de l’appareil. Pour gérer automatiquement les nouvelles tentatives, vérifiez que vous utilisez la dernière version des Kits de développement logiciel (SDK) Azure IoT. Pour connaître les meilleures pratiques en matière de gestion des erreurs temporaires et de nouvelles tentatives, consultez l’article Gestion des erreurs temporaires.

Si le problème persiste, voir le service Resource Health et la page des états d’Azure pour déterminer si IoT Hub rencontre un problème connu. Vous pouvez également utiliser la fonctionnalité de basculement manuel.

S’il n’existe aucun problème connu et que le problème persiste, contactez le support pour un examen approfondi.

503003 partition introuvable

Vous pouvez voir que les demandes adressées à IoT Hub échouent en générant l’erreur 503003 PartitionNotFound.

Cette erreur est interne à IoT Hub et probablement temporaire. Consultez Erreurs de serveur interne à IoT Hub.

Pour résoudre cette erreur, consultez Erreurs de serveur interne IoT Hub.

504101 Délai d’expiration de la passerelle

Lorsque vous tentez d’appeler une méthode directe à partir de l’IoT Hub sur un appareil, vous pouvez voir que la demande échoue en générant l’erreur 504101 GatewayTimeout.

Cette erreur se produit car IoT Hub a rencontré une erreur et n’a pas pu confirmer si la méthode directe s’est terminée avant l’expiration du délai d’attente. Ou, lors de l’utilisation d’une version antérieure du SDK C# Azure IoT (<1.19.0), le lien AMQP entre l’appareil et IoT Hub peut être supprimé en mode silencieux en raison d’un bogue.

Pour résoudre cette erreur, émettez une nouvelle tentative ou une mise à niveau vers la dernière version du Kit SDK C# Azure IOT.