Grundlegendes und Beheben von Azure IoT Hub Fehlern

  • Artikel

In diesem Artikel werden die Ursachen und Lösungen für allgemeine Fehlercodes beschrieben, die beim Verwenden von IoT Hub auftreten können.

400027 Verbindung bei neuer Verbindung zwangsweise geschlossen

Möglicherweise wird der Fehler 400027 ConnectionForcefullyClosedOnNewConnection angezeigt, wenn Ihr Gerät die Verbindung beendet und Communication_Error als ConnectionStatusChangeReason mittels .NET-SDK- und MQTT-Transporttyp meldet. Ihr Gerät-zu-Cloud-Zwillingsvorgang (so wie gemeldete Eigenschaften lesen oder patchen) oder der direkte Methodenaufruf schlägt mit dem Fehlercode 400027 fehl.

Dieser Fehler tritt auf, wenn von einem anderen Client eine neue Verbindung mit IoT Hub unter Verwendung derselben Identität erstellt wurde, sodass IoT Hub die vorherige Verbindung geschlossen hat. IoT Hub lässt nicht zu, dass mehr als ein Client eine Verbindung mit derselben Identität herstellt.

Stellen Sie sicher, dass jeder Client eine Verbindung mit IoT Hub unter Verwendung seiner eigenen Identität herstellt.

401003 IoT Hub nicht autorisiert

In Protokollen wird ein Muster von Geräten angezeigt, bei denen gerade mit der Meldung 401003 IoTHubUnauthorized die Verbindung getrennt wird, gefolgt von 404104 DeviceConnectionClosedRemotely und kurz danach der erfolgreichen Herstellung einer Verbindung.

Oder Anforderungen an IoT Hub schlagen mit einer der folgenden Meldungen fehl:

  • Autorisierungsheader fehlt
  • IotHub '*' enthält nicht das angegebene Gerät. '*'
  • Die Autorisierungsregel '*' lässt keinen Zugriff für '*'zu.
  • Fehler bei der Authentifizierung für dieses Gerät, beim Erneuern von Token oder Zertifikat und beim erneuten Herstellen einer Verbindung
  • Der Fingerabdruck entspricht nicht der Konfiguration: Fingerabdruck: SHA1Hash=*, SHA2Hash=*; Konfiguration: PrimaryThumbprint=*, SecondaryThumbprint=*
  • Der Prinzipal user@example.com ist nicht für GET für /exampleOperation autorisiert, weil keine Berechtigungen zugewiesen wurden.

Bei MQTT verlassen sich einige SDKs darauf, dass IoT Hub beim Ablauf des SAS-Tokens eine Trennung der Verbindung auslöst, um zu wissen, wann es aktualisiert werden muss. Also:

  1. Das SAS-Token läuft ab.
  2. IoT Hub bemerkt den Ablauf und trennt die Geräteverbindung mit 401003 IoTHubUnauthorized.
  3. Das Gerät schließt die Trennung der Verbindung mit 404104 DeviceConnectionClosedRemotely ab.
  4. Das IoT SDK generiert ein neues SAS-Token.
  5. Das Gerät stellt die Verbindung mit IoT Hub erfolgreich wieder her.

Oder IoT Hub konnte den Autorisierungsheader, die Regel oder den Schlüssel nicht authentifizieren. Dies kann auf einen der in den Symptomen genannten Gründe zurückzuführen sein.

Um den Fehler zu beheben, ist keine Aktion nötig, wenn das IoT SDK für die Verbindung verwendet wird. Das IoT SDK generiert das neue Token erneut, um bei SAS-Tokenablauf die Verbindung wiederherzustellen.

Die standardmäßige Tokenlebensdauer beträgt 60 Minuten für SDKs. Bei einigen SDKs können die Tokenlebensdauer und der Schwellenwert für die Tokenerneuerung jedoch konfiguriert werden. Außerdem unterscheiden sich bei jedem SDK die Fehler, die generiert werden, wenn die Verbindung eines Geräts bei der Tokenerneuerung getrennt und wiederhergestellt wird. Weitere entsprechende Einzelheiten sowie Informationen dazu, wie Sie feststellen können, welches SDK das Gerät in Protokollen verwendet, finden Sie unter Verbindungstrennungsverhalten von MQTT-Geräten bei Azure IoT-SDKs.

Wenn die Fehlermenge für Geräteentwickler ein Problem darstellt, wechseln Sie zum C SDK, über das das SAS-Token vor dem Ablauf erneuert wird. Bei AMQP kann das SAS-Token ohne eine Trennung der Verbindung aktualisiert werden.

Im Allgemeinen sollte in der angezeigten Fehlermeldung erläutert werden, wie der Fehler behoben werden kann. Wenn Sie aus irgendeinem Grund auf die Details der Fehlermeldung nicht zugreifen können, stellen Sie Folgendes sicher:

  • Die SAS (Shared Access Signature) oder ein anderes verwendetes Sicherheitstoken ist nicht abgelaufen.
  • Bei der X.509-Zertifikatsauthentifizierung ist das mit dem Gerät verbundene Geräte- oder Zertifizierungsstellenzertifikat nicht abgelaufen. Erfahren Sie, wie Sie X.509-Zertifizierungsstellenzertifikate bei IoT Hub registrieren. Informationen dazu finden Sie unter Tutorial: Erstellen und Hochladen von Zertifikaten für Testzwecke.
  • Bei der X.509-Authentifizierung per Fingerabdruck wird der Fingerabdruck des Gerätezertifikats bei IoT Hub registriert.
  • Die Autorisierungsanmeldeinformationen sind für das verwendete Protokoll richtig formatiert. Weitere Informationen finden Sie unter Steuern des Zugriffs auf IoT Hub.
  • Die verwendete Autorisierungsregel verfügt über die Berechtigung für den angeforderten Vorgang.
  • Bei den letzten Fehlermeldungen, die mit „principal...“ beginnen, kann dieser Fehler behoben werden, indem dem Benutzer die richtige Azure RBAC-Berechtigungsstufe zugewiesen wird. Beispielsweise kann ein IoT-Hub-Besitzer die Rolle „IoT Hub-Datenbesitzer“ zuweisen, die sämtliche Berechtigungen gewährt. Versuchen Sie es mit dieser Rolle, um das Problem aufgrund fehlender Berechtigungen zu beheben.

Hinweis

Bei einigen Geräten tritt möglicherweise ein Problem mit Zeitabweichungen auf, wenn die Gerätezeit mehr als fünf Minuten von der Zeit des Servers abweicht. Dieser Fehler kann auftreten, wenn ein Gerät seit Wochen oder sogar Monaten eine Verbindung mit einem IoT-Hub problemlos hergestellt hat, dann aber beginnt, seine Verbindung kontinuierlich abzulehnen. Der Fehler kann auch spezifisch für eine Teilmenge der mit dem IoT-Hub verbundenen Geräte sein, da die Zeitabweichung – je nachdem, wann ein Gerät zum ersten Mal verbunden oder eingeschaltet wird, – unterschiedlich sein kann.

Oft wird das Problem durch Ausführen einer Uhrzeitsynchronisierung mithilfe von NTP oder durch Neustarten des Geräts (das eine Uhrzeitsynchronisierung während der Startsequenz automatisch durchführen kann) behoben, sodass das Gerät eine Verbindung erneut herstellen kann. Zur Vermeidung dieses Fehlers konfigurieren Sie das Gerät so, dass es mithilfe von NTP eine regelmäßige Uhrzeitsynchronisierung durchführt. Sie können die Synchronisierung für „täglich“, „wöchentlich“ oder „monatlich“ planen – je nachdem, wie groß die Zeitabweichung beim Gerät ist. Wenn Sie eine regelmäßige NTP-Synchronisierung auf Ihrem Gerät nicht konfigurieren können, planen Sie einen regelmäßigen Neustart.

403002 IoT Hub-Kontingent überschritten

Alle Anforderungen an IoT Hub schlagen mit der Meldung 403002 IoTHubQuotaExceeded fehl. Im Azure-Portal wird die Liste mit IoT-Hub-Geräten nicht geladen.

Dieser Fehler tritt typischerweise auf, wenn das tägliche Nachrichtenkontingent für den IoT-Hub überschritten wird. So beheben Sie diesen Fehler:

Dieser Fehler kann auch von einem Massenimportauftrag zurückgegeben werden, wenn die Anzahl der Geräte, die für Ihren IoT-Hub registriert sind, die Kontingentgrenze für einen IoT-Hub bald erreichen oder überschreiten. Weitere Informationen finden Sie unter Problembehandlung für Importjobs.

403004 Maximale Warteschlangentiefe des Geräts überschritten

Beim Versuch, eine Cloud-zu-Gerät-Nachricht zu senden, schlägt die Anforderung mit der Meldung 403004 oder DeviceMaximumQueueDepthExceeded fehl.

Die zugrunde liegende Ursache ist, dass die Anzahl von Nachrichten, die für das Gerät in die Warteschlange eingereiht wurden, das Warteschlangenlimit überschreitet.

Der wahrscheinlichste Grund für die Überschreitung dieses Grenzwerts: Sie verwenden HTTPS zum Empfangen der Nachricht. Dies führt zu kontinuierlichem Abrufen mithilfe von ReceiveAsync und letztlich dazu, dass die IoT Hub-Anforderung gedrosselt wird.

Das unterstützte Muster für C2D-Nachrichten mit HTTPS entspricht Geräten, die nicht permanent verbunden sind und weniger häufig Nachrichten abrufen (d.h. seltener als alle 25 Minuten). Um die Wahrscheinlichkeit zu verringern, dass das Warteschlangenlimit erreicht wird, wechseln Sie zu AMQP oder MQTT für C2D-Nachrichten.

Als Alternative erweitern Sie die Logik auf Geräteseite, damit Nachrichten in der Warteschlange schnell abgeschlossen, abgelehnt oder abgebrochen werden, verkürzen Sie die Gültigkeitsdauer, oder erwägen Sie, weniger Nachrichten zu senden. Weitere Informationen finden Sie unter Nachrichtenablauf (Gültigkeitsdauer).

Und schließlich: Überlegen Sie eine Verwendung der Purge Queue API (API zum endgültigen Löschen des Warteschlangeninhalts), damit ausstehende Nachrichten regelmäßig bereinigt werden, bevor das Limit erreicht wird.

403006 Maximales Limit für den aktiven Dateiupload des Geräts überschritten

Möglicherweise schlägt Ihre Anforderung zum Dateiupload mit dem Fehlercode 403006 DeviceMaximumActiveFileUploadLimitExceeded und der Meldung „Anzahl von aktiven Dateiupload-Anforderungen kann 10 nicht überschreiten“ fehl.

Dieser Fehler tritt auf, da jeder Geräte-Client für gleichzeitige Dateiuploads begrenzt ist. Sie können den Grenzwert leicht überschreiten, wenn Ihr Gerät IoT Hub nicht benachrichtigt, nachdem Dateiuploads abgeschlossen wurden. Dieses Problem wird häufig durch ein unzuverlässiges geräteseitiges Netzwerk verursacht.

Um diesen Fehler zu beheben, stellen Sie sicher, dass das Gerät IoT Hub Abschluss des Dateiuploads umgehend benachrichtigen kann. Versuchen Sie dann, die SAS-Token-TTL für die Dateiuploadkonfiguration zu verkürzen.

404001 Gerät nicht gefunden

Während einer Cloud-zu-Gerät-Kommunikation (C2D), so wie eine C2D-Nachricht, ein Zwillingsupdate oder eine direkte Methode, schlägt der Vorgang mit der Meldung 404001 DeviceNotFound fehl.

Der Vorgang ist fehlgeschlagen, weil IoT Hub das Gerät nicht finden kann. Das Gerät ist entweder nicht registriert oder deaktiviert.

Um diesen Fehler zu beheben, registrieren Sie die verwendete Geräte-ID, und versuchen Sie es erneut.

404103 Gerät nicht online

Eine direkte Methode auf einem Gerät schlägt mit der Meldung 404103 DeviceNotOnline selbst dann fehl, wenn das Gerät online ist.

Wenn Sie wissen, dass das Gerät online ist und die Fehlermeldung weiterhin angezeigt wird, liegt es wahrscheinlich daran, dass der Rückruf der direkten Methode auf dem Gerät nicht registriert ist.

Informationen zum ordnungsgemäßen Konfigurieren Ihres Geräts für Rückrufe der direkten Methode finden Sie unter Behandeln einer direkten Methode auf einem Gerät.

404104 Geräteverbindung von Remote geschlossen

Die Geräteverbindung wird in regelmäßigen Abständen (beispielsweise alle 65 Minuten) getrennt, und in den IoT Hub-Ressourcenprotokollen wird die Meldung 404104 DeviceConnectionClosedRemotely angezeigt. Manchmal wird auch 401003 IoTHubUnauthorized und weniger als eine Minute später ein Ereignis des Typs „Geräteverbindung erfolgreich“ angezeigt.

Die Geräteverbindung wird nach dem Zufallsprinzip getrennt und in den IoT Hub-Ressourcenprotokollen wird die Meldung 404104 DeviceConnectionClosedRemotely angezeigt.

Die Verbindung vieler Geräte wird auf einmal getrennt, die Metrik Verbundene Geräte (connectedDeviceCount) fällt ab und in den Azure Monitor-Protokollen treten mehr Meldungen des Typs 404104 DeviceConnectionClosedRemotely und interne 500xxx-Fehler als üblich auf.

Das zum Herstellen einer Verbindung mit IoT Hub verwendete SAS-Token ist abgelaufen, was dazu führt, dass IoT Hub die Verbindung mit dem Gerät trennt. Die Verbindung wird wiederhergestellt, wenn das Token vom Gerät aktualisiert wurde. Beispielsweise läuft das SAS-Token für C SDK standardmäßig stündlich ab. Das kann zu regulären Trennungen der Verbindung führen. Weitere Informationen finden Sie unter 401003 IoTHubUnauthorized.

Einige Möglichkeiten schließen ein:

  • Das Gerät hat die zugrunde liegende Netzwerkkonnektivität länger als das MQTT-Keep-Alive verloren, was zu einem Remote-Leerlauftimeout führte. Die Einstellung für das MQTT-Keep-Alive kann bei jedem Gerät unterschiedlich sein.
  • Das Gerät hat eine Zurücksetzung auf TCP/IP-Ebene gesendet, aber keine Anwendungsebene MQTT DISCONNECT. Im Wesentlichen hat das Gerät die zugrunde liegende Socketverbindung plötzlich geschlossen. Manchmal wird dieses Problem durch Fehler in älteren Versionen des Azure IoT SDKs verursacht.
  • Die geräteseitige Anwendung ist abgestürzt.

Bei IoT Hub ist möglicherweise ein vorübergehendes Problem aufgetreten. Weitere Informationen finden Sie unter IoT Hub interner Serverfehler.

So beheben Sie diesen Fehler:

  • Informationen zu Fehler 401003 IoTHubUnauthorized finden Sie in den Anweisungen.
  • Stellen Sie sicher, dass das Gerät über eine gute Konnektivität zum IoT Hub verfügt, indem Sie die Verbindung testen. Wenn das Netzwerk unzuverlässig oder zeitweilig ist, raten wir davon ab, den Keep-Alive-Wert zu erhöhen. Dies könnte nämlich dazu führen, dass die Erkennung (z. B. über Azure Monitor-Warnungen) länger dauert.
  • Verwenden Sie die neuesten Versionen der IoT SDKs.
  • Informationen zu IoT Hub internen Serverfehlern finden Sie in den Anleitungen.

Wir empfehlen die Verwendung von Azure IoT-Geräte-SDKs, um Verbindungen zuverlässig zu verwalten. Weitere Informationen finden Sie unter Verwalten von Konnektivität und zuverlässigem Messaging mithilfe von Azure IoT Hub-Geräte-SDKs.

409001 Gerät bereits vorhanden ist

Wenn Sie versuchen, ein Gerät in IoT Hub zu registrieren, schlägt die Anforderung mit der Meldung 409001 DeviceAlreadyExists fehl.

Der Fehler tritt auf, weil es im IoT-Hub bereits ein Gerät mit derselben Geräte-ID gibt.

Um diesen Fehler zu beheben, verwenden Sie eine andere Geräte-ID und versuchen Sie es erneut.

Der Fehler 409002 LinkCreationConflict wird in Protokollen zusammen mit einer Trennung von Geräteverbindungen oder einem Fehler bei Cloud-zu-Gerät-Nachrichten protokolliert.

Dieser Fehler tritt im Allgemeinen auf, wenn IoT Hub erkennt, dass es bei einem Client mehr als eine Verbindung gibt. Wenn eine neue Verbindungsanforderung für ein Gerät mit einer vorhandenen Verbindung eintrifft, schließt IoT Hub die vorhandene Verbindung mit dieser Fehlermeldung.

Im häufigsten Fall führt ein separates Problem (z. B. 404104 DeviceConnectionClosedRemotely) dazu, dass die Verbindung des Geräts getrennt wird. Das Gerät versucht, die Verbindung sofort wiederherzustellen, doch IoT Hub betrachtet das Gerät weiterhin als verbunden. IoT Hub schließt die vorherige Verbindung und protokolliert diesen Fehler.

Eine fehlerhafte geräteseitige Logik bewirkt, dass das Gerät die Verbindung herstellt, wenn eine Verbindung bereits geöffnet ist.

Um diesen Fehler zu beheben, suchen Sie nach anderen Fehlern in den Protokollen, die Sie beheben können, da dieser Fehler in der Regel als Nebeneffekt eines anderen, vorübergehenden Problems angezeigt wird. Erstellen Sie andernfalls nur dann eine neue Verbindungsanforderung, wenn die Verbindung unterbrochen wird.

412002 Gerätenachrichtensperre verloren

Beim Versuch, eine Cloud-zu-Gerät-Nachricht zu senden, schlägt die Anforderung mit der Meldung 412002DeviceMessageLockLost fehl.

Wenn ein Gerät eine Cloud-zu-Gerät-Nachricht aus der Warteschlange empfängt (zum Beispiel über ReceiveAsync()), wird die Nachricht von IoT Hub für eine Sperr-Timeout-Dauer von einer Minute gesperrt. Wenn das Gerät versucht, die Nachricht nach Ablauf des Sperrtimeouts abzuschließen, löst IoT Hub diese Ausnahme aus.

Wenn IoT Hub die Benachrichtigung nicht innerhalb der Sperrtimeoutdauer von einer Minute erhält, setzt es die Nachricht zurück auf den Status Enqueued (In die Warteschlange eingereiht). Das Gerät kann versuchen, die Nachricht erneut zu empfangen. Wenn Sie ein erneutes Auftreten dieses Fehlers in Zukunft verhindern möchten, implementieren Sie geräteseitige Logik, damit die Nachricht innerhalb von einer Minute nach dem Empfang abgeschlossen wird. Dieses Timeout von einer Minute Dauer kann nicht geändert werden.

429001 Drosselungsausnahme

Ihre Anforderungen an IoT Hub schlagen mit der Meldung 429001 ThrottlingException fehl.

Dieser Fehler tritt auf, wenn die IoT Hub-Drosselungslimits, die bei dem angeforderten Vorgang überschritten wurden.

Um diesen Fehler zu beheben, überprüfen Sie, ob Sie das Drosselungslimit erreichen, indem Sie Ihre Metrik der Versuche zum Senden von Telemetrienachrichten mit den oben angegebenen Limits vergleichen. Sie können auch die Metrik Anzahl von Drosselungsfehlern überprüfen. Weitere Informationen zu diesen Metriken finden Sie unter Gerätetelemetriemetriken. Informationen dazu, wie Sie mithilfe von Metriken Ihren IoT-Hub überwachen können, finden Sie unter Überwachen von IoT-Hub.

IoT Hub gibt „429 ThrottlingException“ nur zurück, nachdem das Limit während eines zu langen Zeitraums überschritten wurde. Dies geschieht, damit Ihre Nachrichten nicht gelöscht werden, wenn Ihr IoT Hub Burstdatenverkehr abruft. In der Zwischenzeit verarbeitet IoT Hub die Nachrichten mit der Drosselungsrate, die langsam sein kann, wenn zu viel Datenverkehr im Backlog vorhanden ist. Weitere Informationen finden Sie unter Traffic-Shaping.

Erwägen Sie, Ihre IoT Hub-Instanz zentral hochzuskalieren, wenn Sie die Kontingent- oder Drosselungslimits erreichen.

500xxx Interne Fehler

Möglicherweise schlägt Ihre Anforderung an IoT Hub mit einer Meldung fehl, die mit 500 und/oder einer Art von „Serverfehler“ beginnt. Einige Möglichkeiten sind:

  • 500001 ServerError: Bei IoT Hub ist ein serverseitiges Problem aufgetreten.

  • 500008 GenericTimeout: IoT Hub konnte die Verbindungsanforderung nicht vor dem Timeout abschließen.

  • ServiceUnavailable (kein Fehlercode): Bei IoT Hub ist ein interner Fehler aufgetreten.

  • InternalServerError (kein Fehlercode): Bei IoT Hub ist ein interner Fehler aufgetreten.

Es kann viele Ursachen für eine 500xxx-Fehlerantwort geben. In allen Fällen ist das Problem höchstwahrscheinlich vorübergehend. Obwohl das IoT Hub-Team daran arbeitet, die SLA zu verwalten, können kleine Teilmengen von IoT Hub-Knoten gelegentlich vorübergehende Fehler aufweisen. Wenn Ihr Gerät versucht, eine Verbindung zu einem Knoten herzustellen, der Probleme aufweist, erhalten Sie diese Fehlermeldung.

Geben Sie zum Beheben von 500xxx-Fehlern einen Wiederholungsversuch vom Gerät aus. Um Wiederholungsversuche automatisch zu verwalten, stellen Sie sicher, dass Sie die neueste Version des Azure IoT SDKs verwenden. Die Best Practices für die Behandlung vorübergehender Fehler und Wiederholungsversuche finden Sie unter Behandeln vorübergehender Fehler.

Wenn das Problem weiterhin besteht, überprüfen Sie Ressourcenintegrität und Azure-Status, um festzustellen, ob es bei IoT Hub ein bekanntes Problem gibt. Sie können auch das Feature für manuelles Failover verwenden.

Wenn keine bekannten Probleme vorliegen und das Problem fortbesteht, wenden Sie sich an den Support, um weitere Unterstützung zu erhalten.

503003 Partition nicht gefunden

Anforderungen an IoT Hub schlagen mit der Meldung 503003 PartitionNotFound fehl.

Dieser Fehler ist für IoT Hub intern und wahrscheinlich vorübergehend. Weitere Informationen finden Sie unter IoT Hub interner Serverfehler.

Informationen zum Beheben dieses Fehlers finden Sie unter IoT Hub interne Serverfehlern.

504101 Gateway-Timeout

Wenn Sie versuchen, eine direkte Methode von IoT Hub für ein Gerät aufzurufen, schlägt die Anforderung mit der Meldung 504101 GatewayTimeout fehl.

Dieser Fehler tritt auf, da IoT Hub einen Fehler aufweist und nicht bestätigen konnte, ob die direkte Methode vor dem Timeout abgeschlossen wurde. Oder wenn Sie eine frühere Version des Azure IoT C#SDK (<1.19.0) verwenden, kann der AMQP-Link zwischen dem Gerät und IoT Hub aufgrund eines Fehlers automatisch gelöscht werden.

Um diesen Fehler zu beheben, führen Sie eine Wiederholung oder Aktualisierung auf die neueste Version des Azure IOT C# SDK aus.