Share via

Förstå och lösa Azure IoT Hub-fel

  • Artikel

I den här artikeln beskrivs orsaker och lösningar för vanliga felkoder som du kan stöta på när du använder IoT Hub.

400027 Anslut ion stängdes kraftigt för ny anslutning

Du kan se felet 400027 Anslut ionForcefullyClosedOnNew Anslut ion om enheten kopplar från och rapporterar Communication_Error som Anslut ionStatusChangeReason med hjälp av transporttypen .NET SDK och MQTT. Eller så misslyckas din enhets-till-moln-tvillingåtgärd (till exempel läs- eller korrigeringsrapporterade egenskaper) eller direktmetodanrop med felkoden 400027.

Det här felet uppstår när en annan klient skapar en ny anslutning till IoT Hub med samma identitet, så IoT Hub stänger den tidigare anslutningen. IoT-hubben tillåter inte att fler än en klient ansluter med samma identitet.

Lös det här felet genom att se till att varje klient ansluter till IoT Hub med sin egen identitet.

401003 IoT Hub obehörig

I loggar kan du se ett mönster där enheter kopplas från med 401003 IoTHubUnauthorized, följt av 404104 Device Anslut ionClosedRemotely och sedan ansluta kort därefter.

Eller så misslyckas begäranden till IoT Hub med något av följande felmeddelanden:

  • Auktoriseringsrubrik saknas
  • IotHub '*' innehåller inte den angivna enheten '*'
  • Auktoriseringsregeln '*' tillåter inte åtkomst för '*'
  • Autentiseringen misslyckades för den här enheten, förnya token eller certifikat och återansluta
  • Tumavtrycket matchar inte konfigurationen: Tumavtryck: SHA1Hash=*, SHA2Hash=*; Konfiguration: PrimaryThumbprint=*, SecondaryThumbprint=*
  • Huvudkontot user@example.com är inte auktoriserat för GET på /exampleOperation på grund av att inga tilldelade behörigheter har tilldelats

Det här felet uppstår eftersom vissa SDK:er för MQTT förlitar sig på att IoT Hub utfärdar frånkopplingen när SAS-token upphör att gälla för att veta när den ska uppdateras. Så,

  1. SAS-token upphör att gälla
  2. IoT Hub märker förfallodatumet och kopplar från enheten med 401003 IoTHubUnauthorized
  3. Enheten slutför frånkopplingen med 404104 Device Anslut ionClosedRemotely
  4. IoT SDK genererar en ny SAS-token
  5. Enheten återansluter med IoT Hub

Eller så kunde IoT Hub inte autentisera autentiseringshuvudet, regeln eller nyckeln. Detta kan bero på någon av de orsaker som anges i symtomen.

För att lösa det här felet krävs ingen åtgärd om du använder IoT SDK för anslutning med hjälp av enheten anslutningssträng. IoT SDK återskapar den nya token för att återansluta vid SAS-tokens förfallotid.

Standardtokens livslängd är 60 minuter över SDK:er. För vissa SDK:er kan dock tokenlivslängden och tröskelvärdet för tokenförnyelse konfigureras. Dessutom skiljer sig de fel som genereras när en enhet kopplar från och återansluter vid tokenförnyelse för varje SDK. Mer information och information om hur du avgör vilken SDK din enhet använder i loggar finns i MQTT-enhetens frånkopplingsbeteende med Azure IoT SDK:er.

Om volymen av fel är ett problem för enhetsutvecklare växlar du till C SDK som förnyar SAS-token innan den upphör att gälla. För AMQP kan SAS-token uppdateras utan frånkoppling.

I allmänhet bör det felmeddelande som visas förklara hur du åtgärdar felet. Om du av någon anledning inte har åtkomst till felmeddelandeinformationen kontrollerar du följande:

  • DEN SAS eller annan säkerhetstoken som du använder har inte upphört att gälla.
  • För X.509-certifikatautentisering har enhetscertifikatet eller certifikatutfärdarcertifikatet som är associerat med enheten inte upphört att gälla. Mer information om hur du registrerar X.509 CA-certifikat med IoT Hub finns i Självstudie: Skapa och ladda upp certifikat för testning.
  • För X.509-certifikatets tumavtrycksautentisering registreras tumavtrycket för enhetscertifikatet med IoT Hub.
  • Auktoriseringsautentiseringsuppgifterna är väl utformade för det protokoll som du använder. Mer information finns i Kontrollera åtkomst till IoT Hub.
  • Den auktoriseringsregel som används har behörighet för den begärda åtgärden.
  • För de sista felmeddelandena som börjar med "principal..." kan det här felet lösas genom att tilldela rätt nivå av Azure RBAC-behörighet till användaren. En ägare på IoT Hub kan till exempel tilldela rollen "IoT Hub-dataägare", vilket ger alla behörigheter. Prova den här rollen för att lösa bristen på behörighetsproblem.

Kommentar

Vissa enheter kan uppleva ett tidsavdriftsproblem när enhetstiden har en större skillnad än fem minuter från servern. Det här felet kan inträffa när en enhet har anslutit till en IoT-hubb utan problem i veckor eller till och med månader, men sedan kontinuerligt får anslutningen nekad. Felet kan också vara specifikt för en delmängd av enheter som är anslutna till IoT-hubben, eftersom tidsavvikelsen kan inträffa i olika takt beroende på när en enhet först ansluts eller aktiveras.

Att utföra en tidssynkronisering med NTP eller starta om enheten (som automatiskt kan utföra en tidssynkronisering under startsekvensen) löser ofta problemet och gör att enheten kan ansluta igen. För att undvika det här felet konfigurerar du enheten för att utföra en periodisk tidssynkronisering med hjälp av NTP. Du kan schemalägga synkroniseringen för varje dag, varje vecka eller månad beroende på hur mycket drift enheten upplever. Om du inte kan konfigurera en periodisk NTP-synkronisering på enheten schemalägger du en periodisk omstart.

403002 IoT Hub-kvoten har överskridits

Du kan se begäranden till IoT Hub misslyckas med felet 403002 IoTHubQuotaExceeded. Och i Azure-portalen läses inte IoT Hub-enhetslistan in.

Det här felet uppstår vanligtvis när den dagliga meddelandekvoten för IoT-hubben överskrids. Lös problemet så här:

Det här felet kan också returneras av ett massimportjobb när antalet enheter som är registrerade på din IoT Hub närmar sig eller överskrider kvotgränsen för en IoT-hubb. Mer information finns i Felsöka importjobb.

403004 Maximalt ködjup för enheten har överskridits

När du försöker skicka ett meddelande från molnet till enheten kan du se att begäran misslyckas med felet 403004 eller DeviceMaximumQueueDepthExceeded.

Den underliggande orsaken till det här felet är att antalet meddelanden som anges för enheten överskrider kögränsen.

Den troligaste orsaken till att du stöter på den här gränsen är att du använder HTTPS för att ta emot meddelandet, vilket leder till kontinuerlig avsökning med , ReceiveAsyncvilket resulterar i att IoT Hub begränsar begäran.

Det mönster som stöds för meddelanden från moln till enhet med HTTPS är tillfälligt anslutna enheter som söker efter meddelanden sällan (mindre än var 25:e minut). Om du vill minska sannolikheten för att kögränsen överskrids växlar du till AMQP eller MQTT för meddelanden från moln till enhet.

Du kan också förbättra logiken på enhetssidan för att slutföra, avvisa eller överge köade meddelanden snabbt, förkorta tiden till live eller överväga att skicka färre meddelanden. Se C2D-meddelandets TTL-värde.

Slutligen bör du överväga att använda API:et Rensa kö för att regelbundet rensa väntande meddelanden innan gränsen nås.

403006 Gränsen för maximal aktiv filuppladdning för enheten har överskridits

Du kan se att din filuppladdningsbegäran misslyckas med felkoden 403006 DeviceMaximumActiveFileUploadLimitExceeded och meddelandet "Antalet aktiva filuppladdningsbegäranden får inte överstiga 10".

Det här felet beror på att varje enhetsklient är begränsad för samtidiga filuppladdningar. Du kan enkelt överskrida gränsen om enheten inte meddelar IoT Hub när filuppladdningar har slutförts. Det här problemet orsakas ofta av ett opålitligt nätverk på enhetssidan.

Lös det här felet genom att se till att enheten snabbt kan meddela att IoT Hub-filuppladdningen har slutförts. Försök sedan att minska SAS-token-TTL för filuppladdningskonfiguration.

404001 Enheten hittades inte

Under en C2D-kommunikation (moln-till-enhet), till exempel C2D-meddelande, tvillinguppdatering eller direktmetod, kan du se att åtgärden misslyckas med felet 404001 DeviceNotFound.

Åtgärden misslyckades eftersom IoT Hub inte kan hitta enheten. Enheten är antingen inte registrerad eller inaktiverad.

Lös det här felet genom att registrera enhets-ID:t som du använde och försök sedan igen.

404103 Enheten är inte online

Du kan se att en direktmetod till en enhet misslyckas med felet 404103 DeviceNotOnline även om enheten är online.

Om du vet att enheten är online och fortfarande får felet uppstod troligen felet eftersom återanropet för direktmetoden inte har registrerats på enheten.

Information om hur du konfigurerar enheten korrekt för direkt metodåteranrop finns i Hantera en direktmetod på en enhet.

404104 Enhetsanslutningen stängdes via fjärranslutning

Du kan se att enheterna kopplas från med jämna mellanrum (till exempel var 65:e minut) och du ser 404104 Device Anslut ionClosedRemotely i IoT Hub-resursloggarna. Ibland kan du också se 401003 IoTHubUnauthorized och en lyckad enhetsanslutningshändelse mindre än en minut senare.

Eller så kopplas enheterna från slumpmässigt och du ser 404104 Device Anslut ionClosedRemotely i IoT Hub-resursloggarna.

Eller så kan många enheter kopplas från samtidigt, du ser en nedgång i måttet Anslut ed devices (connectedDeviceCount) och det finns fler 404104 Enhet Anslut ionClosedRemotely och 500xxx Interna fel i Azure Monitor-loggar än vanligt.

Det här felet kan inträffa eftersom SAS-token som används för att ansluta till IoT Hub har upphört att gälla, vilket gör att IoT Hub kopplar från enheten. Anslutningen återupprättas när token uppdateras av enheten. SAS-token upphör till exempel att gälla varje timme som standard för C SDK, vilket kan leda till regelbundna frånkopplingar. Mer information finns i 401003 IoTHubUnauthorized.

Några andra möjligheter är:

  • Enheten förlorade den underliggande nätverksanslutningen längre än MQTT keep-alive, vilket resulterade i en tidsgräns för fjärrinaktivitet. Inställningen MQTT keep-alive kan skilja sig åt per enhet.
  • Enheten skickade en TCP/IP-nivååterställning men skickade inte en programnivå MQTT DISCONNECT. I princip stängde enheten plötsligt den underliggande socketanslutningen. Ibland orsakas det här problemet av buggar i äldre versioner av Azure IoT SDK.
  • Programmet på enhetssidan kraschade.

Eller så kan IoT Hub ha ett tillfälligt problem. Se IoT Hub:s interna serverfel.

Lös problemet så här:

  • Se vägledningen för fel 401003 IoTHubUnauthorized.
  • Kontrollera att enheten har en bra anslutning till IoT Hub genom att testa anslutningen. Om nätverket är otillförlitligt eller tillfälligt rekommenderar vi inte att du ökar keep-alive-värdet eftersom det kan leda till att identifieringen (till exempel via Azure Monitor-aviseringar) tar längre tid.
  • Använd de senaste versionerna av IoT SDK:er.
  • Se vägledningen för interna IoT Hub-serverfel.

Vi rekommenderar att du använder SDK för Azure IoT-enheter för att administrerar anslutningar på ett tillförlitligt sätt. Mer information finns i Hantera anslutningar och tillförlitlig meddelandehantering med hjälp av SDK:er för Azure IoT Hub-enheter

409001 Enheten finns redan

När du försöker registrera en enhet i IoT Hub kan du se att begäran misslyckas med felet 409001 DeviceAlreadyExists.

Det här felet beror på att det redan finns en enhet med samma enhets-ID i IoT-hubben.

Lös det här felet genom att använda ett annat enhets-ID och försöka igen.

Du kan se felet 409002 LinkCreationConflict i loggar tillsammans med enhetsfel vid frånkoppling eller meddelandefel från molnet till enheten.

Det här felet inträffar vanligtvis när IoT Hub identifierar att en klient har mer än en anslutning. När en ny anslutningsbegäran tas emot för en enhet med en befintlig anslutning stänger IoT Hub faktiskt den befintliga anslutningen med det här felet.

I det vanligaste fallet gör ett separat problem (till exempel 404104 Device Anslut ionClosedRemotely) att enheten kopplas från. Enheten försöker återupprätta anslutningen omedelbart, men IoT Hub anser fortfarande att enheten är ansluten. IoT Hub stänger den tidigare anslutningen och loggar det här felet.

Eller så gör felaktig logik på enhetssidan att enheten upprättar anslutningen när en redan är öppen.

Lös det här felet genom att leta efter andra fel i loggarna som du kan felsöka eftersom det här felet vanligtvis visas som en bieffekt av ett annat, tillfälligt problem. Annars bör du bara utfärda en ny anslutningsbegäran om anslutningen avbryts.

412002 Enhetsmeddelandelåset har förlorats

När du försöker skicka ett meddelande från molnet till enheten kan du se att begäran misslyckas med felet 412002 DeviceMessageLockLost.

Det här felet beror på att när en enhet tar emot ett meddelande från molnet till enheten från kön (till exempel med hjälp ReceiveAsync()av ) låses meddelandet av IoT Hub under en tidsgräns på en minut. Om enheten försöker slutföra meddelandet när tidsgränsen för låset upphör att gälla genererar IoT Hub det här undantaget.

Om IoT Hub inte får meddelandet inom tidsgränsen på en minut för låsning, återgår meddelandet till Ettqueued-tillstånd . Enheten kan försöka ta emot meddelandet igen. Om du vill förhindra att felet inträffar i framtiden implementerar du logik på enhetssidan för att slutföra meddelandet inom en minut efter att meddelandet tagits emot. Det går inte att ändra tidsgränsen på en minut.

429001 Begränsningsfel

Du kan se att dina begäranden till IoT Hub misslyckas med felet 429001 ThrottlingException.

Det här felet uppstår när begränsningsgränserna för IoT Hub har överskridits för den begärda åtgärden.

Lös det här felet genom att kontrollera om du når begränsningsgränsen genom att jämföra måttet skicka telemetrimeddelanden mot de gränser som anges ovan. Du kan också kontrollera måttet Antal begränsningsfel . Information om dessa mått finns i Enhetstelemetrimått. Information om hur du använder mått för att övervaka din IoT-hubb finns i Övervaka IoT Hub.

IoT Hub returnerar 429 ThrottlingException först efter att gränsen har överskridits för länge. Detta görs så att dina meddelanden inte tas bort om din IoT-hubb får burst-trafik. Under tiden bearbetar IoT Hub meddelandena med begränsad hastighet, vilket kan gå långsamt om det finns för mycket kvarvarande trafik att hantera. Läs mer i Trafikkvotering.

Överväg att skala upp din IoT-hubb om du når upp till kvoter eller begränsningsvärden.

500xxx Interna fel

Du kan se att din begäran till IoT Hub misslyckas med ett fel som börjar med 500 och/eller någon form av "serverfel". Några möjligheter är:

  • 500001 ServerError: IoT Hub stötte på ett problem på serversidan.

  • 500008 GenericTimeout: IoT Hub kunde inte slutföra anslutningsbegäran innan tidsgränsen uppnåddes.

  • ServiceUnavailable (ingen felkod): IoT Hub påträffade ett internt fel.

  • InternalServerError (ingen felkod): IoT Hub påträffade ett internt fel.

Det kan finnas många orsaker till ett 500xxx-felsvar. I samtliga fall är problemet troligtvis tillfälligt. Även om IoT Hub-teamet arbetar hårt för att underhålla serviceavtalet kan små delmängder av IoT Hub-noder ibland uppleva tillfälliga fel. När enheten försöker ansluta till en nod som har problem får du det här felet.

Åtgärda 500xxx-fel genom att göra ett nytt försök från enheten. Om du vill hantera återförsök automatiskt kontrollerar du att du använder den senaste versionen av Azure IoT SDK:er. Bästa praxis för tillfällig felhantering och återförsök finns i Tillfälliga felhantering.

Om problemet kvarstår kontrollerar du Resource Health och Azure-status för att se om IoT Hub har ett känt problem. Du kan också använda den manuella redundansfunktionen.

Om det inte finns några kända problem och problemet kvarstår kontaktar du supporten för ytterligare undersökning.

503003 partition hittades inte

Du kan se att begäranden till IoT Hub misslyckas med felet 503003 PartitionNotFound.

Det här felet är internt för IoT Hub och är sannolikt tillfälligt. Se interna IoT Hub-serverfel.

Information om hur du löser det här felet finns i Interna IoT Hub-serverfel.

tidsgräns för 504101 gateway

När du försöker anropa en direktmetod från IoT Hub till en enhet kan du se att begäran misslyckas med felet 504101 GatewayTimeout.

Det här felet beror på att IoT Hub påträffade ett fel och inte kunde bekräfta om direktmetoden slutfördes innan tidsgränsen gick ut. Eller när du använder en tidigare version av Azure IoT C# SDK (<1.19.0) kan AMQP-länken mellan enheten och IoT Hub tas bort tyst på grund av en bugg.

Lös det här felet genom att göra ett nytt försök eller uppgradera till den senaste versionen av Azure IOT C# SDK.