Sdílet prostřednictvím

Podpora IoT Hub MQTT 5 (zastaralá)

  • Článek

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

Tento dokument definuje rozhraní API roviny dat ioT Hubu přes protokol MQTT verze 5.0. Kompletní definice v tomto rozhraní API najdete v referenčních informacích k rozhraní API.

Poznámka:

Podpora MQTT 5 ve službě IoT Hub je zastaralá a IoT Hub má omezenou podporu funkcí pro MQTT. Pokud vaše řešení potřebuje podporu MQTT v3.1.1 nebo v5, doporučujeme podporu MQTT ve službě Azure Event Grid. Další informace najdete v tématu Porovnání podpory MQTT ve službě IoT Hub a Event Gridu.

Požadavky

  • Vytvořte zcela nové centrum IoT s povoleným režimem náhledu. MQTT 5 je k dispozici pouze v režimu náhledu a existující centrum IoT Hub nemůžete přepnout do režimu náhledu. Další informace najdete v tématu Povolení režimu náhledu.
  • Předchozí znalost specifikace MQTT 5

Úroveň podpory a omezení

Podpora služby IoT Hub pro MQTT 5 je ve verzi Preview a omezuje se následujícími způsoby (informace o klientech prostřednictvím CONNACK vlastností, pokud není výslovně uvedeno jinak):

  • Žádné oficiální sady SDK pro zařízení Azure IoT zatím nepodporují.
  • Identifikátory předplatného se nepodporují.
  • Sdílená předplatná nejsou podporovaná.
  • RETAIN není podporováno.
  • Maximum QoS je 1.
  • Maximum Packet Size je 256 KiB (s výhradou dalších omezení pro každou operaci).
  • Přiřazené ID klientů se nepodporují.
  • Keep Alive je omezena na 19 min (maximální prodleva kontroly liveness – 28.5 min).
  • Topic Alias Maximum je 10.
  • Response Information není podporováno; CONNACK nevrací Response Information vlastnost, i když CONNECT obsahuje Request Response Information vlastnost.
  • Receive Maximum (maximální povolený počet nevyřízených nevyřízených PUBLISH paketů (ve směru klienta-server) s QoS: 1) je 16.
  • Jeden klient nemůže mít více než 50 předplatná. Pokud klient dosáhne limitu předplatného, SUBACK vrátí 0x97 kód důvodu (překročení kvóty) pro předplatná.

Životní cyklus připojení

Connection

Pokud chcete pomocí tohoto rozhraní API připojit klienta ke službě IoT Hub, navazujte připojení podle specifikace MQTT 5. Klient musí odesílat CONNECT pakety do 30 sekund po úspěšném použití metody handshake protokolu TLS nebo server připojení zavře. Tady je příklad paketu CONNECT :

-> 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 vlastnost je povinná a určuje, kterou metodu ověřování se používá. Další informace o metodě ověřování najdete v tématu Ověřování.
  • Authentication Data zpracování majetku závisí na Authentication Method. Je-li Authentication Method nastavena na SAShodnotu , Authentication Data je nutné a musí obsahovat platný podpis. Další informace o ověřovacích datech najdete v tématu Ověřování.
  • api-version vlastnost je povinná a musí být nastavena na hodnotu verze rozhraní API zadanou v hlavičce této specifikace, aby se tato specifikace použila.
  • host vlastnost definuje název hostitele tenanta. Vyžaduje se, pokud se během handshakeu TLS nezobrazí rozšíření SNI v záznamu Hello klienta.
  • sas-at definuje čas připojení.
  • sas-expiry definuje dobu vypršení platnosti zadaného sdíleného přístupového podpisu.
  • client-agent volitelně sdělí informace o klientovi, který vytváří připojení.

Poznámka:

Authentication Method a další vlastnosti v celé specifikaci s velkými písmeny jsou vlastnosti první třídy v MQTT 5 – jsou popsány v podrobnostech ve specifikaci MQTT 5. api-version a další vlastnosti v případě pomlčky jsou vlastnosti uživatele specifické pro rozhraní API služby IoT Hub.

IoT Hub po dokončení ověřování odpoví paketem CONNACK a načte data pro podporu připojení. Pokud se připojení úspěšně naváže, CONNACK vypadá to takto:

<- 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

Tyto CONNACK vlastnosti paketů odpovídají specifikaci MQTT 5. Odrážejí možnosti služby IoT Hub.

Ověřování

Vlastnost Authentication Method na CONNECT klientovi definuje, jaký druh ověřování používá pro toto připojení:

  • SAS- Sdílený přístupový podpis je k dispozici ve CONNECTAuthentication Data vlastnosti,
  • X509 – klient spoléhá na ověřování klientských certifikátů.

Ověřování selže, pokud metoda ověřování neodpovídá nakonfigurované metodě klienta ve službě IoT Hub.

Poznámka:

Toto rozhraní API vyžaduje Authentication Method , aby byla vlastnost nastavena v CONNECT paketu. Pokud Authentication Method vlastnost není k dispozici, připojení selže s Bad Request odpovědí.

Ověřování pomocí uživatelského jména a hesla použité v předchozích verzích rozhraní API se nepodporuje.

SAS

Při ověřování založeném na SAS musí klient zadat podpis kontextu připojení. Podpis prokáže pravost připojení MQTT. Podpis musí být založený na jednom ze dvou ověřovacích klíčů v konfiguraci klienta ve službě IoT Hub. Nebo musí být založená na jednom ze dvou sdílených přístupových klíčů zásad sdíleného přístupu.

Řetězec k podepsání musí být vytvořen následujícím způsobem:

{host name}\n
{Client Id}\n
{sas-policy}\n
{sas-at}\n
{sas-expiry}\n
  • host name je odvozena buď z rozšíření SNI (prezentované klientem v záznamu Client Hello během metody handshake protokolu TLS) nebo host vlastnost uživatele v paketu CONNECT .
  • Client Id je identifikátor klienta v CONNECT paketu.
  • sas-policy – pokud je k dispozici, definuje zásady přístupu ke službě IoT Hub používané pro ověřování. Kóduje se jako vlastnost uživatele v CONNECT paketu. Volitelné: Vynechání znamená, že se místo toho použijí nastavení ověřování v registru zařízení.
  • sas-at – pokud je k dispozici, určuje čas připojení – aktuální čas. Je kódován jako vlastnost time uživatele typu v CONNECT paketu.
  • sas-expiry definuje dobu vypršení platnosti ověřování. Jedná se o timevlastnost uživatele typu typ paketu CONNECT . Tato vlastnost je povinná.

Pro volitelné parametry, pokud je vynechán, musí být prázdný řetězec použit místo v řetězci pro podepsání.

HMAC-SHA256 slouží k hashování řetězce na základě jednoho ze symetrických klíčů zařízení. Hodnota hash se pak nastaví jako hodnota Authentication Data vlastnosti.

X509

Pokud Authentication Method je vlastnost nastavená na X509, IoT Hub ověří připojení na základě poskytnutého klientského certifikátu.

Opětovné ověření

Pokud se používá ověřování založené na SAS, doporučujeme používat krátkodobé ověřovací tokeny. Aby bylo připojení ověřené a aby se zabránilo odpojení kvůli vypršení platnosti, klient se musí znovu ověřit odesláním AUTH paketu ( Reason Code: 0x19 opětovné ověření):

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

Pravidla:

  • Authentication Method musí být stejná jako ta, která se používá k počátečnímu ověřování.
  • Pokud bylo připojení původně ověřeno pomocí SAS na základě zásad sdíleného přístupu, podpis použitý při opětovném ověření musí být založený na stejné zásadě.

Pokud je opětovné ověření úspěšné, IoT Hub odešle AUTH paket s Reason Code: 0x00 (úspěchem). V opačném případě IoT Hub odesílá DISCONNECT paket s Reason Code: 0x87 (neautorizuje) a ukončí připojení.

Odpojení

Server může klienta odpojit z několika důvodů, mezi které patří:

  • klient se chová špatně způsobem, který není možné odpovědět negativním potvrzením (nebo odpovědí) přímo,
  • serveru se nedaří udržovat stav připojení aktuální,
  • jiný klient se připojuje se stejnou identitou.

Server se může odpojit od kódu z jakéhokoli důvodu definovaného ve specifikaci MQTT 5.0. Notable zmínky:

  • 135 (Neautorizuje se) při selhání opětovného ověření, vypršení platnosti aktuálního tokenu SAS nebo změně přihlašovacích údajů zařízení.
  • 142 (Relace převzala) při otevření nového připojení se stejnou identitou klienta.
  • 159 (Překročila se rychlost připojení) pokud rychlost připojení pro centrum IoT překročí limit.
  • 131 (Chyba specifická pro implementaci) se používá pro všechny vlastní chyby definované v tomto rozhraní API. status a reason vlastnosti slouží ke sdělení dalších podrobností o příčině odpojení (viz odpověď s podrobnostmi).

Operace

Všechny funkce v tomto rozhraní API jsou vyjádřeny jako operace. Tady je příklad operace Odesílání telemetrie:

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

<- PUBACK
    Packet_Id: 3
    Reason_Code: 0

Kompletní specifikaci operací v tomto rozhraní API najdete v referenčních informacích k rozhraní API roviny dat ioT Hubu MQTT 5.

Poznámka:

Všechny ukázky v této specifikaci se zobrazují z pohledu klienta. Znaménko -> znamená, že klient odesílá paket – <- příjem.

Témata a odběry zpráv

Témata používaná ve zprávách operací v tomto rozhraní API začínají na $iothub/. Sémantika zprostředkovatele MQTT se na tyto operace nevztahuje (podrobnosti najdete v tématu Témata začínající na $). Témata, která $iothub/ začínají tím, že nejsou definovaná v tomto rozhraní API, nejsou podporovaná:

  • Odeslání zpráv do nedefinovaných výsledků tématu v Not Found odpovědi (podrobnosti najdete v části Odpověď ),
  • Přihlášení k odběru nedefinovaného tématu má za následek SUBACK Reason Code: 0x8F (filtr témat je neplatný).

V názvech témat a názvech vlastností se rozlišují malá a velká písmena a musí se přesně shodovat. Například v době, $iothub/telemetry/ kdy $iothub/telemetry je tato funkce, není podporovaná.

Poznámka:

Zástupné cardy v předplatných $iothub/.. nejsou podporované. To znamená, že klient se nemůže přihlásit k odběru $iothub/+ nebo $iothub/#. Při pokusu o to bude výsledkem SUBACK (nepodporovaná předplatná se zástupnými Reason Code: 0xA2 cardy). Pro operace, které je obsahují, se podporují pouze zástupné cardy s jedním segmentem (+) místo parametrů cesty v názvu tématu.

Typy interakcí

Všechny operace v tomto rozhraní API jsou založené na jednom ze dvou typů interakcí:

  • Zpráva s volitelným potvrzením (MessageAck)
  • Request-Response (ReqRep)

Operace se také liší podle směru (podle směru počáteční zprávy v výměně):

  • Klient-server (c2s)
  • Server-to-Client (s2c)

Například send telemetry is Client-to-Server operation of "Message with potvrzení" type, zatímco Handle Direct Method is Server-to-Client operation of Request-Response type.

Interakce s potvrzením zpráv

Zpráva s volitelnou interakcí potvrzení (MessageAck) je vyjádřena jako výměna PUBLISH PUBACK paketů v MQTT. Potvrzení je volitelné a odesílatel si ho může vyžádat odesláním PUBLISH paketu s QoS: 0.

Poznámka:

Pokud musí být vlastnosti v PUBACK paketu zkráceny z důvodu Maximum Packet Size deklarování klientem, IoT Hub zachová tolik vlastností uživatele, kolik se může vejít do daného limitu. Vlastnosti uživatele uvedené jako první mají větší šanci odeslat než vlastnosti uvedené později; Reason String vlastnost má nejnižší prioritu.

Příklad jednoduché interakce MessageAck

Zpráva:

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

Potvrzení (úspěch):

PUBACK
    Packet_Id: 34
    Reason_Code: 0

Interakce požadavků a odpovědí

V interakcích Request-Response (ReqRep) se požadavek i odpověď překládají do PUBLISH paketů s QoS: 0.

Correlation Data vlastnost musí být nastavena v obou a používá se k porovnávání paketu odpovědi na paket požadavku.

Toto rozhraní API používá jedno téma $iothub/responses odpovědi pro všechny operace ReqRep. Přihlášení k odběru nebo zrušení odběru z tohoto tématu pro operace mezi klientem a serverem není povinné – server předpokládá, že se mají přihlásit k odběru všichni klienti.

Příklad jednoduché interakce ReqRep

Požadavek:

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

Odpověď (úspěch):

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

Interakce ReqRep nepodporují PUBLISH pakety jako QoS: 1 zprávy požadavků nebo odpovědí. Odeslání výsledků požadavku PUBLISH v Bad Request odpovědi

Maximální délka podporovaná ve Correlation Data vlastnosti je 16 bajtů. Pokud Correlation Data je vlastnost paketu PUBLISH nastavena na hodnotu delší než 16 bajtů, IoT Hub odešle DISCONNECT výsledek Bad Request a zavře připojení. Toto chování se vztahuje pouze na pakety vyměňované v rámci tohoto rozhraní API.

Poznámka:

Data korelace jsou libovolná bajtová sekvence, například není zaručeno, že se jedná o řetězec UTF-8.

ReqRep použít předdefinovaná témata pro odpověď; Vlastnost Téma odpovědi v paketu požadavku PUBLISH (pokud je nastavena odesílatelem) je ignorována.

IoT Hub automaticky přihlásí klienta k odběru témat odpovědí pro všechny operace ReqRep mezi klienty. I když se klient výslovně odhlásí z tématu odpovědi, IoT Hub automaticky obnoví předplatné. U interakcí ReqRep mezi servery je stále nutné, aby se zařízení přihlásilo k odběru.

Vlastnosti zprávy

Vlastnosti operací – systém nebo uživatelem definované – jsou vyjádřeny jako vlastnosti paketů v MQTT 5.

Uživatelská jména vlastností rozlišují malá a velká písmena a musí být napsaná přesně tak, jak je definována. Například v době, Trace-ID kdy trace-id je tato funkce, není podporovaná.

Požadavky s vlastnostmi uživatele mimo specifikaci a bez předpony @ způsobí chybu.

Systémové vlastnosti jsou kódovány buď jako vlastnosti první třídy (například Content Type) nebo jako vlastnosti uživatele. Specifikace poskytuje úplný seznam podporovaných vlastností systému. Všechny vlastnosti první třídy jsou ignorovány, pokud není v specifikaci výslovně uvedena podpora.

Pokud jsou povoleny uživatelsky definované vlastnosti, musí jejich názvy následovat ve formátu @{property name}. Uživatelem definované vlastnosti podporují pouze platné řetězcové hodnoty UTF-8. Vlastnost s hodnotou 15 musí být například MyProperty1 zakódována jako vlastnost User s názvem @MyProperty a hodnotou 15.

Pokud IoT Hub nerozpozná vlastnost User, považuje se za chybu a Služba IoT Hub odpoví chybou PUBACK Reason Code: 0x83 (chyba specifická pro implementaci) a status: 0100 (Chybný požadavek). Pokud potvrzení nebylo požadováno (QoS: 0), DISCONNECT paket se stejnou chybou se odešle zpět a připojení se ukončí.

Toto rozhraní API definuje kromě toho stringnásledující datové typy:

  • time: počet milisekund od 1970-01-01T00:00:00.000Z. například 1600987195320 pro 2020-09-24T22:39:55.320Z,
  • u32: 32bitové celé číslo bez znaménka,
  • u64: 64bitové celé číslo bez znaménka,
  • i32: 32bitové celé číslo.

Response

Interakce můžou mít za následek různé výsledky: Success, Bad Request, Not Founda další. Výsledky se navzájem rozlišují podle status vlastnosti uživatele. Reason Code v PUBACK paketech (pro interakce MessageAck) odpovídá status , pokud je to možné.

Poznámka:

Pokud klient zadá Request Problem Information: 0 paket CONNECT, nebudou u PUBACK paketů odeslány žádné vlastnosti uživatele, aby byly v souladu se specifikací MQTT 5, včetně status vlastnosti. V takovém případě se klient stále může spolehnout na Reason Code určení, jestli je potvrzení kladné nebo záporné.

Každá interakce má výchozí (nebo úspěch). Reason Code Má vlastnost 0 "statusnot set". Jinak:

  • Pro interakce PUBACK MessageAck získá Reason Code jiné než 0x0 (úspěch). status mohou být přítomny k dalšímu objasnění výsledku.
  • V případě interakcí ReqRep získá status Response PUBLISH sadu vlastností.
  • Vzhledem k tomu, že neexistuje způsob, jak reagovat na interakce QoS: 0 MessageAck přímo, DISCONNECT paket se odešle místo toho s informacemi o odpovědi a následným odpojením.

Příklady:

Chybný požadavek (MessageAck):

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

Not Authorized (MessageAck):

PUBACK
    Reason_Code: 135
    status: 0101

Not Authorized (ReqRep):

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

V případě potřeby IoT Hub nastaví následující vlastnosti uživatele:

  • status – Rozšířený kód služby IoT Hub pro stav operace. Tento kód lze použít k rozlišení výsledků.
  • trace-id – ID trasování pro operaci; IoT Hub může udržovat další diagnostiku týkající se operace, která by se dala použít k internímu šetření.
  • reason - zprávu čitelný člověkem, která poskytuje další informace o tom, proč operace skončila ve stavu označeném status vlastností.

Poznámka:

Pokud klient nastaví Maximum Packet Size vlastnost v paketu CONNECT na velmi malou hodnotu, nemusí se všechny vlastnosti uživatele vejít a nezobrazí se v paketu.

reason je určen pouze pro lidi a neměl by se používat v klientské logice. Toto rozhraní API umožňuje, aby se zprávy v libovolném okamžiku měnily bez upozornění nebo změny verze.

Pokud klient odešle RequestProblemInformation: 0 paket CONNECT, nebudou vlastnosti uživatele zahrnuty do potvrzení podle specifikace MQTT 5.

Stavový kód

status vlastnost má stavový kód pro operaci. Je optimalizovaná pro efektivitu strojového čtení. Skládá se z dvoubajtů bez znaménka zakódované jako šestnáctkové v řetězci jako 0501. Struktura kódu (bitová mapa):

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

První bajt se používá pro příznaky:

  • Bity 0 a 1 označují typ výsledků:
    • 00 -úspěch
    • 01 – chyba klienta
    • 10 – chyba serveru
  • bit 2: označuje, že chyba je opakovatelná. 1
  • Bity 3 až 7 jsou rezervované a musí být nastaveny na 0

Druhý bajt obsahuje skutečný jedinečný kód odpovědi. Kódy chyb s různými příznaky můžou mít stejnou druhou bajtovou hodnotu. Mohou existovat například 0001kódy chyb , , 020101010301 které mají odlišný význam.

Je to například Too Many Requests klient, opakovatelná chyba s vlastním kódem 1. Jeho hodnota je 0000 0101 0000 0001 nebo 0x0501.

Klienti můžou pomocí bitů typu identifikovat, jestli se operace úspěšně ukončila. Klienti mohou také použít opakovatelný bit k rozhodnutí, zda je rozumné opakovat operaci.

Doporučení

Správa relací

CONNACK paket přenese Session Present vlastnost označující, zda server obnovil dříve vytvořenou relaci. Pomocí této vlastnosti zjistíte, jestli se chcete přihlásit k odběru témat nebo přeskočit přihlášení k odběru od dřívějšího dokončení předplatného.

Pokud se chcete spolehnout Session Present, klient musí sledovat předplatná, která se provádí (tj. odesílaný SUBSCRIBE paket a přijatý SUBACK s kódem úspěšného důvodu), nebo se ujistěte, že se přihlásíte k odběru všech témat v rámci jedné SUBSCRIBE/SUBACK výměny. V opačném případě, pokud klient odešle dva SUBSCRIBE pakety a server zpracuje pouze jeden z nich úspěšně, server komunikuje Session Present: 1 CONNACK , zatímco má pouze část klientských předplatných přijatá.

Pokud chcete zabránit tomu, aby se starší verze klienta nepřihlásila k odběru všech témat, je lepší se přihlásit k odběru bezpodmínečně, když se změní chování klienta (například jako součást aktualizace firmwaru). Pokud chcete zajistit, aby nezastaralá předplatná zůstala (s ohledem na maximální povolený počet předplatných), explicitně odhlaste odběr předplatných, která se už nepoužívají.

Dávkování

Neexistuje žádný speciální formát pro odeslání dávky zpráv. Pokud chcete snížit režii operací náročných na prostředky v protokolu TLS a sítích, sbalte pakety (PUBLISHPUBACK, SUBSCRIBEa tak ne) společně, než je předáte podkladovému zásobníku PROTOKOLU TLS/TCP. Klient také může usnadnit alias tématu v rámci dávky:

  • Zadejte úplný název tématu do prvního PUBLISH paketu pro připojení a přidružte k němu alias tématu.
  • Do stejného tématu vložte následující pakety s prázdným názvem tématu a vlastností aliasu tématu.

Migrace

Tato část uvádí změny v rozhraní API v porovnání s předchozí podporou MQTT.

  • Přenosový protokol je MQTT 5. Dříve – MQTT 3.1.1.
  • Kontextové informace pro ověřování SAS jsou obsaženy přímo v CONNECT paketu místo kódování spolu s podpisem.
  • Metoda ověřování slouží k označení použité metody ověřování.
  • Sdílený přístupový podpis se vloží do vlastnosti Ověřovací data. Dříve se použilo pole Heslo.
  • Témata pro operace se liší:
    • Telemetrie: $iothub/telemetry místo devices/{Client Id}/messages/events,
    • Příkazy: $iothub/commands místo devices/{Client Id}/messages/devicebound,
    • Hlášeno dvojče patch: $iothub/twin/patch/reported místo $iothub/twin/PATCH/properties/reported,
    • Oznámit změně požadovaného stavu dvojčete: $iothub/twin/patch/desired místo $iothub/twin/PATCH/properties/desired.
  • Předplatné tématu odpovědi na operace požadavků na klient-server není povinné.
  • Vlastnosti uživatele se používají místo kódování vlastností v segmentu názvu tématu.
  • Názvy vlastností jsou napsané v "dash-case" pojmenování místo zkratek se speciální předponou. Uživatelem definované vlastnosti teď vyžadují předponu. Například je nyní message-id, $.mid zatímco myProperty1 se stane @myProperty1.
  • Vlastnost Data korelace se používá ke korelaci zpráv požadavků a odpovědí pro operace odezvy požadavku místo $rid vlastnosti kódované v tématu.
  • iothub-connection-auth-method vlastnost již není označena událostmi telemetrie.
  • Příkazy C2D se nevyprázdní bez předplatného ze zařízení. Zůstanou ve frontě, dokud se zařízení nepředplatí nebo nevyprší jejich platnost.

Příklady

Odeslání telemetrie

Zpráva:

-> 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>

Uznání:

<- PUBACK
    Packet_Id: 31
    Reason_Code: 0

Alternativní potvrzení (omezené):

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

Odeslání stavu získání dvojčete

Požadavek:

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

Odpověď (úspěch):

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

Odpověď (není povolena):

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

Zpracování volání přímé metody

Požadavek:

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

Odpověď (úspěch):

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

Poznámka:

status není nastavená – jedná se o odpověď na úspěch.

Odpověď zařízení není k dispozici:

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

Chyba při používání QoS 0, část 1

Požadavek:

-> 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>

Odpověď:

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

Chyba při používání QoS 0, část 2

Požadavek:

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

Odpověď:

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

Další kroky