Dukungan IoT Hub MQTT 5 (tidak digunakan lagi)
Versi: 2.0 api-version: 2020-10-01-pratinjau
Dokumen ini menentukan API bidang data IoT Hub melalui protokol MQTT versi 5.0. Lihat Referensi API untuk definisi lengkap dalam API ini.
Catatan
Dukungan MQTT 5 di IoT Hub tidak digunakan lagi dan IoT Hub memiliki dukungan fitur terbatas untuk MQTT. Jika solusi Anda memerlukan dukungan MQTT v3.1.1 atau v5, kami sarankan dukungan MQTT di Azure Event Grid. Untuk informasi selengkapnya, lihat Membandingkan dukungan MQTT di IoT Hub dan Event Grid.
Prasyarat
- Buat hub IoT baru dengan mode pratinjau diaktifkan. MQTT 5 hanya tersedia dalam mode pratinjau, dan Anda tidak dapat mengalihkan hub IoT yang ada ke mode pratinjau. Untuk informasi selengkapnya, lihat Mengaktifkan mode pratinjau
- Pengetahuan sebelumnya tentang spesifikasi MQTT 5.
Tingkat dukungan dan batasan
Dukungan IoT Hub untuk MQTT 5 dalam pratinjau dan terbatas dengan cara berikut (dikomunikasikan ke klien melalui properti CONNACK
kecuali dicatat sebaliknya secara eksplisit):
- Belum ada dukungan SDK perangkat Azure IoT resmi.
- Pengidentifikasi langganan tidak didukung.
- Langganan bersama tidak didukung.
RETAIN
tidak didukung.Maximum QoS
adalah1
.Maximum Packet Size
adalah256 KiB
(tunduk pada batasan lebih lanjut per operasi).- ID Klien yang ditetapkan tidak didukung.
Keep Alive
dibatasi hingga19 min
(penundaan maksimum untuk pemeriksaan keaktifan –28.5 min
).Topic Alias Maximum
adalah10
.Response Information
tidak didukung;CONNACK
tidak mengembalikan propertiResponse Information
bahkan jikaCONNECT
berisi propertiRequest Response Information
.Receive Maximum
(jumlah maksimum paketPUBLISH
yang belum diakui yang diizinkan (dalam arah client-server) denganQoS: 1
) adalah16
.- Klien tunggal tidak boleh memiliki lebih dari
50
langganan. Jika klien mencapai batas langganan,SUBACK
mengembalikan0x97
kode alasan (Kuota terlampaui) untuk langganan.
Siklus hidup koneksi
Connection
Untuk menyambungkan klien ke IoT Hub menggunakan API ini, buat koneksi sesuai spesifikasi MQTT 5.
Klien harus mengirim paket CONNECT
dalam waktu 30 detik setelah jabat tangan TLS berhasil, atau server menutup koneksi.
Berikut contoh dari paket 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
- Properti
Authentication Method
diperlukan dan mengidentifikasi metode autentikasi mana yang digunakan. Untuk informasi selengkapnya tentang metode autentikasi, lihat Autentikasi. - Penanganan properti
Authentication Data
tergantung padaAuthentication Method
. JikaAuthentication Method
diatur keSAS
,Authentication Data
diperlukan dan harus berisi tanda tangan yang valid. Untuk informasi selengkapnya tentang data autentikasi, lihat Autentikasi. - Properti
api-version
diperlukan dan harus diatur ke nilai versi API yang disediakan di header spesifikasi ini agar spesifikasi ini berlaku. - Properti
host
menentukan nama host penyewa. Ini diperlukan kecuali ekstensi SNI disajikan dalam rekaman Halo Klien selama jabat tangan TLS sas-at
menentukan waktu koneksi.sas-expiry
menentukan waktu kedaluwarsa untuk SAS yang disediakan.client-agent
secara opsional mengkomunikasikan informasi tentang klien yang membuat koneksi.
Catatan
Authentication Method
dan properti lainnya di seluruh spesifikasi dengan nama yang dikapitalisasi adalah properti kelas satu di MQTT 5 - properti tersebut dijelaskan secara rinci dalam spesifikasi MQTT 5. api-version
dan properti lain dalam tanda hubung adalah properti pengguna khusus untuk IoT Hub API.
IoT Hub merespons dengan paket CONNACK
setelah selesai dengan autentikasi dan mengambil data untuk mendukung koneksi. Jika koneksi berhasil dibuat, CONNACK
terlihat seperti:
<- 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
Properti paket CONNACK
ini mengikuti spesifikasi MQTT 5. Properti tersebut mencerminkan kemampuan IoT Hub.
Autentikasi
Properti Authentication Method
pada klien CONNECT
menentukan jenis autentikasi yang digunakan untuk koneksi ini:
SAS
- Tanda Tangan Akses Bersama disediakan diCONNECT
propertiAuthentication Data
,X509
- Klien mengandalkan autentikasi sertifikat klien.
Autentikasi gagal jika metode autentikasi tidak cocok dengan metode klien yang dikonfigurasi di IoT Hub.
Catatan
API ini membutuhkan properti Authentication Method
untuk diatur dalam paket CONNECT
. Jika properti Authentication Method
tidak disediakan, koneksi gagal dengan respons Bad Request
.
Autentikasi nama pengguna/kata sandi yang digunakan dalam versi API sebelumnya tidak didukung.
SAS
Dengan autentikasi berbasis SAS, klien harus memberikan tanda tangan konteks koneksi. Tanda tangan membuktikan keaslian koneksi MQTT. Tanda tangan harus didasarkan pada salah satu dari dua kunci autentikasi dalam konfigurasi klien di IoT Hub. Atau harus didasarkan pada salah satu dari dua kunci akses bersama dari kebijakan akses bersama.
String untuk ditandatangani harus dibentuk sebagai berikut:
{host name}\n
{Client Id}\n
{sas-policy}\n
{sas-at}\n
{sas-expiry}\n
host name
berasal baik dari ekstensi SNI (disajikan oleh klien dalam rekaman Halo Klien selama jabat tangan TLS) atau properti penggunahost
dalam paketCONNECT
.Client Id
adalah Pengidentifikasi Klien dalam paketCONNECT
.sas-policy
- jika ada, menentukan kebijakan akses IoT Hub yang digunakan untuk autentikasi. Ini dikodekan sebagai properti pengguna pada paketCONNECT
. Opsional: menghilangkannya berarti pengaturan autentikasi di registri perangkat digunakan sebagai gantinya.sas-at
- Jika ada, menentukan waktu koneksi - waktu saat ini. Ini dikodekan sebagai properti pengguna jenistime
pada paketCONNECT
.sas-expiry
menentukan waktu kedaluwarsa untuk autentikasi. Ini adalah properti pengguna yang diketiktime
pada paketCONNECT
. Properti ini diperlukan.
Untuk parameter opsional, jika dihilangkan, string kosong HARUS digunakan sebagai pengganti string untuk ditandatangani.
HMAC-SHA256 digunakan untuk hash string berdasarkan salah satu kunci konten perangkat. Nilai hash kemudian diatur sebagai nilai properti Authentication Data
.
X509
Jika properti Authentication Method
diatur ke X509
, IoT Hub mengautentikasi koneksi berdasarkan sertifikat klien yang disediakan.
Autentikasi ulang
Jika autentikasi berbasis SAS digunakan, sebaiknya gunakan token autentikasi yang berumur pendek. Untuk menjaga koneksi terautentikasi dan mencegah pemutusan sambungan karena kedaluwarsa, klien harus mengautentikasi ulang dengan mengirimkan paket AUTH
dengan Reason Code: 0x19
(autentikasi ulang):
-> AUTH
Reason_Code: 0x19
Authentication_Method: SAS
Authentication_Data: {SAS bytes}
sas-at: {current time}
sas-expiry: {SAS expiry time}
Aturan:
Authentication Method
harus sama dengan yang digunakan untuk autentikasi awal- jika koneksi awalnya diautentikasi menggunakan SAS berdasarkan Shared Access Azure Policy, tanda tangan yang digunakan dalam autentikasi ulang harus didasarkan pada kebijakan yang sama.
Jika autentikasi ulang berhasil, IoT Hub mengirimkan paket AUTH
dengan Reason Code: 0x00
(berhasil). Jika tidak, IoT Hub mengirim paket DISCONNECT
dengan Reason Code: 0x87
(Tidak diotorisasi) dan menutup koneksi.
Pemutusan sambungan
Server dapat memutuskan sambungan klien karena beberapa alasan, termasuk:
- klien bertingkah laku dengan cara yang tidak mungkin ditanggapi dengan pengakuan negatif (atau respons) secara langsung,
- server gagal menjaga status koneksi tetap terkini,
- klien lain terhubung dengan identitas yang sama.
Server dapat memutuskan sambungan dengan kode alasan apa pun yang ditentukan dalam spesifikasi MQTT 5.0. Sebutan penting:
135
(Tidak diotorisasi) ketika autentikasi ulang gagal, token SAS saat ini kedaluwarsa, atau kredensial perangkat berubah.142
(Sesi diambil alih) saat koneksi baru dengan identitas klien yang sama telah dibuka.159
(Tingkat koneksi terlampaui) ketika tingkat koneksi untuk hub IoT melebihi batas.131
(Kesalahan khusus implementasi) digunakan untuk kesalahan khusus apa pun yang ditentukan dalam API ini.status
danreason
properti digunakan untuk mengomunikasikan detail lebih lanjut tentang penyebab pemutusan sambungan (lihat Respons untuk detailnya).
Operasional
Semua fungsi dalam API ini dinyatakan sebagai operasi. Berikut ini contoh operasi Kirim Telemetri:
-> PUBLISH
QoS: 1
Packet_Id: 3
Topic: $iothub/telemetry
Payload: Hello
<- PUBACK
Packet_Id: 3
Reason_Code: 0
Untuk spesifikasi lengkap operasi dalam API ini, lihat referensi API MQTT 5 sarana data IoT Hub.
Catatan
Semua sampel dalam spesifikasi ini ditunjukkan dari perspektif klien. Tanda ->
berarti klien mengirim paket, <-
- menerima.
Topik pesan dan langganan
Topik yang digunakan dalam pesan operasi dalam API ini dimulai dengan $iothub/
.
Semantik broker MQTT tidak berlaku untuk operasi ini (lihat "Topik dimulai dengan $" untuk detailnya).
Topik yang dimulai dengan $iothub/
yang tidak ditentukan dalam API ini tidak didukung:
- Mengirim pesan ke topik yang tidak terdefinisi menghasilkan
Not Found
respons (lihat Respons untuk detailnya), - Berlangganan ke topik yang tidak ditentukan menghasilkan
SUBACK
denganReason Code: 0x8F
(Filter Topik Tidak Valid).
Nama topik dan nama properti peka huruf besar/kecil dan harus sama persis. Misalnya, $iothub/telemetry/
tidak didukung saat $iothub/telemetry
didukung.
Catatan
Kartubebas dalam langganan di $iothub/..
tidak didukung. Artinya, klien tidak dapat berlangganan $iothub/+
atau $iothub/#
. Mencoba melakukannya menghasilkan SUBACK
dengan Reason Code: 0xA2
(Langganan Kartubebas tidak didukung). Hanya kartubebas segmen tunggal (+
) yang didukung sebagai ganti dari parameter jalur dalam nama topik untuk operasi yang memilikinya.
Jenis interaksi
Semua operasi di API ini didasarkan pada salah satu dari dua jenis interaksi:
- Pesan dengan pengakuan opsional (MessageAck)
- Permintaan-Respons (ReqRep)
Operasi juga bervariasi menurut arah (ditentukan oleh arah pesan awal dalam pertukaran):
- Klien-ke-Server (c2s)
- Server-ke-Klien (s2c)
Misalnya, Kirim Telemetri adalah operasi Klien-ke-Server dari jenis "Pesan dengan pengakuan", sedangkan Handle Direct Method adalah operasi Server-ke-Klien dari jenis Permintaan-Respons.
Interaksi pesan-pengakuan
Pesan dengan interaksi Pengakuan (MessageAck) opsional dinyatakan sebagai pertukaran paket PUBLISH
dan PUBACK
di MQTT. Pengakuan bersifat opsional dan pengirim dapat memilih untuk tidak memintanya dengan mengirim PUBLISH
paket dengan QoS: 0
.
Catatan
Jika properti dalam paketi PUBACK
harus dipotong karena Maximum Packet Size
dideklarasikan oleh klien, IoT Hub akan mempertahankan properti Pengguna sebanyak yang dapat ditampung dalam batas yang diberikan. Properti pengguna yang terdaftar pertama memiliki peluang lebih tinggi untuk dikirim daripada yang terdaftar kemudian; properti Reason String
memiliki prioritas paling sedikit.
Contoh interaksi MessageAck sederhana
Pesan:
PUBLISH
QoS: 1
Packet_Id: 34
Topic: $iothub/{request.path}
Payload: <any>
Pengakuan (berhasil):
PUBACK
Packet_Id: 34
Reason_Code: 0
Interaksi Permintaan-Respons
Dalam interaksi Permintaan-Respons (ReqRep), baik Permintaan maupun Respons diterjemahkan ke dalam paket PUBLISH
dengan QoS: 0
.
Properti Correlation Data
harus diatur di keduanya dan digunakan untuk mencocokkan paket Respons dengan paket Permintaan.
API ini menggunakan topik respons tunggal $iothub/responses
untuk semua operasi ReqRep. Berlangganan/berhenti berlangganan dari topik ini untuk operasi klien-ke-server tidak diperlukan - server mengasumsikan semua klien untuk berlangganan.
Contoh interaksi ReqRep sederhana
Permintaan:
PUBLISH
QoS: 0
Topic: $iothub/{request.path}
Correlation_Data: 0x01 0xFA
Payload: ...
Respons (berhasil):
PUBLISH
QoS: 0
Topic: $iothub/responses
Correlation_Data: 0x01 0xFA
Payload: ...
Interaksi ReqRep tidak mendukung paket PUBLISH
dengan QoS: 1
sebagai pesan permintaan atau respons. Mengirim Permintaan PUBLISH
menghasilkan respons Bad Request
.
Panjang maksimum yang didukung dalam properti Correlation Data
adalah 16 byte. Jika properti Correlation Data
pada paket PUBLISH
diatur ke nilai yang lebih panjang dari 16 byte, IoT Hub mengirimkan DISCONNECT
dengan hasil Bad Request
, dan menutup koneksi. Perilaku ini hanya berlaku untuk paket yang ditukar dalam API ini.
Catatan
Data Korelasi adalah urutan byte arbitrer, misalnya tidak dijamin menjadi string UTF-8.
ReqRep menggunakan topik yang telah ditentukan sebelumnya untuk respons; Properti Topik Respons dalam paket Permintaan PUBLISH
(jika diatur oleh pengirim) diabaikan.
IoT Hub secara otomatis membuat klien berlangganan topik respons untuk semua operasi ReqRep klien-ke-server. Bahkan jika klien secara eksplisit berhenti berlangganan dari topik respons, IoT Hub mengaktifkan kembali langganan secara otomatis. Untuk interaksi ReqRep server-ke-klien, perangkat masih perlu berlangganan.
Properti Pesan
Properti operasi - sistem atau yang ditentukan pengguna - dinyatakan sebagai properti paket di MQTT 5.
Nama properti pengguna peka huruf besar/kecil dan harus dieja persis seperti yang ditentukan. Misalnya, Trace-ID
tidak didukung saat trace-id
didukung.
Permintaan dengan properti Pengguna di luar spesifikasi dan tanpa awalan @
menghasilkan kesalahan.
Properti sistem dikodekan sebagai properti kelas satu (misalnya, Content Type
) atau sebagai properti Pengguna. Spesifikasi menyediakan daftar lengkap properti sistem yang didukung.
Semua properti kelas satu diabaikan kecuali dukungan untuk properti tersebut secara eksplisit dinyatakan dalam spesifikasi.
Jika properti yang ditentukan pengguna diizinkan, namanya harus mengikuti format @{property name}
. Properti yang ditentukan pengguna hanya mendukung nilai string UTF-8 yang valid. misalnya, properti MyProperty1
dengan nilai 15
harus dikodekan sebagai properti Pengguna dengan nama @MyProperty
dan nilai 15
.
Jika IoT Hub tidak mengenali properti Pengguna, IoT Hub dianggap sebagai kesalahan, dan IoT Hub merespons dengan PUBACK
dengan Reason Code: 0x83
(Kesalahan khusus implementasi) dan status: 0100
(Permintaan Buruk). Jika pengakuan tidak diminta (QoS: 0), DISCONNECT
paket dengan kesalahan yang sama dikirim kembali dan koneksi dihentikan.
API ini menentukan jenis data berikut selain string
:
time
: jumlah milidetik sejak1970-01-01T00:00:00.000Z
. Misalnya,1600987195320
untuk2020-09-24T22:39:55.320Z
,u32
: bilangan bulat 32-bit yang tidak ditandatangani,u64
: bilangan bulat 64-bit yang tidak ditandatangani,i32
: bilangan bulat 32-bit yang ditandatangani.
Respons
Interaksi dapat menghasilkan hasil yang berbeda: Success
, Bad Request
, Not Found
, dan lainnya.
Hasil dibedakan satu sama lain oleh properti pengguna status
. Reason Code
dalam paket PUBACK
(untuk interaksi MessageAck) mencocokkan status
dalam arti jika memungkinkan.
Catatan
Jika klien menentukan Request Problem Information: 0
dalam paket CONNECT, tidak ada properti pengguna yang akan dikirim pada paket PUBACK
untuk memenuhi spesifikasi MQTT 5, termasuk properti status
. Dalam hal ini, klien masih dapat mengandalkan Reason Code
untuk menentukan apakah pengakuan itu positif atau negatif.
Setiap interaksi memiliki default (atau berhasil). Ini memiliki Reason Code
0
dan properti status
"tidak diatur". Sebaliknya:
- Untuk interaksi MessageAck,
PUBACK
mendapatkanReason Code
selain 0x0 (Berhasil). Propertistatus
mungkin ada untuk lebih memperjelas hasilnya. - Untuk interaksi ReqRep, Respons
PUBLISH
mendapatkan kumpulan propertistatus
. - Karena tidak ada cara untuk merespons interaksi MessageAck dengan
QoS: 0
secara langsung, paketDISCONNECT
dikirim sebagai gantinya dengan informasi respons, diikuti dengan pemutusan sambungan.
Contoh:
Permintaan Buruk (MessageAck):
PUBACK
Reason_Code: 131
status: 0100
reason: Unknown property `test`
Tidak Diotorisasi (MessageAck):
PUBACK
Reason_Code: 135
status: 0101
Tidak Diotorisasi (ReqRep):
PUBLISH
QoS: 0
Topic: $iothub/responses
Correlation_Data: ...
status: 0101
Jika diperlukan, IoT Hub mengatur properti pengguna berikut:
status
- Kode diperpanjang IoT Hub untuk status operasi. Kode ini dapat digunakan untuk membedakan hasil.trace-id
– ID pelacakan untuk operasi; IoT Hub mungkin menyimpan lebih banyak diagnostik mengenai operasi yang dapat digunakan untuk penyelidikan internal.reason
- pesan yang dapat dibaca manusia yang memberikan informasi lebih lanjut tentang mengapa operasi berakhir dalam keadaan yang ditunjukkan oleh propertistatus
.
Catatan
Jika klien mengatur properti Maximum Packet Size
dalam paket CONNECT ke nilai yang sangat kecil, tidak semua properti pengguna mungkin pas dan tidak akan muncul dalam paket.
reason
dimaksudkan hanya untuk orang dan tidak boleh digunakan dalam logika klien. API ini memungkinkan pesan diubah kapan saja tanpa peringatan atau perubahan versi.
Jika klien mengirim RequestProblemInformation: 0
dalam paket CONNECT, properti pengguna tidak akan disertakan dalam pengakuan sesuai spesifikasi MQTT 5.
Kode status
Properti status
membawa kode status untuk operasi. Ini dioptimalkan untuk efisiensi membaca komputer.
Ini terdiri dari bilangan bulat dua byte yang tidak bertanda yang dikodekan sebagai hex dalam string seperti 0501
.
Struktur kode (peta 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
Byte pertama digunakan untuk bendera:
- bit 0 dan 1 menunjukkan jenis hasil:
00
- berhasil01
- kesalahan klien10
- kesalahan server
- bit 2:
1
menunjukkan kesalahan dapat dicoba lagi - bit 3 sampai 7 dicadangkan dan harus diatur ke
0
Byte kedua berisi kode respons nyata yang berbeda. Kode galat dengan bendera yang berbeda dapat memiliki nilai byte kedua yang sama. Misalnya, mungkin ada kode galat 0001
, 0101
, 0201
, 0301
yang memiliki arti berbeda.
Misalnya, Too Many Requests
adalah klien, kesalahan yang dapat coba lagi dengan kode sendiri 1
. Nilainya adalah 0000 0101 0000 0001
atau 0x0501
.
Klien dapat menggunakan bit jenis untuk mengidentifikasi apakah operasi berhasil diselesaikan. Klien juga dapat menggunakan bit yang dapat dicoba lagi untuk memutuskan apakah masuk akal untuk mencoba kembali operasi.
Rekomendasi
Manajemen sesi
Paket CONNACK
membawa properti Session Present
untuk menunjukkan apakah server memulihkan sesi yang dibuat sebelumnya. Gunakan properti ini untuk mengetahui apakah akan berlangganan topik atau melewatkan berlangganan karena langganan dilakukan lebih awal.
Untuk mengandalkan Session Present
,klien harus melacak langganan yang dibuatnya (yaitu, mengirim paket SUBSCRIBE
dan menerima SUBACK
dengan kode alasan yang berhasil), atau pastikan untuk berlangganan semua topik dalam satu pertukaran SUBSCRIBE
/ SUBACK
. Jika tidak, jika klien mengirim dua SUBSCRIBE
paket, dan server hanya memproses salah satunya dengan sukses, server berkomunikasi Session Present: 1
CONNACK
sambil hanya memiliki bagian dari langganan klien yang diterima.
Untuk mencegah kasus di mana versi klien yang lebih lama tidak berlangganan semua topik, lebih baik untuk berlangganan tanpa syarat ketika perilaku klien berubah (misalnya, sebagai bagian dari pembaruan firmware). Juga, untuk memastikan tidak ada langganan usang yang tertinggal (mengambil dari jumlah maksimum langganan yang diizinkan), secara eksplisit berhenti berlangganan dari langganan yang tidak lagi digunakan.
Pembuatan batch
Tidak ada format khusus untuk mengirim batch pesan. Untuk mengurangi overhead operasi intensif sumber daya di TLS dan jaringan, paket bundel (PUBLISH
, PUBACK
, SUBSCRIBE
, dan sebagainya tidak) bersama-sama sebelum menyerahkannya ke tumpukan TLS/TCP yang mendasarinya. Selain itu, klien dapat membuat topik alias lebih mudah dalam "batch":
- Masukkan nama topik lengkap di paket
PUBLISH
pertama untuk koneksi dan kaitkan topik alias dengannya, - Letakkan paket berikut untuk topik yang sama dengan nama topik kosong dan properti alias topik.
Migration
Bagian ini mencantumkan perubahan dalam API dibandingkan dengan dukungan MQTT sebelumnya.
- Protokol transportasi adalah MQTT 5. Sebelumnya - MQTT 3.1.1.
- Informasi konteks untuk Autentikasi SAS terkandung dalam paket
CONNECT
secara langsung sebagai ganti dari dikodekan bersama dengan tanda tangan. - Metode Autentikasi digunakan untuk menunjukkan metode otentikasi yang digunakan.
- Tanda Tangan Akses Bersama dimasukkan ke dalam properti Data Autentikasi. Sebelumnya bidang Kata Sandi digunakan.
- Topik untuk operasi berbeda:
- Telemetri:
$iothub/telemetry
bukannyadevices/{Client Id}/messages/events
, - Perintah:
$iothub/commands
bukannyadevices/{Client Id}/messages/devicebound
, - Patch Ganda Dilaporkan:
$iothub/twin/patch/reported
bukannya$iothub/twin/PATCH/properties/reported
, - Beri tahu Status Ganda yang Diinginkan Berubah:
$iothub/twin/patch/desired
bukannya$iothub/twin/PATCH/properties/desired
.
- Telemetri:
- Berlangganan untuk topik respons operasi permintaan-respons klien-server tidak diperlukan.
- Properti pengguna digunakan sebagai ganti properti pengodean di segmen nama topik.
- nama properti dieja dalam konvensi penamaan "tanda hubung" alih-alih singkatan dengan awalan khusus. Properti yang ditentukan pengguna sekarang memerlukan awalan sebagai gantinya. Misalnya,
$.mid
sekarangmessage-id
, sementaramyProperty1
menjadi@myProperty1
. - Properti Data Korelasi digunakan untuk mengkorelasikan pesan permintaan dan respons untuk operasi permintaan-respons sebagai ganti dari properti
$rid
yang dikodekan dalam topik. - Properti
iothub-connection-auth-method
tidak lagi ditandai pada peristiwa telemetri. - Perintah C2D tidak dihapus menyeluruh tanpa langganan dari perangkat. Mereka tetap mengantre sampai perangkat berlangganan atau kedaluwarsa.
Contoh
Kirim telemetri
Pesan:
-> 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>
Pengakuan:
<- PUBACK
Packet_Id: 31
Reason_Code: 0
Pengakuan alternatif (dibatasi):
<- PUBACK
Packet_Id: 31
Reason_Code: 151
status: 0501
Mengiirim dapatkan status ganda
Permintaan:
-> PUBLISH
QoS: 0
Topic: $iothub/twin/get
Correlation_Data: 0x01 0xFA
Payload: <empty>
Respons (berhasil):
<- PUBLISH
QoS: 0
Topic: $iothub/responses
Correlation_Data: 0x01 0xFA
Payload: <twin/desired state>
Respons (tidak diperbolehkan):
<- PUBLISH
QoS: 0
Topic: $iothub/responses
Correlation_Data: 0x01 0xFA
status: 0102
reason: Operation not allowed for `B2` SKU
Payload: <empty>
Menangani panggilan metode langsung
Permintaan:
<- PUBLISH
QoS: 0
Topic: $iothub/methods/abc
Correlation_Data: 0x0A 0x10
Payload: <data>
Respons (berhasil):
-> PUBLISH
QoS: 0
Topic: $iothub/responses
Correlation_Data: 0x0A 0x10
response-code: 200 # user defined response code
Payload: <data>
Catatan
status
tidak diatur - ini adalah respons berhasil.
Respons Perangkat Tidak Tersedia:
-> PUBLISH
QoS: 0
Topic: $iothub/responses
Correlation_Data: 0x0A 0x10
status: 0603
Kesalahan saat menggunakan QoS 0, bagian 1
Permintaan:
-> 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>
Respons:
<- DISCONNECT
Reason_Code: 144
reason: "Unsupported topic: `$iothub/twin/gett`"
Kesalahan saat menggunakan QoS 0, bagian 2
Permintaan:
-> PUBLISH # missing Correlation Data
QoS: 0
Topic: $iothub/twin/get
Payload: <data>
Respons:
<- DISCONNECT
Reason_Code: 131
status: 0100
reason: "`Correlation Data` property is missing"
Langkah berikutnya
- Untuk meninjau referensi API pratinjau MQTT 5, lihat referensi API MQTT 5 sarana data IoT Hub (pratinjau).
- Untuk mengikuti sampel C#, lihat repositori sampel GitHub.