Comprendere e risolvere gli errori di hub IoT di Azure

Articolo
02/03/2024

Questo articolo descrive le cause e le soluzioni per i codici di errore comuni che possono verificarsi durante l'uso di hub IoT.

400027 Connessione chiusura forzata della nuova connessione

È possibile che venga visualizzato l'errore 400027 Connessione ionForcefullyClosedOnNew Connessione ion se il dispositivo si disconnette e segnala Communication_Error come Connessione ionStatusChangeReason usando .NET SDK e il tipo di trasporto MQTT. In alternativa, l'operazione da dispositivo a cloud gemello (ad esempio le proprietà segnalate da lettura o patch) o la chiamata al metodo diretto ha esito negativo con il codice di errore 400027.

Questo errore si verifica quando un altro client crea una nuova connessione a hub IoT usando la stessa identità, quindi hub IoT chiude la connessione precedente. Hub IoT non consente a più client di connettersi usando la stessa identità.

Per risolvere questo errore, assicurarsi che ogni client si connetta a hub IoT usando la propria identità.

401003 hub IoT non autorizzato

Nei log è possibile che venga visualizzato un modello di dispositivi che si disconnettono con 401003 IoTHubUnauthorized, seguito da 404104 Device Connessione ionClosedRemotely e quindi si connette correttamente poco dopo.

In alternativa, le richieste a hub IoT hanno esito negativo con uno dei messaggi di errore seguenti:

Intestazione di autorizzazione mancante
IotHub '*' non contiene il dispositivo specificato '*'
La regola di autorizzazione '*' non consente l'accesso per '*'
Autenticazione non riuscita per questo dispositivo, rinnovare il token o il certificato e riconnettersi
Identificazione personale non corrisponde alla configurazione: Identificazione personale: SHA1Hash=*, SHA2Hash=*; Configurazione: PrimaryThumbprint=*, SecondaryThumbprint=*
L'entità user@example.com non è autorizzata per GET in /exampleOperation a causa di autorizzazioni non assegnate

Questo errore si verifica perché, per MQTT, alcuni SDK si basano su hub IoT per rilasciare la disconnessione alla scadenza del token di firma di accesso condiviso per sapere quando aggiornarlo. Quindi

Il token di firma di accesso condiviso scade
hub IoT rileva la scadenza e disconnette il dispositivo con 401003 IoTHubUnauthorized
Il dispositivo completa la disconnessione con 404104 Dispositivo Connessione ionClosedRemotely
IoT SDK genera un nuovo token di firma di accesso condiviso
Il dispositivo si riconnette con hub IoT correttamente

In alternativa, hub IoT non è stato possibile autenticare l'intestazione, la regola o la chiave di autenticazione. Ciò potrebbe essere dovuto a qualsiasi motivo citato nei sintomi.

Per risolvere questo errore, non è necessaria alcuna azione se si usa IoT SDK per la connessione usando il dispositivo stringa di connessione. IoT SDK rigenera il nuovo token per riconnettersi alla scadenza del token di firma di accesso condiviso.

La durata predefinita del token è di 60 minuti tra gli SDK; Tuttavia, per alcuni SDK la durata del token e la soglia di rinnovo del token è configurabile. Inoltre, gli errori generati quando un dispositivo si disconnette e si riconnette al rinnovo del token differisce per ogni SDK. Per altre informazioni e per informazioni su come determinare l'SDK usato nei log, vedere Comportamento di disconnessione dei dispositivi MQTT con Azure IoT SDK.

Per gli sviluppatori di dispositivi, se il volume di errori è un problema, passare a C SDK, che rinnova il token di firma di accesso condiviso prima della scadenza. Per AMQP, il token di firma di accesso condiviso può essere aggiornato senza disconnessione.

In generale, il messaggio di errore presentato dovrebbe spiegare come correggere l'errore. Se per qualche motivo non si ha accesso ai dettagli del messaggio di errore, assicurarsi di:

La firma di accesso condiviso o un altro token di sicurezza usato non è scaduta.
Per l'autenticazione del certificato X.509, il certificato del dispositivo o il certificato della CA associato al dispositivo non è scaduto. Per informazioni su come registrare i certificati della CA X.509 con hub IoT, vedere Esercitazione: Creare e caricare certificati per i test.
Per l'autenticazione dell'identificazione personale del certificato X.509, l'identificazione personale del certificato del dispositivo viene registrata con hub IoT.
Le credenziali di autorizzazione sono ben formate per il protocollo usato. Per altre informazioni, vedere Controllare l'accesso alle hub IoT.
La regola di autorizzazione usata dispone dell'autorizzazione per l'operazione richiesta.
Per gli ultimi messaggi di errore che iniziano con "principal...", questo errore può essere risolto assegnando all'utente il livello corretto di autorizzazione controllo degli accessi in base al ruolo di Azure. Ad esempio, un proprietario nel hub IoT può assegnare il ruolo "proprietario dati hub IoT", che concede tutte le autorizzazioni. Provare questo ruolo per risolvere il problema di mancanza di autorizzazione.

Nota

Alcuni dispositivi possono riscontrare un problema di deviazione del tempo quando l'ora del dispositivo ha una differenza maggiore di cinque minuti rispetto al server. Questo errore può verificarsi quando un dispositivo si connette a un hub IoT senza problemi per settimane o anche mesi, ma inizia a rifiutare continuamente la connessione. L'errore può anche essere specifico di un sottoinsieme di dispositivi connessi all'hub IoT, poiché la deviazione del tempo può verificarsi a velocità diverse a seconda del momento in cui un dispositivo è connesso o attivato per la prima volta.

Spesso, l'esecuzione di una sincronizzazione dell'ora usando NTP o il riavvio del dispositivo (che può eseguire automaticamente una sincronizzazione dell'ora durante la sequenza di avvio) risolve il problema e consente al dispositivo di connettersi di nuovo. Per evitare questo errore, configurare il dispositivo per eseguire una sincronizzazione temporale periodica tramite NTP. È possibile pianificare la sincronizzazione per le esperienze giornaliere, settimanali o mensili a seconda della quantità di esperienze del dispositivo. Se non è possibile configurare una sincronizzazione NTP periodica nel dispositivo, pianificare un riavvio periodico.

403002 hub IoT quota superata

È possibile che vengano visualizzate le richieste di hub IoT hanno esito negativo con l'errore 403002 IoTHubQuotaExceeded. E in portale di Azure, l'elenco dei dispositivi dell'hub IoT non viene caricato.

Questo errore si verifica in genere quando viene superata la quota giornaliera dei messaggi per l'hub IoT. Per risolvere questo errore:

Aggiornare o aumentare il numero di unità nell'hub IoT o attendere il giorno UTC successivo per l'aggiornamento della quota giornaliera.
Per comprendere il modo in cui le operazioni vengono conteggiate in base alla quota, ad esempio query gemelle e metodi diretti, vedere Informazioni sui prezzi di hub IoT.
Per configurare il monitoraggio per l'utilizzo giornaliero della quota, configurare un avviso con la metrica Numero totale di messaggi usati. Per istruzioni dettagliate, vedere Configurare metriche e avvisi con hub IoT.

Questo errore può essere restituito anche da un processo di importazione in blocco quando il numero di dispositivi registrati nell'hub IoT si avvicina o supera il limite di quota per un hub IoT. Per altre informazioni, vedere Risolvere i problemi relativi ai processi di importazione.

403004 Profondità massima coda dispositivo superata

Quando si tenta di inviare un messaggio da cloud a dispositivo, è possibile che la richiesta non riesca con l'errore 403004 o DeviceMaximumQueueDepthExceeded.

La causa sottostante di questo errore è che il numero di messaggi accodati per il dispositivo supera il limite di coda.

Il motivo più probabile per cui si sta verificando questo limite è che si sta usando HTTPS per ricevere il messaggio, che porta al polling continuo usando ReceiveAsync, con conseguente hub IoT limitazione della richiesta.

Il modello supportato per i messaggi da cloud a dispositivo con HTTPS è rappresentato da dispositivi collegati in modo intermittente che controllano raramente la presenza di messaggi (meno di ogni 25 minuti). Per ridurre la probabilità di raggiungere il limite di coda, passare a AMQP o MQTT per i messaggi da cloud a dispositivo.

In alternativa, migliorare la logica lato dispositivo per completare, rifiutare o abbandonare rapidamente i messaggi in coda, ridurre il tempo di vita o prendere in considerazione l'invio di un minor numero di messaggi. Vedere Durata dei messaggi C2D.

Infine, prendere in considerazione l'uso dell'API Elimina coda per pulire periodicamente i messaggi in sospeso prima che venga raggiunto il limite.

403006 Limite massimo di caricamento file attivo del dispositivo superato

È possibile che la richiesta di caricamento del file non riesca con il codice di errore 403006 DeviceMaximumActiveFileUploadLimitExceeded e un messaggio "Numero di richieste di caricamento di file attive non può superare 10".

Questo errore si verifica perché ogni client del dispositivo è limitato per i caricamenti simultanei di file. È possibile superare facilmente il limite se il dispositivo non invia notifiche hub IoT al completamento dei caricamenti di file. Questo problema è comunemente causato da una rete lato dispositivo inaffidabile.

Per risolvere questo errore, assicurarsi che il dispositivo possa notificare tempestivamente hub IoT completamento del caricamento dei file. Provare quindi a ridurre il TTL del token di firma di accesso condiviso per la configurazione del caricamento di file.

404001 dispositivo non trovato

Durante una comunicazione da cloud a dispositivo (C2D), ad esempio un messaggio C2D, un aggiornamento gemello o un metodo diretto, è possibile che l'operazione non riesca con errore 404001 DeviceNotFound.

L'operazione non è riuscita perché hub IoT non riesce a trovare il dispositivo. Il dispositivo non è registrato o è disabilitato.

Per risolvere questo errore, registrare l'ID dispositivo usato, quindi riprovare.

404103 dispositivo non online

È possibile che un metodo diretto a un dispositivo non riesca con l'errore 404103 DeviceNotOnline anche se il dispositivo è online.

Se si sa che il dispositivo è online e viene comunque visualizzato l'errore, l'errore probabilmente si è verificato perché il callback del metodo diretto non è registrato nel dispositivo.

Per configurare correttamente il dispositivo per i callback dei metodi diretti, vedere Gestire un metodo diretto in un dispositivo.

404104 Connessione del dispositivo chiusa in remoto

Si noterà che i dispositivi si disconnettono a intervalli regolari (ad esempio ogni 65 minuti) e vengono visualizzati 404104 Dispositivo Connessione ionClosedRemotely nei log delle risorse hub IoT. A volte, vengono visualizzati anche 401003 IoTHubUnauthorized e un evento di connessione del dispositivo riuscito meno di un minuto dopo.

In alternativa, i dispositivi si disconnettono in modo casuale e vengono visualizzati 404104 Device Connessione ionClosedRemotely nei log delle risorse hub IoT.

In alternativa, molti dispositivi si disconnettono contemporaneamente, viene visualizzato un dip nella metrica dei dispositivi Connessione (connectedDeviceCount) e sono presenti più 404104 Dispositivo Connessione ionClosedRemotely e 500xxx Errori interni nei log di Monitoraggio di Azure del solito.

Questo errore può verificarsi perché il token di firma di accesso condiviso usato per connettersi a hub IoT scaduto, causando la disconnessione del dispositivo hub IoT. La connessione viene ristabilita quando il token viene aggiornato dal dispositivo. Ad esempio, il token di firma di accesso condiviso scade ogni ora per impostazione predefinita per C SDK, che può causare interruzioni regolari. Per altre informazioni, vedere 401003 IoTHubUnauthorized.

Alcune altre possibilità includono:

Il dispositivo ha perso la connettività di rete sottostante più a lungo del keep-alive MQTT, causando un timeout di inattività remoto. L'impostazione keep-alive di MQTT può essere diversa per dispositivo.
Il dispositivo ha inviato una reimpostazione a livello TCP/IP ma non ha inviato un oggetto a livello MQTT DISCONNECTdi applicazione. Fondamentalmente, il dispositivo ha chiuso bruscamente la connessione socket sottostante. In alcuni casi, questo problema è causato da bug nelle versioni precedenti di Azure IoT SDK.
L'applicazione lato dispositivo si è arrestata in modo anomalo.

In alternativa, hub IoT potrebbe verificarsi un problema temporaneo. Vedere hub IoT errore interno del server.

Per risolvere questo errore:

Vedere le indicazioni per l'errore 401003 IoTHubUnauthorized.
Assicurarsi che il dispositivo disponga di una buona connettività per hub IoT testando la connessione. Se la rete non è affidabile o intermittente, non è consigliabile aumentare il valore keep-alive perché potrebbe comportare il rilevamento (ad esempio, tramite avvisi di Monitoraggio di Azure) richiede più tempo.
Usare le versioni più recenti degli SDK IoT.
Vedere le indicazioni per hub IoT errori interni del server.

È consigliabile usare gli SDK dei dispositivi IoT di Azure per gestire in modo affidabile le connessioni. Per altre informazioni, consultare Gestire le funzionalità di connettività e messaggistica affidabile con gli Azure IoT Hub SDK per dispositivi

409001 Dispositivo già esistente

Quando si tenta di registrare un dispositivo in hub IoT, è possibile che la richiesta abbia esito negativo con l'errore 409001 DeviceAlreadyExists.

Questo errore si verifica perché è già presente un dispositivo con lo stesso ID dispositivo nell'hub IoT.

Per risolvere questo errore, usare un ID dispositivo diverso e riprovare.

409002 conflitto di creazione del collegamento

È possibile che venga visualizzato l'errore 409002 LinkCreationConflict nei log insieme alla disconnessione del dispositivo o all'errore del messaggio da cloud a dispositivo.

In genere, questo errore si verifica quando hub IoT rileva che un client ha più di una connessione. Infatti, quando arriva una nuova richiesta di connessione per un dispositivo con una connessione esistente, hub IoT chiude la connessione esistente con questo errore.

Nel caso più comune, un problema separato (ad esempio 404104 Dispositivo Connessione ionClosedRemotely) causa la disconnessione del dispositivo. Il dispositivo tenta di ristabilire immediatamente la connessione, ma hub IoT considera ancora il dispositivo connesso. L'hub IoT chiude la connessione precedente e registra questo errore.

In alternativa, la logica sul lato dispositivo difettosa fa sì che il dispositivo stabilisca la connessione quando ne è già aperta una.

Per risolvere questo errore, cercare altri errori nei log che è possibile risolvere perché questo errore viene in genere visualizzato come effetto collaterale di un problema temporaneo diverso. In alternativa, assicurarsi di generare una nuova richiesta di connessione solo se la connessione viene interrotta.

412002 Blocco messaggi dispositivo perso

Quando si tenta di inviare un messaggio da cloud a dispositivo, è possibile che la richiesta non riesca con l'errore 412002 DeviceMessageLockLost.

Questo errore si verifica perché quando un dispositivo riceve un messaggio da cloud a dispositivo dalla coda (ad esempio, usando ReceiveAsync()) il messaggio viene bloccato da hub IoT per una durata di timeout di blocco di un minuto. Se il dispositivo tenta di completare il messaggio dopo la scadenza del timeout di blocco, hub IoT genera questa eccezione.

Se hub IoT non riceve la notifica entro la durata del timeout di blocco di un minuto, imposta nuovamente il messaggio sullo stato accodato. Il dispositivo può tentare di ricevere di nuovo il messaggio. Per evitare che l'errore si verifichi in futuro, implementare la logica lato dispositivo per completare il messaggio entro un minuto dalla ricezione del messaggio. Questo timeout di un minuto non può essere modificato.

429001 eccezione di limitazione

È possibile che le richieste di hub IoT non riescano con l'errore 429001 ThrottlingException.

Questo errore si verifica quando sono stati superati hub IoT limiti di limitazione per l'operazione richiesta.

Per risolvere questo errore, controllare se si raggiunge il limite di limitazione confrontando la metrica dei tentativi di invio dei messaggi di telemetria rispetto ai limiti specificati in precedenza. È anche possibile controllare la metrica Numero di errori di limitazione. Per informazioni su queste metriche, vedere Metriche di telemetria dei dispositivi. Per informazioni sull'uso delle metriche per monitorare l'hub IoT, vedere Monitorare hub IoT.

hub IoT restituisce 429 ThrottlingException solo dopo che il limite è stato violato per un periodo troppo lungo. Questa operazione viene eseguita in modo che i messaggi non vengano eliminati se l'hub IoT riceve il traffico burst. Nel frattempo, l'hub IoT elabora i messaggi alla velocità di limitazione dell'operazione, che potrebbe essere lenta se è presente una quantità eccessiva di traffico nel backlog. Per altre informazioni, vedere Traffic shaping dell'hub IoT.

Prendere in considerazione di aumentare l'hub IoT se si raggiungono le quote o i limiti.

Errori interni 500xxx

Si noterà che la richiesta di hub IoT ha esito negativo con un errore che inizia con 500 e/o una sorta di "errore del server". Alcune possibilità sono:

500001 ServerError: hub IoT si è verificato un problema sul lato server.
500008 GenericTimeout: hub IoT non è stato possibile completare la richiesta di connessione prima del timeout.
ServiceUnavailable (nessun codice di errore): hub IoT rilevato un errore interno.
InternalServerError (nessun codice di errore): hub IoT rilevato un errore interno.

Esistono molte cause per una risposta di errore 500xxx. In tutti i casi, il problema è molto probabilmente temporaneo. Anche se il team dell'hub IoT si impegna costantemente per il mantenimento del contratto di servizio, in piccoli subset di nodi dell'hub IoT possono occasionalmente verificarsi errori temporanei. Quando il dispositivo tenta di connettersi a un nodo in cui si sono verificati problemi, viene visualizzato questo errore.

Per attenuare gli errori di 500xxx, eseguire un nuovo tentativo dal dispositivo. Per gestire automaticamente i tentativi, assicurarsi di usare la versione più recente degli Azure IoT SDK. Per le procedure consigliate sulla gestione degli errori temporanei e la ripetizione dei tentativi, vedere Gestione degli errori temporanei.

Se il problema persiste, controllare Integrità risorse e Stato di Azure per verificare se hub IoT presenta un problema noto. È anche possibile usare la funzionalità di failover manuale.

Se non sono presenti problemi noti e il problema persiste, contattare il supporto tecnico per ulteriori indagini.

503003 Partizione non trovata

È possibile che le richieste di hub IoT non riescano con l'errore 503003 PartitionNotFound.

Questo errore è interno a hub IoT ed è probabilmente temporaneo. Vedere hub IoT errori interni del server.

Per risolvere questo errore, vedere hub IoT errori interni del server.

timeout del gateway 504101

Quando si tenta di richiamare un metodo diretto da hub IoT a un dispositivo, è possibile che la richiesta non riesca con l'errore 504101 GatewayTimeout.

Questo errore si verifica perché hub IoT rilevato un errore e non è stato possibile confermare se il metodo diretto è stato completato prima del timeout. In alternativa, quando si usa una versione precedente di Azure IoT C# SDK (<1.19.0), il collegamento AMQP tra il dispositivo e hub IoT può essere eliminato automaticamente a causa di un bug.

Per risolvere questo errore, eseguire un nuovo tentativo o eseguire l'aggiornamento alla versione più recente di Azure IOT C# SDK.