用AWS IoT Core MQTT訂閱溫度數據:5分鐘打通感測器到雲端
工廠IT技術人員專用AWS IoT CoreMQTT訂閱ATLANTIS 自有品牌
用AWS IoT Core MQTT訂閱溫度數據：5分鐘打通感測器到雲端
「Re-Atlantis」是我們的品牌使命——重現古代理想文明對精密測量的追求。當柏拉圖描繪的理想國強調秩序與精準，我們相信，資料從感測器到雲端的每一段路徑，也應該同樣精準、同樣可被驗證。這也是為什麼本篇要特別聚焦在「訂閱（Subscribe）」——因為沒有驗證過的資料流，永遠不能算是真正打通了雲端。詳見 ATLANTIS 品牌故事。
一、發布（Publish）與訂閱（Subscribe）：MQTT的核心概念
在第一篇文章中，我們示範了如何把 RS-485 溫度數據透過 MQTT 協定「發布（Publish）」到 AWS IoT Core。但發布之後，資料去了哪裡？誰能看到？這就是本篇要解決的問題——訂閱（Subscribe）。
完成第一次訂閱驗證
影響資料送達可靠度
主控台測試客戶端免費
可對應多個MQTT主題
MQTT（Message Queuing Telemetry Transport）是一種「發布/訂閱」（Pub/Sub）架構的輕量級通訊協定，專為頻寬有限、網路不穩定的物聯網環境設計——這正好符合工廠現場的網路條件。在這個架構下，發布者（Publisher）與訂閱者（Subscriber）互不直接連線，而是透過一個「訊息代理（Broker）」中介，AWS IoT Core本身就是這個Broker。
為什麼工廠IT一定要學會「訂閱」？
很多工廠在導入雲端監控時，只完成了「發布」這一步，就急著往下做Lambda、DynamoDB、儀表板，卻從未親自驗證過「資料到底有沒有正確送達」。這會導致一個常見的除錯困境：當儀表板顯示的數據異常時，工程師不知道問題出在感測器、閘道器、網路，還是雲端規則設定。而學會用MQTT訂閱工具直接查看Broker上的原始訊息，正是排除這種困境最快的方法。
二、5分鐘實作：用AWS IoT Core主控台的MQTT測試客戶端訂閱數據
本篇的重點在於④與⑤：先用主控台的MQTT測試客戶端快速驗證資料流是否暢通（不需寫任何程式），確認無誤後，再進一步用Python程式訂閱同一個主題，把資料接進自己的應用程式或後續的Lambda處理流程。
步驟一：登入AWS IoT Core主控台
登入AWS管理主控台後，搜尋「IoT Core」進入服務頁面，左側選單找到「MQTT測試客戶端（MQTT test client）」。這是AWS內建的網頁版MQTT用戶端，不需要安裝任何軟體，也不需要憑證即可測試（僅限主控台內部使用，實際裝置仍須憑證驗證）。
步驟二：訂閱主題
在「訂閱主題」欄位輸入 factory/line1/temperature（或使用萬用字元 factory/# 訂閱該路徑下所有子主題），點擊「訂閱」。此時畫面會進入等待狀態，等待有裝置發布訊息到這個主題。
步驟三：從現場執行發布程式，觀察是否即時顯示
接著回到第一篇文章的範例二（Python發布程式），在現場工控電腦上執行。若一切設定正確，主控台的訂閱畫面會在1～2秒內顯示剛剛發布的JSON訊息內容，包含溫度值、裝置ID與時間戳記。
驗證成功時，你應該會看到類似這樣的訊息
"device_id": "ATL-STT-001",
"temperature": 68.4,
"unit": "C",
"timestamp": 1784812345
}
如果5分鐘內沒有看到任何訊息，代表資料流中斷在某個環節——可能是憑證權限不足、主題名稱打錯、或現場網路無法連上AWS端點。下一節會列出常見排錯清單。
三、MQTT主題命名規則：工廠現場的最佳實踐
很多工廠在剛開始導入時，會把所有感測器都發布到同一個籠統的主題（例如 sensor/data），結果隨著感測點增加，資料變得難以區分與管理。以下是我們建議的主題命名結構，兼顧擴充性與查詢彈性。
| 主題階層 | 範例值 | 用途說明 |
|---|---|---|
| 廠區 | factory | 固定前綴，識別為工廠端資料 |
| 廠區代號 | taipei-plant1 | 若有多廠區，於此區分 |
| 產線代號 | line1 | 識別資料來源產線 |
| 裝置類型 | temperature / pressure | 區分感測器類型，方便訂閱時篩選 |
| 裝置ID | ATL-STT-001 | 唯一識別碼，對應實體變送器 |
完整主題範例：factory/taipei-plant1/line1/temperature/ATL-STT-001。這樣的結構讓你可以用萬用字元彈性訂閱，例如訂閱 factory/taipei-plant1/line1/temperature/# 只看該產線所有溫度數據，或訂閱 factory/+/+/temperature/#（+代表單層萬用字元）跨廠區查看所有溫度類感測器，而不需要為每個裝置寫死固定訂閱清單。
MQTT的三種QoS等級：資料送達可靠度的關鍵設定
| QoS等級 | 送達保證 | 適用情境 | 工廠應用建議 |
|---|---|---|---|
| QoS 0 | 最多送達一次（可能遺失） | 對即時性要求高、可容忍偶爾漏資料 | 高頻率但非關鍵的環境監測（如一般溫濕度） |
| QoS 1 | 至少送達一次（可能重複） | 資料完整性優先，可接受偶爾重複 | 建議工廠壓力/溫度告警數據採用此等級 |
| QoS 2 | 精確送達一次 | 要求最嚴謹但延遲較高 | 計費、安全相關的關鍵事件記錄 |
對於多數工廠的溫度壓力監控應用，我們建議採用QoS 1，在「不遺漏異常事件」與「系統效能」之間取得平衡。AWS IoT Core目前對QoS 2的支援視情境而異，實作前建議查閱AWS官方文件確認最新支援範圍。
四、用Python程式訂閱：讓資料自動流入你的應用程式
主控台驗證成功後，下一步是用程式「常駐訂閱」，讓資料可以自動導入你自己的資料庫、告警系統或儀表板，而不是每次都手動開主控台查看。以下範例使用 paho-mqtt 套件，這是Python中最常見的MQTT用戶端函式庫。
範例一：用 paho-mqtt 訂閱 AWS IoT Core 溫度主題
import json
import ssl
import paho.mqtt.client as mqtt
ENDPOINT = "your-endpoint.iot.ap-northeast-1.amazonaws.com"
TOPIC = "factory/taipei-plant1/line1/temperature/#"
def on_connect(client, userdata, flags, rc):
print(f"連線結果代碼：{rc}")
client.subscribe(TOPIC, qos=1)
print(f"已訂閱主題：{TOPIC}")
def on_message(client, userdata, msg):
payload = json.loads(msg.payload.decode())
print(f"[{msg.topic}] 裝置 {payload.get('device_id')}"
f" 溫度：{payload.get('temperature')}°C")
# 此處可接續寫入資料庫、觸發告警或轉發至其他系統
client = mqtt.Client(client_id="factory-subscriber-01")
client.tls_set(
ca_certs="root-CA.crt",
certfile="certificate.pem.crt",
keyfile="private.pem.key",
tls_version=ssl.PROTOCOL_TLSv1_2
)
client.on_connect = on_connect
client.on_message = on_message
client.connect(ENDPOINT, 8883, keepalive=60)
client.loop_forever()
這段程式會持續在背景執行，一旦有新的溫度數據發布到符合訂閱條件的主題，on_message 函式就會自動被觸發。這也是後續系列文章中「Lambda自動觸發運算」架構的本地端對照版本——先在自己的伺服器上用這套邏輯驗證資料處理流程，之後再決定是否遷移到Lambda無伺服器架構。
範例二：用 boto3 透過 IoT Data Plane 發布測試訊息（除錯用）
如果想在不接觸實體感測器的情況下，快速測試訂閱端程式是否正常運作，可以用 boto3 的 iot-data 客戶端手動發布一則測試訊息。
import boto3
import json
client = boto3.client("iot-data", region_name="ap-northeast-1")
test_payload = {
"device_id": "ATL-TEST-000",
"temperature": 25.0,
"unit": "C",
"timestamp": 1784812999
}
response = client.publish(
topic="factory/taipei-plant1/line1/temperature/ATL-TEST-000",
qos=1,
payload=json.dumps(test_payload)
)
print("測試訊息已發布，請確認訂閱端是否收到")
這個範例特別適合工廠IT在沒有實體感測器在旁邊的辦公室環境先行測試整條雲端邏輯，等程式驗證無誤後，再拿到產線現場接上真正的ATLANTIS溫度變送器。
五、ATLANTIS 支援數位輸出的溫度量測產品，如何對應MQTT架構
能夠穩定地被MQTT訂閱，前提是感測器本身的數位輸出要穩定、精度足夠。以下是幾款適合搭配本文架構、串接雲端監控的ATLANTIS溫度量測產品。
LTPT-410RS系列 溫度液位傳送器 —— 可同時測量溫度與液位，高可靠性、高穩定性設計，適合搭配RS-485集中監控後接續發布至AWS IoT Core
ATTX-200 防爆溫度傳送器 —— Pt100傳感器搭配補償電路，全焊接防爆外殼，適合危險環境的溫度雲端監控應用
DTT-P4 二線式大圓頭溫度傳送器 —— PT100Ω轉4-20mA標準輸出，適合搭配類比輸入模組轉換為數位訊號後接入MQTT發布架構
DTS-STS 數位溫度開關 —— 雙組開關輸出＋類比訊號輸出＋OLED顯示，適合同時需要本地告警與雲端監控的雙重需求場合
完整規格請參考 ATLANTIS 產品型錄、精密溫度感測器完整決策指南，以及工業4.0壓力感測器整合指南。
六、常見排錯清單：訂閱不到資料時，依序檢查這五項
| 檢查順序 | 可能原因 | 排除方式 |
|---|---|---|
| 1 | 訂閱與發布的主題名稱不一致（大小寫、路徑錯誤） | 複製貼上比對兩端主題字串，避免手動輸入誤差 |
| 2 | IoT Policy未授權該憑證訂閱/發布特定主題 | 檢查Policy中的iot:Subscribe與iot:Publish資源範圍是否涵蓋該主題 |
| 3 | 憑證未啟用或未附加到對應的Thing | 於主控台確認憑證狀態為Active並已附加Policy與Thing |
| 4 | 現場網路無法對外連線至8883埠 | 確認防火牆規則允許對AWS IoT端點的TLS連線 |
| 5 | 發布程式本身執行時發生例外但未捕捉 | 加上try/except並印出錯誤訊息，確認發布程式真的有執行到publish那一行 |
資深工程師分享：「工廠IT在第一次串接雲端服務時，最常見的錯誤不是程式寫錯，而是『以為連上了但其實沒有』。養成用MQTT測試客戶端先驗證的習慣，可以省下大半除錯時間——這跟儀錶校正的邏輯是一樣的：先確認量測基準沒問題，再往下談自動化。」
七、案例分享：某北部食品加工廠的溫度監控訂閱驗證流程
以下案例經匿名化處理，客戶為台灣北部一家食品加工廠，原先僅有本地端SCADA系統顯示溫度數據，導入AWS IoT Core的過程中，特別重視「資料送達驗證」這一步。
| 階段 | 驗證方式 | 發現的問題 | 解決方式 |
|---|---|---|---|
| PoC初期 | 主控台MQTT測試客戶端訂閱 | 訂閱不到任何訊息 | 發現IoT Policy誤將資源範圍設為特定裝置ID，未涵蓋新增測試裝置 |
| PoC中期 | Python paho-mqtt訂閱程式常駐運行 | 偶爾收到重複訊息 | 確認QoS 1本身允許重複送達，於應用層加上去重邏輯（依timestamp與device_id） |
| PoC後期 | boto3手動發布測試訊息驗證訂閱端穩定性 | 訂閱端程式長時間運行後偶爾斷線 | 加上自動重連機制與心跳（keepalive）參數調整 |
| 正式上線 | 持續監控訂閱端日誌與AWS CloudWatch指標 | — | 建立每日巡檢清單，確認訂閱端程式存活狀態 |
這個案例說明了一件事：「打通雲端」不是終點，而是「持續驗證」的開始。工廠IT技術人員在建立自動化監控系統時，也必須建立一套「監控監控系統本身」的機制，避免訂閱端程式默默斷線卻無人察覺。
資料來源與延伸閱讀
本文技術架構參考 AWS IoT Core 官方文件（docs.aws.amazon.com/iot）、MQTT.org 發布之 MQTT 5.0 規範，以及 Eclipse Paho 專案官方文件。QoS等級行為與AWS IoT Core支援範圍請以AWS官網最新公告為準。ATLANTIS產品技術規格引用自內部產品規格書與出廠檢驗報告。
八、內連延伸閱讀
九、20 大常見問題 FAQ（MQTT訂閱與AWS IoT Core）
1. MQTT的發布與訂閱一定要用同一個主題名稱嗎？
+單層、#多層）涵蓋發布端的主題路徑，否則訂閱端不會收到任何訊息。2. AWS IoT Core主控台的MQTT測試客戶端安全嗎？可以在正式環境使用嗎？
3. 訂閱主題時用萬用字元「+」和「#」有什麼差別？
+代表比對單一層級（例如factory/+/temperature可比對factory/line1/temperature），#代表比對該層級以下所有內容（必須放在主題結尾，例如factory/#可比對所有以factory開頭的主題）。4. QoS 1的「至少送達一次」會不會造成資料重複計算？
device_id與timestamp組合做去重判斷，尤其是涉及計費或觸發次數計算的場景。5. paho-mqtt和AWSIoTPythonSDK該用哪一個？
6. 訂閱端程式斷線後，錯過的訊息還找得回來嗎？
7. IoT Policy要怎麼寫，才能限制某個裝置只能訂閱特定主題？
iot:Subscribe與iot:Receive動作的Resource欄位，指定為該裝置專屬的主題路徑（例如factory/taipei-plant1/line1/temperature/ATL-STT-001），避免使用過於寬鬆的萬用字元授權，降低單一憑證外洩的影響範圍。8. 訂閱到的溫度數據要怎麼存進資料庫？
on_message回呼函式中，將解析後的資料寫入資料庫（如DynamoDB、RDS或InfluxDB）。若採用AWS原生架構，也可以透過IoT Core規則引擎直接將符合條件的訊息路由寫入DynamoDB，不需自行寫訂閱程式。9. 一個AWS帳號可以同時訂閱多少個主題？
10. 現場網路斷線時，發布端的資料會遺失嗎？
11. 訂閱端程式要部署在哪裡？工廠內部還是雲端？
12. Lambda可以直接當作MQTT訂閱端嗎？
13. 訂閱到的JSON格式如果錯誤，程式會怎樣？
json.loads()解析格式錯誤的資料，會拋出例外導致程式中斷。建議在on_message中加上try/except例外處理，記錄錯誤訊息並略過該筆異常資料，避免整個訂閱程式因單筆錯誤資料而終止。14. 如何確認訂閱端程式是否還「活著」？
15. 訂閱多個工廠據點的數據，主題該怎麼設計？
taipei-plant1），並在頂層管理端使用萬用字元（如factory/+/line1/temperature/#）跨廠區訂閱同類型數據，同時仍保留依廠區獨立查詢的彈性。16. 用MQTT訂閱和直接呼叫API拉取數據，哪個比較適合即時監控？
17. 訂閱端如果同時開很多個連線會不會被限流？
18. 訂閱到的溫度數據，時間戳記要用UTC還是本地時間？
19. 主控台的MQTT測試客戶端可以看到歷史訊息嗎？
20. 導入MQTT訂閱架構後，工廠IT還需要學什麼進階技能？
十、下一步：讓 ATLANTIS 協助你完成感測器選型與雲端串接規劃
31年工業儀錶製造經驗 × 完整數位輸出產品線
從變送器選型、RS-485/Modbus對照，到MQTT主題架構規劃，我們可以陪工廠IT團隊完成從硬體到雲端的完整驗證流程。
📞 02-2820-3405 免費選型諮詢 📧 線上快速詢價
業務一部 Ian：ian@atlantis.com.tw ｜ 業務二部 Nori：nori@atlantis.com.tw
文章更新時間：2026年7月｜作者：ATLANTIS 應用工程團隊｜本文為系列教學文章第二篇，接續第一篇RS-485接AWS IoT Core的基礎，下一篇將深入「Lambda入門：當溫度數據抵達時自動觸發運算」。