Azure IoT Hub-fouten begrijpen en oplossen

Artikel
02/02/2024

In dit artikel worden de oorzaken en oplossingen beschreven voor veelvoorkomende foutcodes die u kunt tegenkomen tijdens het gebruik van IoT Hub.

400027 Verbinding maken wordt geforceerd gesloten op een nieuwe verbinding

Mogelijk ziet u de fout 400027 Verbinding maken ionForcefullyClosedOnNew Verbinding maken ion als de verbinding met uw apparaat wordt verbroken en Communication_Error rapporteert als de Verbinding maken ionStatusChangeReason met behulp van .NET SDK en MQTT-transporttype. Of uw apparaat-naar-clouddubbelbewerking (zoals gerapporteerde eigenschappen voor lezen of patchen) of directe methode-aanroepen mislukt met de foutcode 400027.

Deze fout treedt op wanneer een andere client een nieuwe verbinding met IoT Hub maakt met dezelfde identiteit, zodat IoT Hub de vorige verbinding sluit. Met IoT-hub kunnen niet meer dan één client verbinding maken met dezelfde identiteit.

U kunt deze fout oplossen door ervoor te zorgen dat elke client verbinding maakt met IoT Hub met behulp van een eigen identiteit.

401003 IoT Hub niet geautoriseerd

In logboeken ziet u mogelijk een patroon van apparaten die de verbinding verbreken met 401003 IoTHubUnauthorized, gevolgd door 404104 Device Verbinding maken ionClosedRemotely en vervolgens kort daarna verbinding maken.

Of aanvragen voor IoT Hub mislukken met een van de volgende foutberichten:

Autorisatieheader ontbreekt
IotHub '*' bevat niet het opgegeven apparaat '*'
Autorisatieregel *staat geen toegang toe voor *
Verificatie is mislukt voor dit apparaat, token of certificaat vernieuwen en opnieuw verbinding maken
Vingerafdruk komt niet overeen met de configuratie: Vingerafdruk: SHA1Hash=*, SHA2Hash=*; Configuratie: PrimaryThumbprint=*, SecondaryThumbprint=*
Principal user@example.com is niet geautoriseerd voor GET on /exampleOperation vanwege geen toegewezen machtigingen

Deze fout treedt op omdat sommige SDK's voor MQTT afhankelijk zijn van IoT Hub om de verbinding te verbreken wanneer het SAS-token verloopt om te weten wanneer het moet worden vernieuwd. Dus

Het SAS-token verloopt
IoT Hub merkt dat het apparaat verloopt en verbreekt de verbinding met 401003 IoTHubUnauthorized
Het apparaat voltooit de verbinding met 404104 Device Verbinding maken ionClosedRemotely
De IoT SDK genereert een nieuw SAS-token
Het apparaat wordt opnieuw verbonden met IoT Hub

Of IoT Hub kan de verificatieheader, regel of sleutel niet verifiëren. Dit kan worden veroorzaakt door een van de redenen die worden genoemd in de symptomen.

Om deze fout op te lossen, is er geen actie nodig als u IoT SDK gebruikt voor verbinding met behulp van het apparaat verbindingsreeks. Met IoT SDK wordt het nieuwe token opnieuw gegenereerd om opnieuw verbinding te maken bij het verlopen van het SAS-token.

De standaard levensduur van tokens is 60 minuten tussen SDK's; Voor sommige SDK's is de levensduur van het token en de drempelwaarde voor tokenvernieuwing echter configureerbaar. Bovendien verschillen de fouten die worden gegenereerd wanneer een apparaat de verbinding verbreekt en opnieuw verbinding maakt bij het vernieuwen van tokens voor elke SDK. Zie het gedrag van de verbinding met MQTT-apparaten met Azure IoT SDK's voor meer informatie over hoe u kunt bepalen welke SDK uw apparaat gebruikt in logboeken.

Als het aantal fouten voor apparaatontwikkelaars een probleem is, schakelt u over naar de C SDK, waarmee het SAS-token vóór de vervaldatum wordt vernieuwd. Voor AMQP kan het SAS-token worden vernieuwd zonder de verbinding te verbreken.

Over het algemeen moet het weergegeven foutbericht uitleggen hoe u de fout kunt oplossen. Als u om een of andere reden geen toegang hebt tot de details van het foutbericht, controleert u het volgende:

Het SAS- of andere beveiligingstoken dat u gebruikt, is niet verlopen.
Voor X.509-certificaatverificatie is het apparaatcertificaat of het CA-certificaat dat is gekoppeld aan het apparaat niet verlopen. Voor meer informatie over het registreren van X.509-CA-certificaten bij IoT Hub, raadpleegt u Zelfstudie: Certificaten maken en uploaden voor testen.
Voor verificatie van vingerafdruk van X.509-certificaat wordt de vingerafdruk van het apparaatcertificaat geregistreerd bij IoT Hub.
De autorisatiereferentie is goed opgemaakt voor het protocol dat u gebruikt. Zie Toegang tot IoT Hub beheren voor meer informatie.
De gebruikte autorisatieregel heeft de machtiging voor de aangevraagde bewerking.
Voor de laatste foutberichten die beginnen met 'principal...', kan deze fout worden opgelost door het juiste niveau van de Azure RBAC-machtiging aan de gebruiker toe te wijzen. Een eigenaar van de IoT Hub kan bijvoorbeeld de rol 'IoT Hub-gegevenseigenaar' toewijzen, die alle machtigingen verleent. Probeer deze rol om het gebrek aan machtigingen op te lossen.

Notitie

Sommige apparaten ondervinden mogelijk een probleem met tijdsdrift wanneer de tijd van het apparaat een verschil van meer dan vijf minuten heeft ten opzichte van de server. Deze fout kan optreden wanneer een apparaat verbinding heeft gemaakt met een IoT-hub zonder problemen gedurende weken of zelfs maanden, maar de verbinding vervolgens voortdurend wordt geweigerd. De fout kan ook specifiek zijn voor een subset van apparaten die zijn verbonden met de IoT-hub, omdat de tijdsdrift kan optreden met verschillende tarieven, afhankelijk van wanneer een apparaat voor het eerst is verbonden of ingeschakeld.

Vaak lost het uitvoeren van een tijdsynchronisatie met behulp van NTP of het opnieuw opstarten van het apparaat (waardoor automatisch een tijdsynchronisatie wordt uitgevoerd tijdens de opstartvolgorde) het probleem op en kan het apparaat opnieuw verbinding maken. Om deze fout te voorkomen, configureert u het apparaat om een periodieke tijdsynchronisatie uit te voeren met NTP. U kunt de synchronisatie plannen voor dagelijks, wekelijks of maandelijks, afhankelijk van de hoeveelheid drift van het apparaat. Als u geen periodieke NTP-synchronisatie op uw apparaat kunt configureren, plant u een periodiek opnieuw opstarten.

403002 IoT Hub-quotum is overschreden

Mogelijk ziet u dat aanvragen voor IoT Hub mislukken met de fout 403002 IoTHubQuotaExceeded. En in Azure Portal wordt de lijst met IoT Hub-apparaten niet geladen.

Deze fout treedt meestal op wanneer het dagelijkse berichtquotum voor de IoT-hub wordt overschreden. Los deze fout als volgt op:

Werk het aantal eenheden op de IoT-hub bij of verhoog het aantal eenheden of wacht de volgende UTC-dag totdat het dagelijkse quotum is vernieuwd.
Zie Prijzen van IoT Hub begrijpen om te begrijpen hoe bewerkingen worden geteld voor het quotum, zoals dubbelquery's en directe methoden.
Als u bewaking wilt instellen voor dagelijks quotumgebruik, stelt u een waarschuwing in met het metrische totaal aantal gebruikte berichten. Zie Metrische gegevens en waarschuwingen instellen met IoT Hub voor stapsgewijze instructies.

Deze fout kan ook worden geretourneerd door een bulkimporttaak wanneer het aantal apparaten dat is geregistreerd bij uw IoT-hub nadert of de quotumlimiet voor een IoT-hub overschrijdt. Zie Problemen met importtaken oplossen voor meer informatie.

403004 maximale wachtrijdiepte van apparaat overschreden

Wanneer u een cloud-naar-apparaat-bericht probeert te verzenden, ziet u mogelijk dat de aanvraag mislukt met de fout 403004 of DeviceMaximumQueueDepthExceeded.

De onderliggende oorzaak van deze fout is dat het aantal berichten dat voor het apparaat wordt verzonden, de wachtrijlimiet overschrijdt.

De meest waarschijnlijke reden dat u deze limiet ondervindt, is omdat u HTTPS gebruikt om het bericht te ontvangen, wat leidt tot continue polling met behulp van ReceiveAsyncioT Hub, wat resulteert in het beperken van de aanvraag.

Het ondersteunde patroon voor cloud-naar-apparaat-berichten met HTTPS is onregelmatig verbonden apparaten die regelmatig controleren op berichten (minder dan elke 25 minuten). Als u de kans wilt verkleinen dat de wachtrijlimiet wordt bereikt, schakelt u over naar AMQP of MQTT voor cloud-naar-apparaat-berichten.

U kunt ook de logica aan de apparaatzijde verbeteren om berichten in de wachtrij snel te voltooien, af te wijzen of af te laten, de tijd tot live verkorten of het verzenden van minder berichten overwegen. Zie C2D message time to Live (TTL van C2D-bericht) voor meer informatie.

Ten slotte kunt u overwegen om de Wachtrij-API leegmaken te gebruiken om berichten die in behandeling zijn periodiek op te schonen voordat de limiet is bereikt.

403006 maximale limiet voor het uploaden van actieve bestanden van het apparaat is overschreden

Mogelijk ziet u dat uw aanvraag voor het uploaden van bestanden mislukt met de foutcode 403006 DeviceMaximumActiveFileUploadLimitExceeded en een bericht 'Aantal actieve uploadaanvragen voor bestanden mag niet groter zijn dan 10'.

Deze fout treedt op omdat elke apparaatclient beperkt is voor gelijktijdige bestandsuploads. U kunt de limiet eenvoudig overschrijden als uw apparaat ioT Hub niet informeert wanneer het uploaden van bestanden is voltooid. Dit probleem wordt meestal veroorzaakt door een onbetrouwbaar netwerk aan de apparaatzijde.

U kunt deze fout oplossen door ervoor te zorgen dat het apparaat onmiddellijk de voltooiing van het uploaden van IoT Hub-bestanden kan melden. Probeer vervolgens de TTL van het SAS-token te verminderen voor het uploaden van bestanden.

404001 apparaat is niet gevonden

Tijdens een C2D-communicatie (cloud-to-device), zoals C2D-bericht, dubbelupdate of directe methode, ziet u mogelijk dat de bewerking mislukt met de fout 404001 DeviceNotFound.

De bewerking is mislukt omdat ioT Hub het apparaat niet kan vinden. Het apparaat is niet geregistreerd of is uitgeschakeld.

Als u deze fout wilt oplossen, registreert u de apparaat-id die u hebt gebruikt en probeert u het opnieuw.

404103 Apparaat niet online

Mogelijk ziet u dat een directe methode voor een apparaat mislukt met de fout 404103 DeviceNotOnline , zelfs als het apparaat online is.

Als u weet dat het apparaat online is en nog steeds de fout krijgt, is de fout waarschijnlijk opgetreden omdat de callback van de directe methode niet is geregistreerd op het apparaat.

Zie Een directe methode op een apparaat afhandelen om uw apparaat correct te configureren voor callbacks van directe methoden.

404104 Apparaatverbinding op afstand gesloten

Mogelijk ziet u dat apparaten met een regelmatig interval (bijvoorbeeld elke 65 minuten) loskoppelen en u ziet 404104 Device Verbinding maken ionClosedRemotely in IoT Hub-resourcelogboeken. Soms ziet u ook 401003 IoTHubUnauthorized en een geslaagde apparaatverbindingsgebeurtenis minder dan een minuut later.

Of apparaten worden willekeurig losgekoppeld en u ziet 404104 Device Verbinding maken ionClosedRemotely in ioT Hub-resourcelogboeken.

Of veel apparaten verbreken tegelijk, u ziet een dip in de metrische gegevens Verbinding maken ed devices (connectedDeviceCount) en er zijn meer 404104 Device Verbinding maken ionClosedRemotely- en 500xxx Interne fouten in Azure Monitor-logboeken dan normaal.

Deze fout kan optreden omdat het SAS-token dat wordt gebruikt om verbinding te maken met IoT Hub is verlopen, waardoor ioT Hub de verbinding met het apparaat verbreekt. De verbinding wordt opnieuw tot stand gebracht wanneer het token wordt vernieuwd door het apparaat. Het SAS-token verloopt bijvoorbeeld standaard elk uur voor C SDK, wat kan leiden tot regelmatige verbroken verbindingen. Zie 401003 IoTHubUnauthorized voor meer informatie.

Enkele andere mogelijkheden zijn:

Het apparaat heeft de onderliggende netwerkverbinding langer verloren dan de MQTT-keep-alive, wat resulteert in een time-out voor externe inactiviteit. De MQTT-keep-alive-instelling kan per apparaat verschillen.
Het apparaat heeft een reset op TCP/IP-niveau verzonden, maar heeft geen toepassingsniveau verzonden MQTT DISCONNECT. In principe heeft het apparaat de onderliggende socketverbinding plotseling gesloten. Soms wordt dit probleem veroorzaakt door fouten in oudere versies van de Azure IoT SDK.
De toepassing aan de apparaatzijde is vastgelopen.

Of IoT Hub ondervindt mogelijk een tijdelijk probleem. Zie de interne serverfout van IoT Hub.

Los deze fout als volgt op:

Zie de richtlijnen voor fout 401003 IoTHubUnauthorized.
Zorg ervoor dat het apparaat een goede verbinding met IoT Hub heeft door de verbinding te testen. Als het netwerk onbetrouwbaar of onregelmatig is, raden we u niet aan om de keep alive-waarde te verhogen, omdat dit kan leiden tot detectie (bijvoorbeeld via Azure Monitor-waarschuwingen).
Gebruik de nieuwste versies van de IoT SDK's.
Zie de richtlijnen voor interne IoT Hub-serverfouten.

We raden aan Azure IoT Device SDK's te gebruiken om verbindingen betrouwbaar te beheren. Bekijk Connectiviteit en betrouwbare berichten beheren met behulp van Azure IoT Hub Device SDK's voor meer informatie

409001 apparaat bestaat al

Wanneer u een apparaat probeert te registreren in IoT Hub, ziet u mogelijk dat de aanvraag mislukt met de fout 409001 DeviceAlreadyExists.

Deze fout treedt op omdat er al een apparaat is met dezelfde apparaat-id in de IoT-hub.

Als u deze fout wilt oplossen, gebruikt u een andere apparaat-id en probeert u het opnieuw.

409002 koppeling maken conflict

Mogelijk ziet u de fout 409002 LinkCreationConflict in logboeken, samen met de verbroken verbinding van het apparaat of de fout in het cloud-naar-apparaatbericht.

Over het algemeen treedt deze fout op wanneer IoT Hub detecteert dat een client meer dan één verbinding heeft. Wanneer een nieuwe verbindingsaanvraag binnenkomt voor een apparaat met een bestaande verbinding, sluit IoT Hub de bestaande verbinding met deze fout.

In het meest voorkomende geval zorgt een afzonderlijk probleem (zoals 404104 Device Verbinding maken ionClosedRemotely) ervoor dat de verbinding van het apparaat wordt verbroken. Het apparaat probeert de verbinding onmiddellijk opnieuw tot stand te brengen, maar IoT Hub beschouwt het verbonden apparaat nog steeds. IoT Hub sluit de vorige verbinding en registreert deze fout.

Of de foutieve logica aan de apparaatzijde zorgt ervoor dat het apparaat de verbinding tot stand brengt wanneer het apparaat al is geopend.

Als u deze fout wilt oplossen, zoekt u naar andere fouten in de logboeken die u kunt oplossen, omdat deze fout meestal wordt weergegeven als een neveneffect van een ander, tijdelijk probleem. Zorg er anders voor dat u alleen een nieuwe verbindingsaanvraag verzendt als de verbinding wordt afgetreden.

412002 Apparaatberichtvergrendeling is verloren gegaan

Wanneer u een cloud-naar-apparaat-bericht probeert te verzenden, ziet u mogelijk dat de aanvraag mislukt met de fout 412002 DeviceMessageLockLost.

Deze fout treedt op omdat wanneer een apparaat een cloud-naar-apparaat-bericht uit de wachtrij ontvangt (bijvoorbeeld met behulp van ReceiveAsync()) het bericht is vergrendeld door IoT Hub voor een time-outduur van één minuut. Als het apparaat het bericht probeert te voltooien nadat de time-out voor de vergrendeling is verlopen, genereert IoT Hub deze uitzondering.

Als IoT Hub de melding niet binnen de time-outduur van vergrendeling van één minuut ontvangt, wordt het bericht teruggezet op de status Enqueued . Het apparaat kan proberen het bericht opnieuw te ontvangen. Als u wilt voorkomen dat de fout zich in de toekomst voordoet, implementeert u logica aan de apparaatzijde om het bericht binnen één minuut na ontvangst van het bericht te voltooien. Deze time-out van één minuut kan niet worden gewijzigd.

uitzondering voor beperking 429001

Mogelijk ziet u dat uw aanvragen voor IoT Hub mislukken met de fout 429001 ThrottlingException.

Deze fout treedt op wanneer de beperkingslimieten voor IoT Hub zijn overschreden voor de aangevraagde bewerking.

Als u deze fout wilt oplossen, controleert u of u de beperkingslimiet bereikt door de metrische gegevens voor het verzenden van telemetrieberichten te vergelijken met de hierboven opgegeven limieten. U kunt ook het metrische gegevens over beperkingsfouten controleren. Zie De metrische gegevens van apparaattelemetrie voor informatie over deze metrische gegevens. Zie IoT Hub bewaken voor informatie over het gebruik van metrische gegevens om u te helpen uw IoT-hub te bewaken.

IoT Hub retourneert 429 ThrottlingException pas nadat de limiet te lang is geschonden. Dit wordt gedaan zodat uw berichten niet worden verwijderd als uw IoT-hub burst-verkeer krijgt. In de tussentijd worden de berichten in IoT Hub verwerkt volgens de vertragingsfactor voor bewerkingen. Als er te veel achterstallig verkeer is, kan dit traag zijn. Zie IoT traffic shapingvoor meer informatie.

Overweeg om uw IoT Hub op te schalen als u te maken hebt met quotum- of beperkingslimieten.

500xxx Interne fouten

Mogelijk ziet u dat uw aanvraag voor IoT Hub mislukt met een fout die begint met 500 en/of een soort 'serverfout'. Enkele mogelijkheden zijn:

500001 ServerError: Er is een probleem aan de serverzijde opgetreden in IoT Hub.
500008 GenericTimeout: IoT Hub kan de verbindingsaanvraag niet voltooien voordat er een time-out optreedt.
ServiceUnavailable (geen foutcode): Er is een interne fout opgetreden in IoT Hub.
InternalServerError (geen foutcode): Er is een interne fout opgetreden in IoT Hub.

Er kunnen veel oorzaken zijn voor een 500xxx-foutreactie. In alle gevallen is het probleem waarschijnlijk tijdelijk. Hoewel het IoT Hub-team hard werkt om de SLA te onderhouden, kunnen kleine subsets van IoT Hub-knooppunten af en toe tijdelijke fouten ondervinden. Wanneer uw apparaat verbinding probeert te maken met een knooppunt dat problemen ondervindt, ontvangt u deze fout.

Als u 500xxx-fouten wilt beperken, voert u een nieuwe poging uit vanaf het apparaat. Als u nieuwe pogingen automatisch wilt beheren, moet u de nieuwste versie van de Azure IoT SDK's gebruiken. Zie De afhandeling van tijdelijke fouten en nieuwe pogingen voor aanbevolen procedures voor het afhandelen van tijdelijke fouten.

Als het probleem zich blijft voordoen, controleert u Resource Health en Azure-status om te zien of IoT Hub een bekend probleem heeft. U kunt ook de functie voor handmatige failover gebruiken.

Als er geen bekende problemen zijn en het probleem zich blijft voordoen, neemt u contact op met de ondersteuning voor verder onderzoek.

503003 partitie niet gevonden

Mogelijk ziet u dat aanvragen voor IoT Hub mislukken met de fout 503003 PartitionNotFound.

Deze fout is intern voor IoT Hub en is waarschijnlijk tijdelijk. Zie interne IoT Hub-serverfouten.

Als u deze fout wilt oplossen, raadpleegt u interne IoT Hub-serverfouten.

Time-out voor 504101 gateway

Wanneer u een directe methode probeert aan te roepen van IoT Hub naar een apparaat, ziet u mogelijk dat de aanvraag mislukt met de fout 504101 GatewayTimeout.

Deze fout treedt op omdat er een fout is opgetreden in IoT Hub en kan niet worden bevestigd of de directe methode is voltooid voordat er een time-out optreedt. Als u een eerdere versie van de Azure IoT C#SDK (<1.19.0) gebruikt, kan de AMQP-koppeling tussen het apparaat en IoT Hub op de achtergrond worden verwijderd vanwege een fout.

Als u deze fout wilt oplossen, voert u een nieuwe poging uit of voert u een upgrade uit naar de nieuwste versie van de Azure IOT C#SDK.

Share via