MQTT 是一種輕量級的物聯網通訊協定,適用於低頻寬和不穩定網路環境。連線訊息中包含 clientID、cleanSession、cleanStart 和 Username 等欄位,用於建立和管理連線。MQTT 連線過程包含客戶端傳送連線請求、伺服器驗證和回應等步驟。在物聯網應用中,MQTT 廣泛應用於智慧家居、工業自動化等場景。Python 的 Paho MQTT 庫提供簡便的連線和訊息釋出功能。MQTT 5 引入了更彈性的使用者名稱和密碼機制、新的連線傳回碼以及更詳細的釋出格式。Will 訊息機制可在客戶端異常斷線時通知其他裝置。理解 MQTT 的核心概念和引數設定,有助於開發者設計更可靠的物聯網應用。
連線訊息結構
連線訊息包含以下欄位:
- clientID:必需欄位,識別使用者端並向伺服器註冊。每個使用者端都有唯一的 client ID,長度可在 1 到 23 個 UTF-8 位元組之間。
- cleanSession:選擇性欄位,決定是否啟用清除工作階段(clean session)功能。
- 0:伺服器必須恢復與使用者端的通訊,且使用者端和伺服器必須在斷線後儲存工作階段狀態。
- 1:使用者端和伺服器必須丟棄先前的工作階段並啟動新的工作階段。
- cleanStart:MQTT 5 所需欄位,作為一個旗標,允許代理伺服器丟棄任何先前的工作階段資料。使用者端然後啟動一個新的工作階段。cleanStart 旗標不會在 TCP 連線關閉時清除最後的工作階段;相反,會設定一個叫做工作階段過期間隔(Session Expiry Interval)的計時器,當工作階段實際清除時會觸發超時。
- Username:選擇性欄位,指定使用者名稱稱。
MQTT 連線過程
當使用者端傳送連線訊息給伺服器時,伺服器會根據連線訊息中的欄位進行相應的處理。以下是 MQTT 連線過程的簡要概述:
- 使用者端傳送連線訊息給伺服器。
- 伺服器接收連線訊息並驗證 client ID。
- 如果 cleanSession 欄位設為 0,伺服器會恢復與使用者端的通訊,並儲存工作階段狀態。
- 如果 cleanSession 欄位設為 1,伺服器會丟棄先前的工作階段並啟動新的工作階段。
- 伺服器處理 cleanStart 旗標和 Username 欄位(如果存在)。
- 伺服器回應連線確認訊息給使用者端。
實際應用
MQTT 通訊協定在物聯網應用中非常常見,例如智慧家居、工業自動化、車聯網等領域。瞭解 MQTT 連線訊息的結構和過程可以幫助開發人員設計和實現更可靠、更高效的 IoT 應用。
程式碼示例
以下是使用 Python 和 Paho MQTT 庫建立 MQTT 連線的示例:
import paho.mqtt.client as mqtt
# 設定 client ID 和 cleanSession
client_id = "my_client"
clean_session = 1
# 建立 MQTT 連線
client = mqtt.Client(client_id, clean_session)
# 連線到伺服器
client.connect("localhost", 1883)
# 傳送連線訊息
client.loop_start()
圖表翻譯
flowchart TD A[使用者端] -->|連線訊息|> B[伺服器] B -->|驗證 client ID|> C[伺服器] C -->|恢復通訊|> D[使用者端] D -->|啟動新工作階段|> E[伺服器] E -->|處理 cleanStart 旗標|> F[伺服器] F -->|回應連線確認訊息|> G[使用者端]
內容解密
MQTT 連線訊息的結構和過程是 IoT 應用中非常重要的知識。瞭解這些知識可以幫助開發人員設計和實現更可靠、更高效的 IoT 應用。在實際應用中,MQTT 連線訊息的處理需要考慮到 cleanSession 和 cleanStart 旗標的設定,以確保使用者端和伺服器之間的通訊是正確和高效的。
MQTT 通訊協定深度剖析
MQTT(Message Queuing Telemetry Transport)是一種廣泛使用的物聯網通訊協定,特別適用於邊緣裝置和雲端之間的資料傳輸。玄貓將深入探討 MQTT 的核心組成部分和引數設定,以便更好地理解其工作原理。
連線設定
在建立 MQTT 連線時,需要設定幾個重要的引數。其中,username 和 password 是用於身份驗證的。特別是在 MQTT 3.1.1 版本中,如果使用密碼,則必須提供這兩個引數。玄貓將使用這些引數來確保連線的安全性。
import paho.mqtt.client as mqtt
# 定義 MQTT 連線設定
username = "玄貓"
password = "password123"
# 建立 MQTT 客戶端
client = mqtt.Client()
# 設定連線引數
client.username_pw_set(username, password)
Will 訊息設定
Will 訊息(Last Will and Testament)是一種特殊的訊息,當 MQTT 客戶端與伺服器斷開連線時,伺服器會傳送這個訊息給其他客戶端。玄貓可以設定 Will 訊息的主題、QoS 等級和 payload。
// 定義 Will 訊息設定
let last_will_topic = "will/topic";
let last_will_qos = 1;
let last_will_message = "斷開連線";
// 設定 Will
## MQTT 5 的連線和釋出機制
MQTT 5 是一種物聯網通訊協定,提供了更高的靈活性和安全性。與 MQTT 3.1.1 相比,MQTT 5 有了一些重要的改進。
### 連線機制
在 MQTT 5 中,使用者名稱和密碼欄位是可選的。這意味著您可以獨立使用使用者名稱或密碼,或者兩者都使用。這個功能在某些情況下非常有用,例如使用 OAuth 驗證服務。
在 MQTT 3.1.1 中,如果您選擇使用密碼,則必須提供使用者名稱。這可能會導致一些不便,因為某些解決方案可能需要使用 JSON 物件作為使用者名稱。MQTT 5 解決了這個問題,允許您獨立使用使用者名稱或密碼。
### 連線傳回碼
當客戶端連線到伺服器時,伺服器會傳回一個連線傳回碼。這個傳回碼指示連線是否成功,或者如果連線被拒絕,則傳回碼會指示原因。MQTT 5 添加了一些新的傳回碼,包括:
* 0:連線成功
* 1:連線被拒絕,因為 MQTT 協定版本不被接受
* 2:連線被拒絕,因為客戶端識別符不被允許
* 4:連線被拒絕,因為使用者名稱或密碼不正確
* 5:連線被拒絕,因為客戶端沒有許可權連線
### 釋出格式
當客戶端連線到伺服器後,可以釋出資料到某個主題分支。每個釋出訊息包含以下欄位:
* packetID:唯一識別釋出訊息的 ID
* topicName:釋出訊息的主題分支
* qos:釋出訊息的 QoS 等級(0、1 或 2)
* retainFlag:是否保留釋出訊息
這些欄位組成了釋出訊息的格式,允許客戶端和伺服器之間進行高效和可靠的通訊。
### Mermaid 圖表
```mermaid
flowchart TD
A[客戶端] --> B[連線到伺服器]
B --> C[伺服器傳回連線碼]
C --> D[連線成功]
D --> E[釋出訊息]
E --> F[伺服器處理釋出訊息]
F --> G[傳回結果]
圖表翻譯
這個 Mermaid 圖表展示了客戶端和伺服器之間的連線和釋出訊息的過程。客戶端首先連線到伺服器,然後伺服器傳回一個連線碼。如果連線成功,客戶端可以釋出訊息到某個主題分支。伺服器接收到釋出訊息後,會進行處理並傳回結果。
內容解密
這個部分解釋了 MQTT 5 的連線和釋出機制。MQTT 5 提供了更高的靈活性和安全性,允許客戶端和伺服器之間進行高效和可靠的通訊。透過瞭解連線傳回碼和釋出格式,開發人員可以更好地設計和實現 MQTT 5 的應用。
MQTT 通訊協定深度剖析
MQTT(Message Queuing Telemetry Transport)是一種廣泛使用的物聯網通訊協定,尤其是在邊緣計算和雲端計算的應用中。它的設計宗旨是為了在低頻寬和高延遲的網路環境中提供高效的訊息傳遞機制。MQTT 的核心思想是根據釋出/訂閱(Publish/Subscribe)模式,讓裝置和應用程式能夠透過主題(Topic)進行通訊。
MQTT 訊息格式
MQTT 訊息由兩個部分組成:固定頭(Fixed Header)和可變頭(Variable Header)。固定頭包含了訊息的基本資訊,如訊息型別、 DUP 標誌、QoS 等級和保留位元。可變頭則包含了與特定訊息型別相關的資訊,例如 CONNECT 訊息中的客戶端 ID 和認證資訊。
SUBSCRIBE 訊息格式
SUBSCRIBE 訊息是用於客戶端向伺服器訂閱特定主題的訊息。其格式如下:
packetID
:唯一識別此訊息的 ID,由客戶端庫負責。topic_1
:第一個要訂閱的主題。qos_1
:第一個主題的 QoS 等級。topic_2
和qos_2
:可選的額外主題和其 QoS 等級。
主題過濾和萬用字元
MQTT 支援使用萬用字元來過濾主題,讓客戶端能夠訂閱多個相關主題。有兩種萬用字元:
+
:單層萬用字元,能夠替代主題名稱中的單一層級。例如,US/+/Milwaukee
能夠匹配所有州的 Milwaukee。#
:多層萬用字元,能夠替代主題名稱中的多個層級。例如,US/Wisconsin/#
能夠匹配所有威斯康辛州的城市。
此外,還有特殊主題以 $
符號開頭,通常用於統計或系統相關的主題。客戶端不能釋出到這些主題。
MQTT 伺服器和客戶端庫
一個 MQTT 伺服器應該支援主題名稱中的萬用字元,但這不是強制性的。如果伺服器不支援萬用字元,則必須拒絕這些請求。設定 packetID
是 MQTT 客戶端庫的責任。
實踐應用和標準
MQTT 3.1.1 是一個成熟的版本,提供了廣泛的功能和彈性。MQTT 5.0 則是最新的版本,引入了更多的功能和改進。Google Cloud Platform(GCP)是支援 MQTT 的雲端平臺之一,提供了 MQTT 伺服器和客戶端庫的實踐應用。
內容解密:
上述內容對 MQTT 通訊協定的基本概念、訊息格式、SUBSCRIBE 訊息、主題過濾和萬用字元、MQTT 伺服器和客戶端庫、實踐應用和標準進行了詳細的介紹。透過這些知識,開發者可以更好地理解和應用 MQTT,在物聯網領域中開發出高效和可靠的應用程式。
圖表翻譯:
flowchart TD A[Mqtt Client] -->|SUBSCRIBE|> B[Mqtt Broker] B -->|PUBLISH|> A A -->|UNSUBSCRIBE|> B B -->|DISCONNECT|> A
這個 Mermaid 圖表展示了 MQTT 客戶端和伺服器之間的基本互動過程,包括訂閱、釋出、取消訂閱和斷開連線。這個過程是 MQTT 通訊協定的核心,讓裝置和應用程式能夠透過主題進行通訊。
MQTT雲端服務與Google IoT Core整合
在本章節中,我們將探討如何將MQTT客戶端和資料接收器整合到Google IoT Core雲端服務中。MQTT雲端服務通常遵循類似的模型,因此這個框架可以作為參考。為了開始使用Google Cloud Platform(GCP),我們需要先完成一些初步步驟,包括建立Google帳戶和設定付款系統。您可以參考以下指示以開始使用Google IoT Core:docs/how-tos/getting-started。
建立裝置和啟用Google API
在GCP中,建立一個裝置、啟用Google API、建立一個主題分支、並將一個成員新增到釋出/訂閱釋出者中。Google IoT Core需要強加密(TLS)和JSON Web Token(JWT)憑證代理,以確保所有資料包的加密。
MQTT 3.1.1代理和Paho MQTT客戶端
MQTT 3.1.1代理由玄貓啟動。Paho MQTT客戶端是一個由Eclipse贊助的專案,也是IBM MQTT專案的原始家園。Paho也是Eclipse M2M Industry Working Group的核心交付專案。其他MQTT訊息代理的變體包括Eclipse Mosquitto專案和Rabbit MQ。
Python範例:釋出Hello World字串到主題分支
以下是使用Paho MQTT客戶端釋出Hello World字串到主題分支的Python範例:
import datetime
import os
import time
import paho.mqtt.client as mqtt
import jwt
project_id = '您的專案名稱'
cloud_region = 'us-central1'
registry_id = '您的登記ID'
device_id = '您的裝置ID'
algorithm = 'RS256'
mqtt_port = 8883
ca_certs_name = 'roots.pem'
private_key_file = '/Users/joeuser/mqtt/rsa_private.pem'
# 建立JWT物件
def create_jwt(project_id, private_key_file, algorithm):
token = {
# 釋出時間
'iat': datetime.datetime.utcnow(),
# 到期時間
'exp': datetime.datetime.utcnow() + datetime.timedelta(minutes=60),
}
# 使用私鑰簽署JWT
token = jwt.encode(token, private_key_file, algorithm=algorithm)
return token
# 連線MQTT代理
client = mqtt.Client()
client.username_pw_set(device_id, password=create_jwt(project_id, private_key_file, algorithm))
client.connect('mqtt.googleapis.com', mqtt_port, ca_certs=ca_certs_name)
# 釋出訊息
client.publish('devices/{}/events'.format(device_id), 'Hello World')
圖表翻譯:
flowchart TD A[裝置] --> B[MQTT代理] B --> C[Google IoT Core] C --> D[釋出/訂閱] D --> E[裝置] E --> F[MQTT代理] F --> G[Google IoT Core]
內容解密:
在上面的範例中,我們使用Paho MQTT客戶端連線到Google IoT Core的MQTT代理,並使用JWT憑證代理進行身份驗證。然後,我們釋出了一個Hello World字串到主題分支中。這個範例展示瞭如何使用MQTT客戶端和Google IoT Core進行資料釋出和接收。
MQTT 客戶端與 Google IoT 連線
MQTT(Message Queuing Telemetry Transport)是一種輕量級的物聯網通訊協定,廣泛用於物聯網裝置與雲端服務之間的通訊。Google IoT Core 是一種完全受管理的服務,允許您安全地連線、管理和分析您的 IoT 裝置。以下是使用 Python 和 MQTT 客戶端庫建立 Google IoT Core 連線的範例。
JWT 認證
首先,我們需要建立一個 JWT(JSON Web Token)令牌,作為認證使用。這個令牌包含了裝置的資訊和私密金鑰。
import datetime
import jwt
def create_jwt(project_id, private_key_file, algorithm):
# 讀取私密金鑰檔案
with open(private_key_file, 'r') as f:
private_key = f.read()
# 建立 JWT 令牌
token = {
'iat': datetime.datetime.utcnow(),
'exp': datetime.datetime.utcnow() + datetime.timedelta(minutes=60),
'aud': project_id
}
return jwt.encode(token, private_key, algorithm=algorithm)
MQTT 客戶端設定
接下來,我們需要設定 MQTT 客戶端。Google IoT Core 需要一個特定的客戶端 ID 格式,包含了專案 ID、區域、登入 ID 和裝置 ID。
import mqtt
def main():
client = mqtt.Client(
client_id=('projects/{}/locations/{}/registries/{}/devices/{}'
.format(project_id, cloud_region, registry_id, device_id))
)
# 設定使用者名稱和密碼(使用 JWT 令牌)
client.username_pw_set(
username='unused', # Google 忽略使用者名稱
password=create_jwt(project_id, private_key_file, algorithm)
)
連線 Google IoT Core
現在,我們可以連線到 Google IoT Core 的 MQTT 伺服器。
client.connect('mqtt.googleapis.com', 8883)
釋出訊息
連線成功後,我們可以釋出訊息到指定的主題。
client.publish('topics/branch', 'Hello World!')
QoS 等級
在釋出訊息時,我們需要設定 QoS(Quality of Service)等級。QoS 等級決定了訊息傳遞的保證級別。
client.publish('topics/branch', 'Hello World!', qos=1)
MQTT 通訊協定與其在物聯網中的應用
MQTT(Message Queuing Telemetry Transport)是一種輕量級的通訊協定,廣泛應用於物聯網(IoT)領域。它的設計宗旨是為了在低頻寬和不穩定的網路環境中提供可靠的訊息傳遞服務。MQTT 通訊協定支援多種網路拓撲,包括點對點、釋出/訂閱等模式。
MQTT 的工作原理
MQTT 的工作原理如下:
- 連線: 客戶端(Client)連線到伺服器(Server),並建立一個會話(Session)。
- 釋出: 客戶端釋出訊息到伺服器,伺服器將訊息轉發給所有訂閱了該主題(Topic)的客戶端。
- 訂閱: 客戶端訂閱一個或多個主題,當伺服器收到釋出到該主題的訊息時,將其轉發給訂閱了該主題的客戶端。
- 斷開連線: 客戶端斷開與伺服器的連線。
MQTT-SN
MQTT-SN(MQTT for Sensor Networks)是一種根據 MQTT 的通訊協定,專門設計用於感知器網路(Sensor Networks)。它的設計目的是為了在低頻寬和低功耗的環境中提供可靠的訊息傳遞服務。MQTT-SN 支援多種網路拓撲,包括無線個人區域網路(Wireless Personal Area Network, WPAN)。
MQTT-SN 的架構和拓撲
MQTT-SN 的架構和拓撲如下:
- 閘道器(Gateway): 閘道器負責將 MQTT-SN 訊息轉換為 MQTT 訊息,反之亦然。
- 轉發器(Forwarder): 轉發器負責將 MQTT-SN 訊息轉發給目的地。
- 客戶端(Client): 客戶端可以釋出和訂閱訊息。
- 代理器(Broker): 代理器負責管理 MQTT-SN 訊息的轉發和儲存。
MQTT-SN 的優點
MQTT-SN 的優點如下:
- 低功耗: MQTT-SN 設計用於低功耗的環境。
- 低頻寬: MQTT-SN 支援低頻寬的網路環境。
- 可靠性: MQTT-SN 提供可靠的訊息傳遞服務。
圖表翻譯:
此圖表展示了 MQTT 客戶端、伺服器和主題之間的關係。MQTT 客戶端連線到伺服器,然後釋出訊息到主題。主題接收到訊息後,將其轉發給所有訂閱了該主題的客戶端。客戶端接收到訊息後,將其處理並顯示出來。
MQTT-SN_gateway_配置與廣告
在MQTT-SN中,gateway可以扮演兩種不同的角色。首先,透明gateway會管理多個獨立的MQTT-SN串流,並將每個串流轉換成MQTT訊息。另一方面,聚合gateway會將多個MQTT-SN串流合併成少數的MQTT串流,然後傳送到雲端的MQTT代理。聚合gateway的設計更為複雜,但可以減少通訊的額外負擔和伺服器上同時開啟的連線數量。
Gateway廣告和發現
由於MQTT-SN的拓樸結構比MQTT更為複雜,因此需要一個發現過程來建立多個gateway和轉發節點之間的路由。當gateway加入MQTT-SN拓樸結構時,會先傳送廣告包給連線的使用者端或其他gateway。多個gateway可以存在於網路中,但使用者端只能連線到單一gateway。使用者端有責任儲存活躍的gateway列表和其網路地址。這個列表是由各種廣告和GWINFO訊息構建而成。
MQTT-SN中有一些新的訊息可用於協助發現和廣告:
- ADVERTISE:由gateway週期性廣播以宣告其存在。
- SEARCHGW:由使用者端廣播。這個訊息的一部分是半徑引數,指出SEARCHGW訊息應該在網路拓樸結構中跟隨的跳數。例如,值1表示單一跳,在非常密集的網路中,每個使用者端都可以用單一跳到達。
- GWINFO:這是gateway的回應,包含gateway ID和gateway地址,只有當SEARCHGW訊息從使用者端傳送時才會廣播。
MQTT和MQTT-SN的差異
MQTT-SN和MQTT之間的主要差異是:
- MQTT-SN不如MQTT流行。
- MQTT-SN中有三個CONNECT訊息,而MQTT中只有一個。額外的兩個用於明確傳輸Will主題和Will訊息。MQTT-SN可以在簡化的媒介和UDP上執行。
- MQTT主題名稱在MQTT-SN中被兩個位元組長的主題ID訊息取代,以協助無線網路中的頻寬限制。
- 預先定義的主題ID和短主題名稱可以在MQTT-SN中使用,而無需註冊。為了使用這個功能,客戶端和伺服器需要使用相同的主題ID。短主題名稱足夠短,可以嵌入PUBLISH訊息中。
- MQTT-SN引入了一個發現程式,以協助客戶端找到伺服器和gateway的網路地址。
- MQTT-SN中的cleanSession被擴充套件到Will功能。客戶端的訂閱可以被保留和儲存,但現在Will資料也被保留。
- MQTT-SN使用了一個修訂的keepAlive程式,以支援無線網路中的低功耗和低頻寬應用。
Mermaid 圖表
graph LR A[MQTT-SN使用者端] -->|SEARCHGW|> B[MQTT-SN Gateway] B -->|GWINFO|> A B -->|ADVERTISE|> A A -->|CONNECT|> B B -->|PUBLISH|> C[MQTT Broker] C -->|PUBLISH|> B B -->|PUBLISH|> A
圖表翻譯:
此圖表展示了MQTT-SN使用者端、MQTT-SN Gateway和MQTT Broker之間的溝透過程。使用者端首先傳送SEARCHGW訊息給Gateway,Gateway回應GWINFO訊息,然後使用者端傳送CONNECT訊息給Gateway。Gateway廣播ADVERTISE訊息宣告其存在。使用者端和Gateway可以傳送PUBLISH訊息給彼此,也可以傳送給MQTT Broker。MQTT Broker也可以傳送PUBLISH訊息給Gateway和使用者端。
選擇合適的MQTT代理伺服器
在構建MQTT解決方案時,架構師可以從眾多商業和開源代理伺服器中進行選擇。以下表格有助於識別一些選擇點和當前功能:
代理伺服器 | 開發者 | 組織 | 客戶端和/或代理伺服器 | MQTT版本 | 支援 | 開源/商業 | 備註功能 |
---|---|---|---|---|---|---|---|
Adafruit IO | Adafruit | 客戶端 | 3.1.1 | 是 | 開源(MIT) | 使用Ruby、Node.js等語言編寫 |
選擇合適的MQTT代理伺服器需要考慮多個因素,包括代理伺服器的開發者、組織、客戶端和代理伺服器的支援、MQTT版本、支援情況、開源或商業模式以及備註功能等。
內容解密:
上述表格中列出的代理伺服器都是目前較為流行的選擇,每個代理伺服器都有其自己的優缺點。例如,Adafruit IO是一個開源的代理伺服器,使用Ruby和Node.js等語言編寫,支援MQTT 3.1.1版本。然而,選擇代理伺服器時需要考慮的不僅僅是技術上的問題,也需要考慮商業上的支援和服務。
圖表翻譯:
graph LR A[選擇代理伺服器] --> B[考慮開發者和組織] B --> C[評估客戶端和代理伺服器支援] C --> D[檢查MQTT版本和支援] D --> E[評估開源或商業模式] E --> F[考慮備註功能] F --> G[最終選擇代理伺服器]
此圖表展示了選擇代理伺服器的流程,從考慮開發者和組織開始,到評估客戶端和代理伺服器支援,檢查MQTT版本和支援,評估開源或商業模式,考慮備註功能,最終選擇代理伺服器。
MQTT 協議在物聯網領域已成為連線裝置和雲端的主流方案。深入剖析 MQTT 的核心架構,可以發現其輕量級、低功耗和高可靠性的特性使其在資源受限的物聯網裝置上得到廣泛應用。MQTT 5.0 版本相較於 3.1.1 版本,在功能性和安全性方面都有顯著提升,例如更靈活的身份驗證機制和更細緻的 QoS 等級,可滿足更多樣化的應用場景。然而,MQTT-SN 作為 MQTT 的延伸,專注於感測器網路,其精簡的訊息格式和低功耗特性更適合功耗敏感的應用。
技術選型時,開發者需要根據具體應用場景的需求權衡 MQTT 和 MQTT-SN 的優劣。例如,在低功耗、低頻寬的感測器網路中,MQTT-SN 更具優勢;而在需要更豐富功能和更高安全性的場景下,MQTT 5.0 則更勝一籌。此外,選擇合適的 MQTT 代理伺服器也至關重要,需考量其效能、可靠性、安全性以及是否支援所需的 MQTT 版本。
展望未來,隨著物聯網裝置的爆炸式增長,MQTT 協議及其生態系統將持續演進。預計未來會有更多針對特定應用場景的 MQTT 擴充套件協議出現,例如更低功耗、更高效的協議版本。同時,安全性和可靠性仍將是 MQTT 發展的重點,以應對日益嚴峻的物聯網安全挑戰。玄貓認為,深入理解 MQTT 協議的不同版本和擴充套件,並結合實際應用場景進行技術選型,才能最大限度地發揮 MQTT 在物聯網領域的價值。對於資源有限的物聯網應用,建議優先評估 MQTT-SN 的適用性,以降低功耗和頻寬成本。