Condividi tramite

hub IoT supporto MQTT 5 (deprecato)

  • Articolo

Versione: 2.0 api-version: 2020-10-01-preview

Questo documento definisce hub IoT'API del piano dati sul protocollo MQTT versione 5.0. Vedere Informazioni di riferimento sulle API per le definizioni complete in questa API.

Nota

Il supporto di MQTT 5 in hub IoT è deprecato e hub IoT supporta funzionalità limitate per MQTT. Se la soluzione richiede il supporto MQTT v3.1.1 o v5, è consigliabile supportare MQTT in Griglia di eventi di Azure. Per altre informazioni, vedere Confrontare il supporto MQTT in hub IoT e Griglia di eventi.

Prerequisiti

  • Creare un nuovo hub IoT con la modalità di anteprima abilitata. MQTT 5 è disponibile solo in modalità di anteprima e non è possibile passare da un hub IoT esistente alla modalità di anteprima. Per altre informazioni, vedere Abilitare la modalità di anteprima
  • Conoscenza precedente della specifica MQTT 5.

Livello di supporto e limitazioni

hub IoT supporto per MQTT 5 è disponibile in anteprima e limitato nei modi seguenti (comunicati al client tramite CONNACK proprietà, a meno che non diversamente specificato in modo esplicito):

  • Non sono ancora supportati SDK ufficiali per dispositivi Azure IoT.
  • Gli identificatori di sottoscrizione non sono supportati.
  • Le sottoscrizioni condivise non sono supportate.
  • RETAIN non è supportata.
  • Maximum QoS è .1
  • Maximum Packet Size è 256 KiB (soggetto a ulteriori restrizioni per ogni operazione).
  • Gli ID client assegnati non sono supportati.
  • Keep Alive è limitato a 19 min (ritardo massimo per il controllo dell'attività - 28.5 min).
  • Topic Alias Maximum è .10
  • Response Information non è supportato; CONNACK non restituisce Response Information la proprietà anche se CONNECT contiene Request Response Information la proprietà .
  • Receive Maximum (numero massimo di pacchetti non riconosciuti in sospeso PUBLISH consentiti (in direzione client-server) con QoS: 1) è 16.
  • Il client singolo non può avere più di 50 sottoscrizioni. Se un client raggiunge il limite di sottoscrizione, SUBACK restituisce 0x97 il codice motivo (quota superata) per le sottoscrizioni.

Ciclo di vita della connessione

Connessione

Per connettere un client a hub IoT usando questa API, stabilire una connessione per ogni specifica MQTT 5. Il client deve inviare CONNECT un pacchetto entro 30 secondi dopo l'handshake TLS riuscito oppure il server chiude la connessione. Ecco un esempio di CONNECT pacchetto:

-> CONNECT
    Protocol_Version: 5
    Clean_Start: 0
    Client_Id: D1
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    api-version: 2020-10-10
    host: abc.azure-devices.net
    sas-at: 1600987795320
    sas-expiry: 1600987195320
    client-agent: artisan;Linux
  • Authentication Method la proprietà è obbligatoria e identifica il metodo di autenticazione usato. Per altre informazioni sul metodo di autenticazione, vedere Autenticazione.
  • Authentication Data la gestione delle proprietà dipende da Authentication Method. Se Authentication Method è impostato su SAS, Authentication Data è obbligatorio e deve contenere una firma valida. Per altre informazioni sui dati di autenticazione, vedere Autenticazione.
  • api-version la proprietà è obbligatoria e deve essere impostata sul valore della versione dell'API fornito nell'intestazione di questa specifica per applicare questa specifica.
  • host la proprietà definisce il nome host del tenant. È necessario a meno che l'estensione SNI non sia stata presentata nel record Hello client durante l'handshake TLS
  • sas-at definisce l'ora di connessione.
  • sas-expiry definisce l'ora di scadenza per la firma di accesso condiviso fornita.
  • client-agent facoltativamente comunica informazioni sul client che crea la connessione.

Nota

Authentication Method e altre proprietà in tutta la specifica con nomi in maiuscolo sono proprietà di prima classe in MQTT 5. Sono descritte nei dettagli nella specifica MQTT 5. api-versione altre proprietà nel caso trattino sono proprietà utente specifiche per hub IoT API.

hub IoT risponde con CONNACK il pacchetto al termine dell'autenticazione e recupera i dati per supportare la connessione. Se la connessione viene stabilita correttamente, CONNACK ha un aspetto simile al seguente:

<- CONNACK
    Session_Present: 1
    Reason_Code: 0x00
    Session_Expiry_Interval: 0xFFFFFFFF # included only if CONNECT specified value less than 0xFFFFFFFF and more than 0x00
    Receive_Maximum: 16
    Maximum_QoS: 1
    Retain_Available: 0
    Maximum_Packet_Size: 262144
    Topic_Alias_Maximum: 10
    Subscription_Identifiers_Available: 0
    Shared_Subscriptions_Available: 0
    Server_Keep_Alive: 1140 # included only if client did not specify Keep Alive or if it specified a bigger value

Queste CONNACK proprietà del pacchetto seguono la specifica MQTT 5. Riflettono le funzionalità di hub IoT.

Autenticazione

La Authentication Method proprietà nel CONNECT client definisce il tipo di autenticazione usato per questa connessione:

  • SAS- La firma di accesso condiviso è disponibile nella CONNECTproprietà di ,Authentication Data
  • X509 - il client si basa sull'autenticazione del certificato client.

L'autenticazione ha esito negativo se il metodo di autenticazione non corrisponde al metodo configurato del client in hub IoT.

Nota

Questa API richiede Authentication Method che la proprietà sia impostata nel CONNECT pacchetto. Se Authentication Method la proprietà non viene specificata, la connessione non riesce con Bad Request la risposta.

L'autenticazione con nome utente/password usata nelle versioni precedenti dell'API non è supportata.

Firma di accesso condiviso

Con l'autenticazione basata su firma di accesso condiviso, un client deve fornire la firma del contesto di connessione. La firma dimostra l'autenticità della connessione MQTT. La firma deve essere basata su una delle due chiavi di autenticazione nella configurazione del client in hub IoT. Oppure deve essere basato su una delle due chiavi di accesso condiviso di un criterio di accesso condiviso.

La stringa da firmare deve essere formata nel modo seguente:

{host name}\n
{Client Id}\n
{sas-policy}\n
{sas-at}\n
{sas-expiry}\n
  • host name è derivato dall'estensione SNI (presentata dal client nel record Hello client durante l'handshake TLS) o host dalla proprietà utente nel CONNECT pacchetto.
  • Client Id è Identificatore client nel CONNECT pacchetto.
  • sas-policy- se presente, definisce hub IoT criterio di accesso usato per l'autenticazione. Viene codificata come proprietà utente nel CONNECT pacchetto. Facoltativo: omettendolo significa che le impostazioni di autenticazione nel Registro di sistema del dispositivo vengono invece usate.
  • sas-at - se presente, specifica l'ora di connessione - ora corrente. Viene codificata come proprietà utente di time tipo nel CONNECT pacchetto.
  • sas-expiry definisce l'ora di scadenza per l'autenticazione. Si tratta di una timeproprietà utente tipizzata nel CONNECT pacchetto. Questa proprietà è obbligatoria.

Per i parametri facoltativi, se omesso, la stringa vuota DEVE essere usata invece nella stringa per firmare.

HMAC-SHA256 viene usato per eseguire l'hashing della stringa in base a una delle chiavi simmetriche del dispositivo. Il valore hash viene quindi impostato come valore della Authentication Data proprietà .

X509

Se Authentication Method la proprietà è impostata su X509, hub IoT autentica la connessione in base al certificato client specificato.

Riautenticazione

Se si usa l'autenticazione basata su firma di accesso condiviso, è consigliabile usare token di autenticazione di breve durata. Per mantenere autenticata la connessione e impedire la disconnessione a causa della scadenza, il client deve ripetere l'autenticazione inviando AUTH un pacchetto con Reason Code: 0x19 (riautenticazione):

-> AUTH
    Reason_Code: 0x19
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    sas-at: {current time}
    sas-expiry: {SAS expiry time}

Regole:

  • Authentication Method deve essere uguale a quello usato per l'autenticazione iniziale
  • se la connessione è stata originariamente autenticata usando la firma di accesso condiviso in base ai criteri di accesso condiviso, la firma usata nella riautenticazione deve essere basata sugli stessi criteri.

Se la riautenticazione ha esito positivo, hub IoT invia AUTH un pacchetto con Reason Code: 0x00 (esito positivo). In caso contrario, hub IoT invia DISCONNECT un pacchetto con Reason Code: 0x87 (non autorizzato) e chiude la connessione.

Sconnessione

Il server può disconnettere il client per alcuni motivi, tra cui:

  • il comportamento errato del cliente in un modo che è impossibile rispondere con riconoscimento negativo (o risposta) direttamente,
  • server non riesce a mantenere aggiornato lo stato della connessione,
  • un altro client si connette con la stessa identità.

Il server può disconnettersi con qualsiasi codice motivo definito nella specifica MQTT 5.0. Menzioni rilevanti:

  • 135 (Non autorizzato) quando la riautenticazione ha esito negativo, il token di firma di accesso condiviso corrente scade o la modifica delle credenziali del dispositivo.
  • 142 (Sessione acquisita) quando è stata aperta una nuova connessione con la stessa identità client.
  • 159 (Frequenza di connessione superata) quando la frequenza di connessione per l'hub IoT supera il limite.
  • 131 (Errore specifico dell'implementazione) viene usato per eventuali errori personalizzati definiti in questa API. status e reason le proprietà vengono usate per comunicare altri dettagli sulla causa della disconnessione (vedere Risposta per informazioni dettagliate).

Operazioni

Tutte le funzionalità di questa API vengono espresse come operazioni. Di seguito è riportato un esempio di operazione di invio dei dati di telemetria:

-> PUBLISH
    QoS: 1
    Packet_Id: 3
    Topic: $iothub/telemetry
    Payload: Hello

<- PUBACK
    Packet_Id: 3
    Reason_Code: 0

Per una specifica completa delle operazioni in questa API, vedere hub IoT informazioni di riferimento sulle API MQTT 5 del piano dati.

Nota

Tutti gli esempi in questa specifica vengono visualizzati dal punto di vista del client. Il segno -> indica l'invio di pacchetti da parte del client, <- ovvero la ricezione.

Argomenti e sottoscrizioni dei messaggi

Gli argomenti usati nei messaggi delle operazioni in questa API iniziano con $iothub/. La semantica del broker MQTT non si applica a queste operazioni (vedere "Argomenti che iniziano con $" per informazioni dettagliate). Gli argomenti che iniziano con $iothub/ che non sono definiti in questa API non sono supportati:

  • Invio di messaggi a risultati non definiti dell'argomento in Not Found risposta (vedere Risposta per informazioni dettagliate),
  • La sottoscrizione a un argomento non definito restituisce SUBACK con Reason Code: 0x8F (Filtro argomento non valido).

I nomi degli argomenti e i nomi delle proprietà fanno distinzione tra maiuscole e minuscole e devono corrispondere esattamente. Ad esempio, $iothub/telemetry/ non è supportato mentre $iothub/telemetry è.

Nota

I caratteri jolly nelle sottoscrizioni $iothub/.. non sono supportati. Ovvero, un client non può sottoscrivere $iothub/+ o $iothub/#. Se si tenta di eseguire questa operazione, SUBACK si ottiene con Reason Code: 0xA2 (Le sottoscrizioni con caratteri jolly non sono supportate). Sono supportati solo i caratteri jolly a segmento singolo (+) anziché i parametri di percorso nel nome dell'argomento per le operazioni che le hanno.

Tipi di interazione

Tutte le operazioni in questa API sono basate su uno dei due tipi di interazione:

  • Messaggio con riconoscimento facoltativo (MessageAck)
  • Request-Response (ReqRep)

Le operazioni variano anche in base alla direzione (determinata dalla direzione del messaggio iniziale in scambio):

  • Da client a server (c2s)
  • Da server a client (s2c)

Ad esempio, Send Telemetry is Client-to-Server operation of "Message with acknowledgementment", while Handle Direct Method is Server-to-Client operation of Request-Response type.

Interazioni con riconoscimento dei messaggi

L'interazione del messaggio con riconoscimento facoltativo (MessageAck) viene espressa come scambio di PUBLISH pacchetti e PUBACK in MQTT. Il riconoscimento è facoltativo e il mittente può scegliere di non richiederlo inviando PUBLISH un pacchetto con QoS: 0.

Nota

Se le proprietà nel PUBACK pacchetto devono essere troncate a Maximum Packet Size causa di dichiarate dal client, hub IoT manterrà il numero di proprietà User che può rientrare nel limite specificato. Le proprietà utente elencate per prime hanno maggiori probabilità di essere inviate rispetto a quelle elencate in un secondo momento; Reason String la proprietà ha la priorità minima.

Esempio di semplice interazione di MessageAck

Messaggio:

PUBLISH
    QoS: 1
    Packet_Id: 34
    Topic: $iothub/{request.path}
    Payload: <any>

Riconoscimento (esito positivo):

PUBACK
    Packet_Id: 34
    Reason_Code: 0

Interazioni con richiesta-risposta

Nelle interazioni Request-Response (ReqRep) entrambe le interazioni request e response si traducono in PUBLISH pacchetti con QoS: 0.

Correlation Data la proprietà deve essere impostata in entrambi e viene usata per associare il pacchetto di risposta al pacchetto Request.

Questa API usa un singolo argomento $iothub/responses di risposta per tutte le operazioni ReqRep. La sottoscrizione a/annullamento della sottoscrizione da questo argomento per le operazioni da client a server non è necessaria. Il server presuppone che tutti i client siano sottoscritti.

Esempio di interazione ReqRep semplice

Richiesta:

PUBLISH
    QoS: 0
    Topic: $iothub/{request.path}
    Correlation_Data: 0x01 0xFA
    Payload: ...

Risposta (esito positivo):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: ...

Le interazioni reqRep non supportano PUBLISH pacchetti con QoS: 1 come messaggi di richiesta o risposta. Invio dei risultati della richiesta PUBLISH in Bad Request risposta.

La lunghezza massima supportata nella Correlation Data proprietà è di 16 byte. Se Correlation Data la proprietà nel PUBLISH pacchetto è impostata su un valore maggiore di 16 byte, hub IoT invia DISCONNECT con Bad Request risultato e chiude la connessione. Questo comportamento si applica solo ai pacchetti scambiati all'interno di questa API.

Nota

I dati di correlazione sono una sequenza di byte arbitrari, ad esempio non è garantito che sia una stringa UTF-8.

ReqRep usa argomenti predefiniti per la risposta; La proprietà Response Topic in Request PUBLISH packet (se impostata dal mittente) viene ignorata.

hub IoT sottoscrive automaticamente gli argomenti di risposta del client per tutte le operazioni ReqRep da client a server. Anche se il client annulla esplicitamente la sottoscrizione dall'argomento di risposta, hub IoT reinserirà automaticamente la sottoscrizione. Per le interazioni reqRep da server a client, è comunque necessario che il dispositivo sottoscriva.

Proprietà del messaggio

Le proprietà dell'operazione , di sistema o definite dall'utente, sono espresse come proprietà del pacchetto in MQTT 5.

I nomi delle proprietà utente fanno distinzione tra maiuscole e minuscole e devono essere digitati esattamente come definito. Ad esempio, Trace-ID non è supportato mentre trace-id è.

Le richieste con proprietà utente esterne alla specifica e senza prefisso @ generano un errore.

Le proprietà di sistema vengono codificate come proprietà di prima classe ,ad esempio Content Type, o come proprietà utente. Specifica fornisce un elenco completo delle proprietà di sistema supportate. Tutte le proprietà della prima classe vengono ignorate, a meno che il supporto non sia indicato in modo esplicito nella specifica.

Se sono consentite proprietà definite dall'utente, i nomi devono seguire il formato @{property name}. Le proprietà definite dall'utente supportano solo valori stringa UTF-8 validi. Ad esempio, MyProperty1 la proprietà con valore 15 deve essere codificata come proprietà User con nome @MyProperty e valore 15.

Se hub IoT non riconosce la proprietà User, viene considerata un errore e hub IoT risponde con PUBACK Reason Code: 0x83 (errore specifico dell'implementazione) e status: 0100 (richiesta non valida). Se il riconoscimento non è stato richiesto (QoS: 0), DISCONNECT il pacchetto con lo stesso errore viene restituito e la connessione viene terminata.

Questa API definisce i tipi di dati seguenti oltre a string:

  • time: numero di millisecondi da 1970-01-01T00:00:00.000Z. ad esempio, 1600987195320 per 2020-09-24T22:39:55.320Z,
  • u32: numero intero senza segno a 32 bit,
  • u64: numero intero senza segno a 64 bit,
  • i32: numero intero a 32 bit con segno.

Response

Le interazioni possono comportare risultati diversi: Success, Bad Request, Not Founde altri. I risultati sono distinti l'uno dall'altro in base alla status proprietà dell'utente. Reason Code nei PUBACK pacchetti (per le interazioni di MessageAck) corrisponde status nel significato dove possibile.

Nota

Se il client specifica Request Problem Information: 0 nel pacchetto CONNECT, nessuna proprietà utente verrà inviata ai PUBACK pacchetti in modo che siano conformi alla specifica MQTT 5, inclusa status la proprietà . In questo caso, il client può comunque basarsi su Reason Code per determinare se il riconoscimento è positivo o negativo.

Ogni interazione ha un valore predefinito (o esito positivo). Reason Code Ha la 0 proprietà e status di "non impostata". Altrimenti:

  • Per le interazioni di MessageAck, PUBACK ottiene un valore Reason Code diverso da 0x0 (Operazione riuscita). status può essere presente per chiarire ulteriormente il risultato.
  • Per le interazioni reqRep, response PUBLISH ottiene il status set di proprietà.
  • Poiché non è possibile rispondere direttamente alle interazioni messageAck con QoS: 0 , DISCONNECT il pacchetto viene inviato invece con informazioni di risposta, seguito da disconnessione.

Esempi:

Richiesta non valida (MessageAck):

PUBACK
    Reason_Code: 131
    status: 0100
    reason: Unknown property `test`

Non autorizzato (MessageAck):

PUBACK
    Reason_Code: 135
    status: 0101

Non autorizzato (ReqRep):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: ...
    status: 0101

Quando necessario, hub IoT imposta le proprietà utente seguenti:

  • status- codice esteso di hub IoT per lo stato dell'operazione. Questo codice può essere usato per distinguere i risultati.
  • trace-id– ID di traccia per l'operazione; hub IoT può mantenere più diagnostica relativa all'operazione che può essere usata per l'indagine interna.
  • reason - messaggio leggibile che fornisce ulteriori informazioni sul motivo per cui l'operazione è terminata in uno stato indicato dalla status proprietà.

Nota

Se il client imposta Maximum Packet Size la proprietà nel pacchetto CONNECT su un valore molto piccolo, non tutte le proprietà utente possono adattarsi e non verranno visualizzate nel pacchetto.

reason è destinato solo alle persone e non deve essere usato nella logica client. Questa API consente di modificare i messaggi in qualsiasi momento senza avviso o modifica della versione.

Se il client invia RequestProblemInformation: 0 nel pacchetto CONNECT, le proprietà utente non verranno incluse negli acknowledgement per ogni specifica MQTT 5.

Codice di stato

status la proprietà contiene il codice di stato per l'operazione. È ottimizzato per l'efficienza di lettura dei computer. È costituito da un intero senza segno a due byte codificato come esadecimale in stringa come 0501. Struttura del codice (mappa bit):

7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
0 0 0 0 0 R T T | C C C C C C C C

Il primo byte viene usato per i flag:

  • bit 0 e 1 indicano il tipo di risultati:
    • 00 -successo
    • 01 - Errore del client
    • 10 - Errore del server
  • bit 2: 1 indica che l'errore è riprovabile
  • i bit da 3 a 7 sono riservati e devono essere impostati su 0

Il secondo byte contiene codice di risposta distinto effettivo. I codici di errore con flag diversi possono avere lo stesso valore di byte secondo. Ad esempio, possono essere presenti 0001codici di errore , 01010201, , 0301 con un significato distinto.

Ad esempio, Too Many Requests è un client, errore ritentabile con codice personalizzato di 1. Il valore è 0000 0101 0000 0001 o 0x0501.

I client possono usare bit di tipo per identificare se l'operazione è stata completata correttamente. I client possono anche usare bit riprovabile per decidere se è opportuno ripetere l'operazione.

Consigli

Gestione della sessione

CONNACK il pacchetto contiene Session Present la proprietà per indicare se la sessione creata in precedenza è stata ripristinata dal server. Utilizzare questa proprietà per determinare se sottoscrivere gli argomenti o ignorare la sottoscrizione dopo che la sottoscrizione è stata eseguita in precedenza.

Per basarsi su Session Present, il client deve tenere traccia delle sottoscrizioni effettuate (ovvero, i pacchetti inviati SUBSCRIBE e ricevuti SUBACK con codice motivo riuscito) o assicurarsi di sottoscrivere tutti gli argomenti in un unico SUBSCRIBE/SUBACK scambio. In caso contrario, se il client invia due SUBSCRIBE pacchetti e il server li elabora correttamente, il server comunica Session Present: 1 in CONNACK mentre ha solo una parte delle sottoscrizioni del client accettate.

Per evitare il caso in cui una versione precedente del client non abbia sottoscritto tutti gli argomenti, è preferibile sottoscrivere in modo incondizionato quando il comportamento del client cambia (ad esempio, come parte dell'aggiornamento del firmware). Inoltre, per garantire che non vengano lasciate sottoscrizioni non aggiornati (prendendo dal numero massimo consentito di sottoscrizioni), annullare esplicitamente la sottoscrizione alle sottoscrizioni che non sono più in uso.

Batch

Non esiste un formato speciale per inviare un batch di messaggi. Per ridurre il sovraccarico delle operazioni a elevato utilizzo di risorse in TLS e rete, aggregare pacchetti (PUBLISH, PUBACK, SUBSCRIBEe così via) insieme prima di distribuirli allo stack TLS/TCP sottostante. Inoltre, il client può semplificare l'alias dell'argomento all'interno del "batch":

  • Inserire il nome dell'argomento completo nel primo PUBLISH pacchetto per la connessione e associarlo all'alias dell'argomento,
  • Inserire i pacchetti seguenti per lo stesso argomento con il nome dell'argomento vuoto e la proprietà alias dell'argomento.

Migrazione

Questa sezione elenca le modifiche apportate all'API rispetto al supporto MQTT precedente.

  • Il protocollo di trasporto è MQTT 5. In precedenza - MQTT 3.1.1.
  • Le informazioni di contesto per l'autenticazione di firma di accesso condiviso sono contenute direttamente nel CONNECT pacchetto anziché essere codificate insieme alla firma.
  • Il metodo di autenticazione viene usato per indicare il metodo di autenticazione usato.
  • La firma di accesso condiviso viene inserita nella proprietà Authentication Data. In precedenza è stato usato il campo Password.
  • Gli argomenti per le operazioni sono diversi:
    • Telemetria: $iothub/telemetry invece di devices/{Client Id}/messages/events,
    • Comandi: $iothub/commands invece di devices/{Client Id}/messages/devicebound,
    • Patch Twin Segnalata: $iothub/twin/patch/reported invece di $iothub/twin/PATCH/properties/reported,
    • Notifica allo stato desiderato del dispositivo gemello modificato: $iothub/twin/patch/desired invece di $iothub/twin/PATCH/properties/desired.
  • La sottoscrizione per l'argomento risposta delle operazioni di richiesta/risposta client-server non è necessaria.
  • Le proprietà utente vengono usate anziché le proprietà di codifica nel segmento del nome dell'argomento.
  • i nomi delle proprietà vengono digitati nella convenzione di denominazione "dash-case" anziché nelle abbreviazioni con prefisso speciale. Le proprietà definite dall'utente richiedono ora il prefisso. Ad esempio, $.mid è ora message-id, mentre myProperty1 diventa @myProperty1.
  • La proprietà Dati di correlazione viene usata per correlare i messaggi di richiesta e risposta per le operazioni di richiesta-risposta anziché la $rid proprietà codificata nell'argomento.
  • iothub-connection-auth-method la proprietà non viene più contrassegnata sugli eventi di telemetria.
  • I comandi C2D non vengono eliminati in assenza di sottoscrizione dal dispositivo. Rimangono in coda fino a quando il dispositivo non sottoscrive o scade.

Esempi

Inviare dati di telemetria

Messaggio:

-> PUBLISH
    QoS: 1
    Packet_Id: 31
    Topic: $iothub/telemetry
    @myProperty1: My String Value # optional
    creation-time: 1600987195320 # optional
    @ No_Rules-ForUser-PROPERTIES: Any UTF-8 string value # optional
    Payload: <data>

Riconoscimento:

<- PUBACK
    Packet_Id: 31
    Reason_Code: 0

Riconoscimento alternativo (limitato):

<- PUBACK
    Packet_Id: 31
    Reason_Code: 151
    status: 0501

Invia lo stato del gemello

Richiesta:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/get
    Correlation_Data: 0x01 0xFA
    Payload: <empty>

Risposta (esito positivo):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: <twin/desired state>

Risposta (non consentita):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    status: 0102
    reason: Operation not allowed for `B2` SKU
    Payload: <empty>

Gestire la chiamata al metodo diretto

Richiesta:

<- PUBLISH
    QoS: 0
    Topic: $iothub/methods/abc
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Risposta (esito positivo):

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    response-code: 200 # user defined response code
    Payload: <data>

Nota

status non è impostato: si tratta di una risposta riuscita.

Risposta dispositivo non disponibile:

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    status: 0603

Errore durante l'uso di QoS 0, parte 1

Richiesta:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/gett # misspelled topic name - server won't recognize it as Request-Response interaction
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Risposta:

<- DISCONNECT
    Reason_Code: 144
    reason: "Unsupported topic: `$iothub/twin/gett`"

Errore durante l'uso di QoS 0, parte 2

Richiesta:

-> PUBLISH # missing Correlation Data
    QoS: 0
    Topic: $iothub/twin/get
    Payload: <data>

Risposta:

<- DISCONNECT
    Reason_Code: 131
    status: 0100
    reason: "`Correlation Data` property is missing"

Passaggi successivi