Kommunikáció egy IoT Hubbal az MQTT protokoll használatával

Ez a cikk azt ismerteti, hogyan használhatják az eszközök a támogatott MQTT-viselkedéseket az Azure IoT Hubbal való kommunikációhoz. Az IoT Hub lehetővé teszi az eszközök számára az IoT Hub-eszközvégpontokkal való kommunikációt a következőkkel:

  • MQTT v3.1.1 a 8883-es TCP-porton
  • MQTT v3.1.1 a WebSocketen a 443-es TCP-porton.

Feljegyzés

A cikkben említett egyes funkciók, például a felhő–eszköz irányú üzenetküldés, az ikereszközök és az eszközfelügyelet csak a standard szintű IoT Hubon érhető el. Az alapszintű és standard/ingyenes IoT Hub-szintekről további információt a megoldáshoz megfelelő IoT Hub-szint kiválasztása című témakörben talál.

Az IoT Hubbal folytatott összes eszközkommunikációt TLS/SSL használatával kell védeni. Ezért az IoT Hub nem támogatja a nem biztonságos kapcsolatokat az 1883-as TCP-porton keresztül.

MQTT-támogatás összehasonlítása az IoT Hubban és az Event Gridben

Az IoT Hub nem teljes körű MQTT-közvetítő, és nem támogatja az MQTT v3.1.1 szabványban megadott összes viselkedést. Ha a megoldásnak MQTT-ra van szüksége, javasoljuk az MQTT támogatását az Azure Event Gridben. Az Event Grid kétirányú kommunikációt tesz lehetővé az MQTT-ügyfelek között rugalmas hierarchikus témakörökben egy pub-sub üzenetkezelési modell használatával. Lehetővé teszi az MQTT-üzenetek átirányítását az Azure-szolgáltatásokba vagy egyéni végpontokra további feldolgozás céljából.

Az alábbi táblázat a két szolgáltatás MQTT-támogatásának különbségeit ismerteti:

IoT Hub Event Grid
Ügyfél-kiszolgáló modell az eszközök és a felhőalkalmazások szoros összekapcsolásával. Közzétételi-előfizetési modell, amely elválasztja a közzétevőket és az előfizetőket.
Az MQTT 3.1.1-es verziójának korlátozott funkciótámogatása, az előzetes verzióban pedig az MQTT v5 korlátozott funkciótámogatása. További funkciók támogatása nem tervezett. Az MQTT 3.1.1-es és v5-ös protokolltámogatása több funkciótámogatást és iparági megfelelőséget tervez.
Statikus, előre definiált témakörök. Egyéni hierarchikus témakörök helyettesítő karakterek támogatásával.
Nem támogatottak a felhőből az eszközre irányuló közvetítések és az eszközök közötti kommunikáció. Támogatja az eszközről a felhőbe irányuló, nagy teljesítményű felhőből eszközre irányuló közvetítéseket és az eszközök közötti kommunikációs mintákat.
256 KB maximális üzenetméret. 512 KB maximális üzenetméret.

Csatlakozás az IoT Hubra

Az eszközök az MQTT protokoll használatával csatlakozhatnak egy IoT Hubhoz az alábbi lehetőségek egyikével:

Az MQTT-port (8883-es TCP-port) számos vállalati és oktatási hálózati környezetben le van tiltva. Ha nem tudja megnyitni a 8883-at a tűzfalon, javasoljuk az MQTT használatát WebSocketeken keresztül. A WebSocket-en keresztüli MQTT a 443-es porton keresztül kommunikál, amely szinte mindig nyitva van hálózati környezetben. Az MQTT és az MQTT WebSockets-protokollokon keresztüli megadásáról az Azure IoT SDK-k használatakor az eszköz SDK-k használata című témakörben olvashat.

Az eszköz SDK-k használata

Az MQTT protokollt támogató eszközoldali SDK-k Java, Node.js, C, C# és Python esetén érhetők el. Az eszköz SDK-k a választott hitelesítési mechanizmussal létesítenek kapcsolatot egy IoT Hubhoz. Az MQTT protokoll használatához az ügyfélprotokoll paraméterét MQTT értékre kell állítani. Az ügyfélprotokoll paraméterben websocketeken keresztül is megadhatja az MQTT-t. Az eszköz SDK-jai alapértelmezés szerint egy IoT Hubhoz csatlakoznak a 0-rabeállított CleanSession jelzővel, és a QoS 1 használatával váltanak üzeneteket az IoT Hubbal. Bár a QoS 0 konfigurálható a gyorsabb üzenetcsere érdekében, vegye figyelembe, hogy a kézbesítés nem garantált és nem is nyugtázható. Ezért a QoS 0-t gyakran "tűznek és felejtésnek" is nevezik.

Ha egy eszköz IoT Hubhoz csatlakozik, az eszköz SDK-jai olyan módszereket biztosítanak, amelyekkel az eszköz üzeneteket cserélhet egy IoT Hubbal.

Az alábbi táblázat az egyes támogatott nyelvekhez tartozó kódmintákra mutató hivatkozásokat tartalmaz, és meghatározza azt a paramétert, amelyet az MQTT vagy az MQTT over WebSockets protokoll használatával az IoT Hubhoz való csatlakozáshoz használ.

Nyelv MQTT protokollparaméter MQTT over WebSockets protocol parameter
Node.js azure-iot-device-mqtt. Mqtt azure-iot-device-mqtt. MqttWs
Java IotHubClientProtocol. MQTT IotHubClientProtocol.MQTT_WS
C MQTT_Protocol MQTT_WebSocket_Protocol
C# TransportType. Mqtt A TransportType.Mqtt visszaesik az MQTT-hez WebSocketsen keresztül, ha az MQTT meghiúsul. Ha csak WebSocketeken szeretné megadni az MQTT-t, használja a TransportType.Mqtt_WebSocket_Only
Python Alapértelmezés szerint támogatja az MQTT-t Hozzáadás websockets=True a híváshoz az ügyfél létrehozásához

Az alábbi töredék bemutatja, hogyan adhatja meg az MQTT over WebSockets protokollt az Azure IoT Node.js SDK használatakor:

var Client = require('azure-iot-device').Client;
var Protocol = require('azure-iot-device-mqtt').MqttWs;
var client = Client.fromConnectionString(deviceConnectionString, Protocol);

Az alábbi töredék bemutatja, hogyan adhatja meg az MQTT over WebSockets protokollt az Azure IoT Python SDK használatakor:

from azure.iot.device.aio import IoTHubDeviceClient
device_client = IoTHubDeviceClient.create_from_connection_string(deviceConnectionString, websockets=True)

Az életben tartás alapértelmezett időtúllépési értéke

Annak érdekében, hogy az ügyfél/IoT Hub-kapcsolat életben maradjon, a szolgáltatás és az ügyfél is rendszeresen küld egymásnak egy élő pinget. Az IoT SDK-t használó ügyfél a következő táblázatban meghatározott időközönként küld életben tartást:

Nyelv Alapértelmezett életben tartási időköz Konfigurálható
Node.js 180 másodperc Nem
Java 230 másodperc Igen
C 240 másodperc Igen
C# 300 másodperc* Igen
Python 60 másodperc Igen

*A C# SDK az MQTT KeepAliveInSeconds tulajdonság alapértelmezett értékét 300 másodpercként határozza meg. A valóságban az SDK egy pingelési kérelmet négyszer küld életben tartási időtartamként. Más szóval az SDK 75 másodpercenként küld egy élő pinget.

Az MQTT 3.1.1-es specifikációját követve az IoT Hub életben tartásának pingelési időköze az ügyfél életben tartásának 1,5-szerese, az IoT Hub azonban 29,45 percre (1767 másodpercre) korlátozza a kiszolgálóoldali időtúllépést. Ez a korlát azért létezik, mert minden Azure-szolgáltatás az Azure Load Balancer TCP tétlenségi időtúllépéséhez van kötve, ami 29,45 perc.

Egy Java SDK-t használó eszköz például elküldi az életben maradó pinget, majd elveszíti a hálózati kapcsolatot. 230 másodperccel később az eszköz nem veszi észre az élő pingelést, mert offline állapotban van. Az IoT Hub azonban nem zárja be azonnal a kapcsolatot – még egy (230 * 1.5) - 230 = 115 másodpercet vár, mielőtt leválasztaná az eszközt az eszköz 404104 Eszköz Csatlakozás ionClosedRemotely hibával.

Az ügyfél maximális életben tartási értéke 1767 / 1.5 = 1177 másodperc. Minden forgalom alaphelyzetbe állítja az életben tartást. Egy sikeres közös hozzáférésű jogosultságkód (SAS) jogkivonat frissítése például alaphelyzetbe állítja az életben tartást.

Eszközalkalmazás migrálása AMQP-ről MQTT-re

Ha az eszköz SDK-jait használja, az AMQP-ről az MQTT-re való váltáshoz módosítani kell a protokollparamétert az ügyfél inicializálásában a korábban leírtak szerint.

Ha így tesz, ellenőrizze a következő elemeket:

  • Az AMQP számos feltétel hibáit adja vissza, míg az MQTT megszakítja a kapcsolatot. Ennek eredményeképpen a kivételkezelési logika bizonyos módosításokat igényelhet.

  • Az MQTT nem támogatja az elutasítási műveleteket a felhőből az eszközre irányuló üzenetek fogadásakor. Ha a háttéralkalmazásnak választ kell kapnia az eszközalkalmazástól, fontolja meg a közvetlen módszerek használatát.

  • Az AMQP nem támogatott a Python SDK-ban.

Az MQTT protokoll közvetlen használata (eszközként)

Ha egy eszköz nem tudja használni az eszköz SDK-jait, akkor is csatlakozhat a nyilvános eszközvégpontokhoz a 8883-es port MQTT protokolljával.

A CONNECT-csomagban az eszköznek a következő értékeket kell használnia:

  • A ClientId mezőhöz használja az eszközazonosítót.

  • A Felhasználónév mezőben használja {iotHub-hostname}/{device-id}/?api-version=2021-04-12{iotHub-hostname} az IoT Hub teljes CName helyét.

    Ha például az IoT Hub neve contoso.azure-devices.net , és ha az eszköz neve MyDevice01, a teljes Felhasználónév mezőnek tartalmaznia kell:

    contoso.azure-devices.net/MyDevice01/?api-version=2021-04-12

    Javasoljuk, hogy az API-verziót is vegye fel a mezőbe. Ellenkező esetben váratlan viselkedést okozhat.

  • A Jelszó mezőben használjon SAS-jogkivonatot. Az SAS-jogkivonat formátuma megegyezik a HTTPS és az AMQP protokolléval:

    SharedAccessSignature sig={signature-string}&se={expiry}&sr={URL-encoded-resourceURI}

    Feljegyzés

    Ha X.509-tanúsítványhitelesítést használ, az SAS-jogkivonat jelszavai nem szükségesek. További információ : Oktatóanyag: Tanúsítványok létrehozása és feltöltése teszteléshez , és kövesse a TLS/SSL konfigurációs szakasz kód utasításait.

    Az SAS-jogkivonatok létrehozásának módjáról további információt az Sas-jogkivonatok használata az IoT Hubhoz való hozzáférés vezérlése eszközként a közös hozzáférésű jogosultságkódok használatával című szakaszában talál.

    A Visual Studio Code platformfüggetlen Azure IoT Hub-bővítményét vagy az az iot hub generate-sas-token parancssori felületi bővítményét is használhatja az SAS-jogkivonat gyors létrehozásához. Ezután tesztelési célokra másolhatja és beillesztheti az SAS-jogkivonatot a saját kódjába.

Az MQTT közvetlen használatával kapcsolatos oktatóanyagért lásd : Az MQTT használata IoT-eszközügyfél eszköz SDK használata nélkül történő fejlesztéséhez.

A Visual Studio Code Azure IoT Hub-bővítményének használata

  1. Az oldalsávon bontsa ki az Eszközök csomópontot az Azure IoT Hub szakaszban.

  2. Kattintson a jobb gombbal az IoT-eszközre, és válassza a helyi menüben az Eszközhöz készült SAS-jogkivonat létrehozása lehetőséget.

  3. Adja meg az SAS-jogkivonat lejárati idejét órákban a beviteli mezőben, majd válassza az Enter billentyűt.

  4. A RENDSZER létrehozza és vágólapra másolja az SAS-jogkivonatot.

    A létrehozott SAS-jogkivonat struktúrája a következő:

    HostName={iotHub-hostname};DeviceId=javadevice;SharedAccessSignature=SharedAccessSignature sr={iotHub-hostname}%2Fdevices%2FMyDevice01%2Fapi-version%3D2016-11-14&sig=vSgHBMUG.....Ntg%3d&se=1456481802

    Ennek a jogkivonatnak az MQTT használatával való csatlakozáshoz jelszó mezőként való használatához használt része a következő:

    SharedAccessSignature sr={iotHub-hostname}%2Fdevices%2FMyDevice01%2Fapi-version%3D2016-11-14&sig=vSgHBMUG.....Ntg%3d&se=1456481802

Az eszközalkalmazás megadhat egy Will-üzenetet a CONNECT-csomagban . Az eszközalkalmazásnak vagy a Will témakör neveként kell devices/{device-id}/messages/events/ megadnia a telemetriai üzenetként továbbítandó Will-üzeneteket.devices/{device-id}/messages/events/{property-bag} Ebben az esetben, ha a hálózati kapcsolat lezárult, de az eszközről korábban nem érkezett MEG A KAPCSOLAT csomag, akkor az IoT Hub elküldi a CONNECT-csomagban megadott Will üzenetet a telemetriai csatornának. A telemetriai csatorna lehet az alapértelmezett Eseményvégpont vagy az IoT Hub-útválasztás által definiált egyéni végpont. Az üzenethez hozzá van rendelve az iothub-MessageType tulajdonság, amelynek értéke Will .

Az MQTT protokoll közvetlen használata (modulként)

Az IoT Hubhoz MQTT-n keresztül is csatlakozhat egy modulidentitás használatával, hasonlóan az IoT Hubhoz eszközként való csatlakozáshoz. Az IoT Hubhoz az MQTT-en keresztül eszközként való csatlakozásról további információt az MQTT protokoll közvetlen használata (eszközként) című témakörben talál. Azonban a következő értékeket kell használnia:

  • Állítsa be az ügyfélazonosítót a következőre {device-id}/{module-id}: .

  • Ha felhasználónévvel és jelszóval hitelesíti a felhasználónevet, állítsa be a felhasználónevet <hubname>.azure-devices.net/{device_id}/{module_id}/?api-version=2021-04-12 , és használja a modul identitásához társított SAS-jogkivonatot jelszóként.

  • Telemetria devices/{device-id}/modules/{module-id}/messages/events/ közzétételéhez használható témakörként.

  • Will-témakörként használható devices/{device-id}/modules/{module-id}/messages/events/ .

  • Üzenetek fogadásához használható devices/{device-id}/modules/{module-id}/# témakörként.

  • Az iker GET és a PATCH témakörök azonosak a modulok és eszközök esetében.

  • Az ikerállapot-témakör azonos a modulok és eszközök esetében.

Az MQTT modulokkal való használatáról további információt az IoT Edge közzétételével és előfizetésével, valamint az IoT Edge hub MQTT-végpontjával kapcsolatos további információkért talál.

Azure IoT SDK nélküli MQTT-t használó minták

Az IoT MQTT-mintaadattár C/C++, Python és CLI-mintákat tartalmaz, amelyek bemutatják, hogyan küldhet telemetriai üzeneteket, fogadhat felhőből eszközre irányuló üzeneteket, és hogyan használhat ikereszközöket az Azure-eszköz SDK-k használata nélkül.

A C/C++ minták az Eclipse Mosquitto könyvtárat használják, a Python-minta az Eclipse Paho-t, a CLI-mintákat pedigmosquitto_pub.

További információ: Oktatóanyag – Az MQTT használata IoT-eszközügyfél fejlesztéséhez.

TLS/SSL-konfiguráció

Az MQTT protokoll közvetlen használatához az ügyfélnek TLS/SSL protokollon keresztül kell csatlakoznia. A lépés kihagyására tett kísérletek csatlakozási hibákkal meghiúsulnak.

TLS-kapcsolat létrehozásához előfordulhat, hogy le kell töltenie és hivatkoznia kell az Azure által használt DigiCert főtanúsítványra. 2023. február 15. és október 15. között az Azure IoT Hub migrálja TLS-főtanúsítványát a DigiCert Baltimore főtanúsítványából a DigiCert Global Root G2-be. A migrálási időszak alatt mindkét tanúsítványnak rendelkeznie kell az eszközein a kapcsolat biztosításához. Az áttelepítéssel kapcsolatos további információkért lásd : IoT-erőforrások áttelepítése új TLS-tanúsítványgyökérre További információ ezekről a tanúsítványokról: Digicert webhelye.

Az alábbi példa bemutatja, hogyan implementálhatja ezt a konfigurációt az Eclipse Foundation Paho MQTT-kódtárÁnak Python-verziójával.

Először telepítse a Paho-kódtárat a parancssori környezetből:

pip install paho-mqtt

Ezután implementálja az ügyfelet egy Python-szkriptben. Cserélje le ezeket a helyőrzőket a következő kódrészletben:

  • <local path to digicert.cer> A DigiCert főtanúsítványt tartalmazó helyi fájl elérési útja. Ezt a fájlt úgy hozhatja létre, hogy a tanúsítványinformációkat a certs.c fájlból másolja a C-hez készült Azure IoT SDK-ba. Adja hozzá a sorokat-----BEGIN CERTIFICATE-----, és -----END CERTIFICATE-----távolítsa el a " jeleket minden sor elején és végén, és távolítsa el a \r\n karaktereket minden sor végén.

  • <device id from device registry> az IoT Hubhoz hozzáadott eszköz azonosítója.

  • <generated SAS token> A jelen cikkben korábban ismertetett módon létrehozott eszköz SAS-jogkivonata.

  • <iot hub name> az IoT Hub neve.

from paho.mqtt import client as mqtt
import ssl

path_to_root_cert = "<local path to digicert.cer file>"
device_id = "<device id from device registry>"
sas_token = "<generated SAS token>"
iot_hub_name = "<iot hub name>"


def on_connect(client, userdata, flags, rc):
    print("Device connected with result code: " + str(rc))


def on_disconnect(client, userdata, rc):
    print("Device disconnected with result code: " + str(rc))


def on_publish(client, userdata, mid):
    print("Device sent message")


client = mqtt.Client(client_id=device_id, protocol=mqtt.MQTTv311)

client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_publish = on_publish

client.username_pw_set(username=iot_hub_name+".azure-devices.net/" +
                       device_id + "/?api-version=2021-04-12", password=sas_token)

client.tls_set(ca_certs=path_to_root_cert, certfile=None, keyfile=None,
               cert_reqs=ssl.CERT_REQUIRED, tls_version=ssl.PROTOCOL_TLSv1_2, ciphers=None)
client.tls_insecure_set(False)

client.connect(iot_hub_name+".azure-devices.net", port=8883)

client.publish("devices/" + device_id + "/messages/events/", '{"id":123}', qos=1)
client.loop_forever()

Eszköztanúsítvány használatával történő hitelesítéshez frissítse az előző kódrészletet az alábbi kódrészletben megadott módosításokkal. A tanúsítványalapú hitelesítésre való felkészülésről további információt az X.509 hitelesítésszolgáltatói tanúsítványokat használó eszközök X.509 hitelesítésszolgáltatói tanúsítványának lekérése című szakaszában talál.

# Create the client as before
# ...

# Set the username but not the password on your client
client.username_pw_set(username=iot_hub_name+".azure-devices.net/" +
                       device_id + "/?api-version=2021-04-12", password=None)

# Set the certificate and key paths on your client
cert_file = "<local path to your certificate file>"
key_file = "<local path to your device key file>"
client.tls_set(ca_certs=path_to_root_cert, certfile=cert_file, keyfile=key_file,
               cert_reqs=ssl.CERT_REQUIRED, tls_version=ssl.PROTOCOL_TLSv1_2, ciphers=None)

# Connect as before
client.connect(iot_hub_name+".azure-devices.net", port=8883)

Eszközről felhőbe irányuló üzenetek küldése

Miután egy eszköz csatlakozott, üzeneteket küldhet az IoT Hubnak témakörnév vagy témakörnév használatával devices/{device-id}/messages/events/devices/{device-id}/messages/events/{property-bag}. Az {property-bag} elem lehetővé teszi, hogy az eszköz más tulajdonságokkal rendelkező üzeneteket küldjön URL-kódolású formátumban. Például:

RFC 2396-encoded(<PropertyName1>)=RFC 2396-encoded(<PropertyValue1>)&RFC 2396-encoded(<PropertyName2>)=RFC 2396-encoded(<PropertyValue2>)…

Feljegyzés

Ez az {property_bag} elem ugyanazt a kódolást használja, mint a HTTPS protokoll lekérdezési sztringjei.

Feljegyzés

Ha D2C-üzeneteket szeretne átirányítani egy Azure Storage-fiókba, és JSON-kódolást szeretne használni, meg kell adnia a tartalomtípust és a tartalomkódolási adatokat, beleértve $.ct=application%2Fjson&$.ce=utf-8az {property_bag} előző megjegyzésben említett adatokat is.

Ezeknek az attribútumoknak a formátuma protokollspecifikus. Az IoT Hub ezeket az attribútumokat lefordítja a megfelelő rendszertulajdonságokra. További információt az IoT Hub üzenet-útválasztási lekérdezés szintaxisának Rendszertulajdonságok szakaszában talál.

Az alábbi lista az IoT Hub implementációspecifikus viselkedéseit ismerteti:

  • Az IoT Hub nem támogatja a QoS 2-üzeneteket. Ha egy eszközalkalmazás közzétesz egy üzenetet a QoS 2-vel, az IoT Hub bezárja a hálózati kapcsolatot.

  • Az IoT Hub nem őrzi meg az üzenetek megőrzését. Ha egy eszköz 1 értékre állított RETAIN jelzővel küld üzenetet, az IoT Hub hozzáadja az mqtt-retain alkalmazás tulajdonságot az üzenethez. Ebben az esetben a megőrző üzenet megőrzése helyett az IoT Hub átadja azt a háttéralkalmazásnak.

  • Az IoT Hub eszközönként csak egy aktív MQTT-kapcsolatot támogat. Bármely új MQTT-kapcsolat ugyanazon eszközazonosító nevében, az IoT Hub elveti a meglévő kapcsolatot, és 400027 Csatlakozás ionForcefullyClosedOnNew Csatlakozás ion be van jelentkezve az IoT Hub-naplókba

  • Az üzenetek üzenettörzs alapján történő átirányításához először hozzá kell adnia a contentType (ct) tulajdonságot az MQTT-témakör végéhez, és meg kell adnia annak értékét application/json;charset=utf-8 az alábbi példában látható módon. Az üzenetek üzenettulajdonságok vagy üzenettörzs alapján történő útválasztásával kapcsolatos további információkért tekintse meg az IoT Hub üzenet-útválasztási lekérdezés szintaxisának dokumentációját.

    devices/{device-id}/messages/events/$.ct=application%2Fjson%3Bcharset%3Dutf-8

További információ: Eszközről felhőbe és felhőbe irányuló üzenetek küldése az IoT Hubbal.

Felhőből eszközre irányuló üzenetek fogadása

Az IoT Hubtól érkező üzenetek fogadásához az eszköznek témakörszűrőként kell előfizetniedevices/{device-id}/messages/devicebound/#. A Témakörszűrőben található többszintű helyettesítő karakter # csak arra szolgál, hogy az eszköz további tulajdonságokat kapjon a témakör nevében. Az IoT Hub nem engedélyezi a # helyettesítő karakterek vagy ? helyettesítő karakterek használatát az altopikák szűréséhez. Mivel az IoT Hub nem általános célú pub-sub messaging broker, csak a dokumentált témakörneveket és témakörszűrőket támogatja. Egy eszköz egyszerre csak öt témakörre tud előfizetni.

Az eszköz nem kap üzeneteket az IoT Hubtól, amíg sikeresen elő nem iratkozott az eszközspecifikus végpontjára, amelyet a devices/{device-id}/messages/devicebound/# témakörszűrő jelöl. Az előfizetés létrehozása után az eszköz megkapja a felhőből az eszközre irányuló üzeneteket, amelyeket az előfizetés időpontja után küldtek neki. Ha az eszköz 0-ra beállított CleanSession jelzővel csatlakozik, az előfizetés különböző munkamenetekben megmarad. Ebben az esetben a következő alkalommal, amikor az eszköz csatlakozik a CleanSession 0-hoz , a leválasztott állapotban lévő üzeneteket kap. Ha az eszköz az 1-nek beállított CleanSession jelzőt használja, addig nem kap üzeneteket az IoT Hubtól, amíg elő nem iratkozhat az eszközvégpontjára.

Az IoT Hub a témakör nevéveldevices/{device-id}/messages/devicebound/ vagy devices/{device-id}/messages/devicebound/{property-bag} üzenettulajdonságokkal rendelkező üzeneteket küld. {property-bag} URL-kódolt kulcs-/értékpárokat tartalmaz az üzenettulajdonságokhoz. A tulajdonságcsomagban csak az alkalmazástulajdonságok és a felhasználó által beállított rendszertulajdonságok (például messageId vagy correlationId) szerepelnek. A rendszertulajdonságok nevei előtaggal $rendelkeznek, az alkalmazástulajdonságok az eredeti tulajdonságnevet használják előtag nélkül. A tulajdonságcsomag formátumáról további információt az eszközről a felhőbe irányuló üzenetek küldése című témakörben talál.

A felhőből az eszközre irányuló üzenetekben a tulajdonságcsomag értékei az alábbi táblázatban látható módon jelennek meg:

Tulajdonságérték Képviselet Leírás
null key Csak a kulcs jelenik meg a tulajdonságcsomagban
üres sztring key= A kulcs, amelyet egy egyenlőségjel követ érték nélkül
non-null, nonempty érték key=value A kulcs, majd egy egyenlőségjel és az érték

Az alábbi példa egy tulajdonságcsomagot mutat be, amely három alkalmazástulajdonságot tartalmaz: prop1 null;prop2, egy üres sztring (""); és a prop3 értéke "egy sztring".

/?prop1&prop2=&prop3=a%20string

Amikor egy eszközalkalmazás feliratkozik egy témakörre a QoS 2-vel, az IoT Hub maximális 1. szintű QoS-szintet biztosít a SUBACK-csomagban. Ezt követően az IoT Hub az 1. QoS használatával küld üzeneteket az eszköznek.

Ikereszköz tulajdonságainak lekérése

Először egy eszköz feliratkozik a $iothub/twin/res/#művelet válaszainak fogadásához. Ezután egy üres üzenetet küld a témakörnek$iothub/twin/GET/?$rid={request id}, amely egy kitöltött kérésazonosítóval rendelkezik. A szolgáltatás ezután egy válaszüzenetet küld, amely az ikereszköz adatait tartalmazza a témakörben $iothub/twin/res/{status}/?$rid={request-id}, ugyanazzal a kérésazonosítóval , mint a kérés.

A kérésazonosító bármilyen érvényes érték lehet egy üzenettulajdonság értékéhez, és az állapot egész számként van érvényesítve. További információ: Eszközről felhőbe és felhőbe irányuló üzenetek küldése az IoT Hubbal.

A válasz törzse az ikereszköz tulajdonságok szakaszát tartalmazza, ahogyan az a következő válaszpéldában is látható:

{
    "desired": {
        "telemetrySendFrequency": "5m",
        "$version": 12
    },
    "reported": {
        "telemetrySendFrequency": "5m",
        "batteryLevel": 55,
        "$version": 123
    }
}

A lehetséges állapotkódok a következők:

Állapot Leírás
200 Siker
429 Túl sok kérés (szabályozva). További információ: IoT Hub-szabályozás
5** Kiszolgálóhibák

További információ: Eszközök ikerállapotának megismerése és használata az IoT hubon.

Az ikereszköz jelentett tulajdonságainak frissítése

A jelentett tulajdonságok frissítéséhez az eszköz kiad egy kérést az IoT Hubhoz egy kijelölt MQTT-témakörön keresztül. Miután az IoT Hub feldolgozta a kérést, egy kiadványon keresztül válaszol a frissítési művelet sikeres vagy sikertelen állapotára egy másik témakörre. Az eszköz feliratkozhat erre a témakörre, hogy értesítést küldjön az ikerfrissítési kérés eredményéről. Az ilyen típusú kérés-válasz interakció az MQTT-ben való implementálásához az eszköz által a frissítési kérelemben kezdetben megadott kérésazonosító ($rid) fogalmát használjuk. Ezt a kérésazonosítót az IoT Hub válasza is tartalmazza, amely lehetővé teszi, hogy az eszköz korrelálja a választ az adott korábbi kérésével.

Az alábbi sorozat bemutatja, hogyan frissíti az eszköz a jelentett tulajdonságokat az IoT Hub ikereszközén:

  1. Az eszköznek először elő kell iratkoznia a $iothub/twin/res/# témakörre, hogy megkapja a művelet válaszait az IoT Hubtól.

  2. Az eszköz egy üzenetet küld, amely tartalmazza az ikereszköz frissítését a $iothub/twin/PATCH/properties/reported/?$rid={request-id} témakörhöz. Ez az üzenet egy kérésazonosító-értéket tartalmaz.

  3. A szolgáltatás ezután egy válaszüzenetet küld, amely tartalmazza a témakör $iothub/twin/res/{status}/?$rid={request-id}jelentett tulajdonsággyűjteményének új ETag-értékét. Ez a válaszüzenet ugyanazt a kérésazonosítót használja, mint a kérés.

A kérelemüzenet törzse egy JSON-dokumentumot tartalmaz, amely új értékeket tartalmaz a jelentett tulajdonságokhoz. A JSON-dokumentum minden tagja frissül, vagy hozzáadja a megfelelő tagot az ikereszköz dokumentumához. Egy tag úgy van beállítva, hogy null törölje a tagot a tartalmazó objektumból. Példa:

{
    "telemetrySendFrequency": "35m",
    "batteryLevel": 60
}

A lehetséges állapotkódok a következők:

Állapot Leírás
204 Siker (nem ad vissza tartalmat)
400 Hibás kérés. Hibásan formázott JSON
429 Túl sok kérés (szabályozva) az IoT Hub szabályozásának megfelelően
5** Kiszolgálóhibák

Az alábbi Python-kódrészlet bemutatja az Iker által jelentett tulajdonságok frissítési folyamatát az MQTT-n keresztül a Paho MQTT-ügyfél használatával:

from paho.mqtt import client as mqtt

# authenticate the client with IoT Hub (not shown here)

client.subscribe("$iothub/twin/res/#")
rid = "1"
twin_reported_property_patch = "{\"firmware_version\": \"v1.1\"}"
client.publish("$iothub/twin/PATCH/properties/reported/?$rid=" +
               rid, twin_reported_property_patch, qos=0)

Ha az ikerpéldány által jelentett tulajdonságok frissítési folyamata sikeres volt az előző kódrészletben, az IoT Hub közzétételi üzenete a következő témakörrel rendelkezik: $iothub/twin/res/204/?$rid=1&$version=6ahol 204 az állapotkód a sikerességet jelzi, $rid=1 megfelel az eszköz által a kódban megadott kérelemazonosítónak, és $version megfelel az ikereszköz jelentett tulajdonságok szakaszának a frissítés után.

További információ: Eszközök ikerállapotának megismerése és használata az IoT hubon.

Kívánt tulajdonságok frissítési értesítésének fogadása

Amikor egy eszköz csatlakozik, az IoT Hub értesítéseket küld a témakörnek $iothub/twin/PATCH/properties/desired/?$version={new-version}, amely tartalmazza a megoldás háttérrendszere által végrehajtott frissítés tartalmát. Példa:

{
    "telemetrySendFrequency": "5m",
    "route": null,
    "$version": 8
}

A tulajdonságfrissítések esetében az értékek azt jelentik, null hogy a JSON-objektumtag törölve van. $version Emellett az ikerpéldány kívánt tulajdonságok szakaszának új verzióját is jelzi.

Fontos

Az IoT Hub csak akkor hoz létre változásértesítéseket, ha az eszközök csatlakoztatva vannak. Győződjön meg arról, hogy implementálja az eszköz újracsatlakozási folyamatát , hogy a kívánt tulajdonságok szinkronizálva maradjanak az IoT Hub és az eszközalkalmazás között.

További információ: Eszközök ikerállapotának megismerése és használata az IoT hubon.

Válasz közvetlen metódusra

Először is egy eszköznek elő kell fizetnie.$iothub/methods/POST/# Az IoT Hub metóduskérelmeket küld a témakörnek $iothub/methods/POST/{method-name}/?$rid={request-id}érvényes JSON vagy üres törzs használatával.

A válaszhoz az eszköz egy érvényes JSON-t vagy üres törzset tartalmazó üzenetet küld a témakörnek $iothub/methods/res/{status}/?$rid={request-id}. Ebben az üzenetben a kérelemazonosítónak meg kell egyeznie a kérelemüzenetben szereplő azonosítóval , az állapotnak pedig egész számnak kell lennie.

További információ: Közvetlen metódusok megismerése és meghívása az IoT Hubról.

Következő lépések

Az MQTT használatáról az alábbiakban olvashat bővebben:

Az IoT-eszközök SDKS-jének használatáról az alábbiakban olvashat bővebben:

Az IoT Hub üzembe helyezésének megtervezéséről az alábbiakban olvashat bővebben: