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

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 Anslutningen tvångsavslutades vid ny anslutning

Du kan se felet 400027 ConnectionForcefullyClosedOnNewConnection om enheten kopplar från och rapporterar Communication_Error som ConnectionStatusChangeReason med .NET SDK och transportprotokollet MQTT. Eller så misslyckas din åtgärd för enhets-till-moln-tvilling (till exempel läsa eller korrigera rapporterade egenskaper) eller direkta metodanrop 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 åtkomst

I loggar kan du se ett mönster med enheter som kopplas från, med felmeddelandet 401003 IoTHubUnauthorized, följt av 404104 DeviceConnectionClosedRemotely och ansluter sedan framgångsrikt 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 DeviceConnectionClosedRemotely
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 resultat 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 enhetsanslutningssträngen. 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 avsnittet MQTT-enhetens frånkopplingsbeteende med Azure IoT SDK:er i Övervaka, diagnostisera och felsöka Azure IoT Hub-enhetsanslutning.

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:

• 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 åtkomsten till IoT Hub med hjälp av Microsoft Entra-ID.
• 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.

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. Gör så här för att lösa problemet:

• Uppgradera eller öka antalet enheter på IoT-hubben eller vänta tills den dagliga kvoten uppdateras nästa UTC-dag.
• Information om hur åtgärder räknas mot kvoten, till exempel tvillingfrågor och direkta metoder, finns i avsnittet Avgifter per åtgärd i faktureringsinformation för Azure IoT Hub.
• Konfigurera övervakning för daglig kvotanvändning genom att konfigurera en avisering med måttet Totalt antal meddelanden som används. Stegvisa instruktioner finns i avsnittet Konfigurera mått i Självstudie: Konfigurera och använda mått och loggar med en IoT-hubb.

Ett massimportjobb kan också returnera det här felet när antalet enheter som är registrerade på din IoT-hubb närmar sig eller överskrider kvotgränsen för en IoT-hubb. För att lära dig mer, se avsnittet Felsöka importjobb i Importera och exportera IoT Hub-enhetsidentiteter i grupp.

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. Mer information finns i avsnittet Meddelandeförfallodatum (time to live) i Förstå meddelanden från moln till enhet från en IoT-hubb.

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. Ett opålitligt nätverk på enhetssidan orsakar ofta det här problemet.

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 ändå får felet beror det troligen på att återanropet för den direkta metoden inte har registrerats på enheten.

Mer information om hur du konfigurerar enheten korrekt för direkt metodåteranrop finns i avsnittet Hantera en direktmetod på en enhet 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 DeviceConnectionClosedRemotely i IoT Hub-resursloggarna. Ibland kan du också se 401003 IoTHubUnauthorized och en lyckad enhetsanslutningshändelse mindre än en minut senare.

Eller så kopplar enheterna slumpmässigt bort, och du ser 404104 DeviceConnectionClosedRemotely i resursloggarna för IoT Hub.

Eller, många enheter kopplas från samtidigt, du ser en nedgång i Anslutna enheter-måttet (connectedDeviceCount) och det finns fler 404104 DeviceConnectionClosedRemotely och 500xxx Interna fel i loggfilerna för Azure Monitor ä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 enheten uppdaterar token. 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 kan buggar i äldre versioner av Azure IoT SDK orsaka det här problemet.
• Programmet på enhetssidan kraschade.

Eller så kan IoT Hub ha ett tillfälligt problem. För mer information, se 500xxx Interna fel.

Gör så här för att lösa problemet:

• 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 Azure IoT Hub SDK:er.
• Se vägledningen för interna 500xxx-fel.

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.

409002-konflikt vid skapande av länkar

Du kan se felet 409002 LinkCreationConflict i loggar tillsammans med enhetsfrånkoppling eller fel vid meddelandeleverans från moln till enhet.

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 är det ett separat problem (till exempel 404104 DeviceConnectionClosedRemotely) som gör 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 ), ReceiveAsync()låser IoT Hub meddelandet 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 notifikationen inom tidsgränsen för låsning som är en minut, återställs meddelandet till Köad 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.

429xxx Taktbegränsningsfel

Du kan se att dina begäranden till IoT Hub misslyckas med ett fel som börjar med 429 , till exempel:

• 429000 – GenericTooManyRequests
• 429001 – ThrottlingException: Begränsningsgränserna överskrids för den begärda åtgärden.
• 429002 – ThrottleBacklogLimitExceeded: Antalet begäranden som finns i kvarvarande uppgifter på grund av begränsning har överskridit gränsen för kvarvarande uppgifter.
• 429003 – ThrottlingBacklogTimeout: Begäranden som har hamnat i kö på grund av strömbegränsning har överskridit tidsgränsen i väntan i kön för eftersläpande förfrågningar.
• 429004 – ThrottlingMaxActiveJobCountExceeded
• 429005 – Enhetsbegränsningsgräns överskriden

Du kan bara övervaka 429001 via Azure Monitor under måttet Antal begränsningsfel. För närvarande har de andra strypningsfelen inget tillhörande mätvärde, men de registreras i loggarna.

Lös dessa fel genom att kontrollera om du når begränsningsgränsen genom att jämföra måttet för sändningsförsök för telemetrimeddelanden med de gränser som tidigare angetts. Du kan också kontrollera Antal begränsningsfel-måttet. 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 Azure IoT Hub.

IoT Hub returnerar 429001 – ThrottlingException först efter att gränsen har överskridits för länge. Den här fördröjningen görs så att dina meddelanden inte går förlorade om din IoT-hubb får en plötslig trafikökning. 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. Mer information finns i avsnittet Trafikformning av IoT Hub-kvoter och begränsning.

Överväg att skala upp din IoT-hubb om du stöter på kvoter eller strypningsgränser.

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 Hub SDK:er. Mer information om metodtips 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. För mer information, se 500xxx Interna fel.

Information om hur du löser det här felet finns i 500xxx Interna fel.

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.