MQTT 是什麼？白話看懂 broker、QoS 與發布訂閱，工廠感測器資料怎麼送進系統

MQTT 是一種專門給物聯網設備用的輕量訊息協定。設備把資料「發布」到一台叫 broker 的中繼伺服器，需要資料的系統去「訂閱」自己關心的主題，雙方不用直接連線。感測器每幾秒報一次溫度、機台一停機就通知後台，這種又小又頻繁的資料，用 MQTT 送最省頻寬，網路斷斷續續也比較撐得住。

我們幫工廠把溫度感測器、ESP32 Wi-Fi 模組、掃碼槍、標籤機和 3D 列印機接進系統時，MQTT 幾乎都是那條「資料進門」的路。這篇用工廠現場聽得懂的話把它拆開：broker、topic、QoS 各是什麼，跟一般網頁用的 HTTP 差在哪，工廠實際拿它送哪些資料，從感測器到看板整條線怎麼搭。帳號、加密這些資安設定我們另外寫過 MQTT 三層防禦架構，這篇不重講。

它的來歷很務實。MQTT 在 1999 年由 IBM 的工程師為了監控輸油管線而設計，當時要透過又貴又慢的衛星線路回傳資料，所以每一個位元組都要省（HiveMQ 整理的 MQTT 發展史有完整經過）。後來它交給 OASIS 標準組織維護，2019 年推出 MQTT 5.0 規格，現在是物聯網最常見的通訊方式之一。

設備數量也一直在長。研究機構 IoT Analytics 的統計估計 2025 年底全球連網的物聯網設備約 211 億台，2030 年上看 390 億台。設備一多，「每台設備定時問一次伺服器」的做法就會越來越吃力，這正是 MQTT 擅長的場景。

MQTT 是什麼？先看一張白話對照表

先講結論：把 MQTT 想成工廠裡的收發室。每台設備把消息交給收發室（broker），收發室按照信封上的分類（topic）轉給有登記要收這類消息的人（訂閱者）。下面這張表把常聽到的名詞一次翻成白話，看完這張，後面的內容就讀得懂了。

看完還是不確定自己的設備該怎麼接進系統，可以直接 加 LINE 問我們，把設備型號和想看的資料丟過來，我們會告訴你大概要怎麼接。

發布／訂閱怎麼運作：設備只管發，系統各自訂

一句話：設備只負責把資料交給 broker，誰要用資料誰自己去訂，設備完全不用知道後面接了幾套系統。

這個設計最大的好處是「加東西不用動設備」。今天先接一個寫資料庫的程式，下個月想加一面現場看板，再過半年要接告警簡訊，都只是在 broker 後面多掛一個訂閱者。對工廠來說這很重要，因為設備端的程式一旦燒進去，要改就得跑現場一台一台更新。

topic 怎麼命名比較不會後悔

topic 是用斜線分層的字串，例如 「factory1/line2/oven03/temperature」。訂閱時可以用萬用字元：「+」 代表任一層，「#」 代表這層以下全部。所以 「factory1/+/+/temperature」 會收到一廠所有設備的溫度，「factory1/line2/#」 會收到二線的所有資料。

命名一開始就要想清楚，半年後設備變成幾十台，亂取的 topic 會讓所有人看不懂。我們接案時習慣照這個順序排：

• 由大到小：廠區 → 產線 → 設備 → 資料種類，查詢和授權都比較好切
• 只用英文小寫、數字和底線，不要放空白和中文，各家工具的支援不一定一樣
• 設備編號跟現場貼的標籤一致，維修人員看到 oven03 就知道是哪一台
• 狀態、量測、指令分開：「.../status」、「.../temperature」、「.../cmd」 不要混在同一個主題

QoS 0、1、2 怎麼選

QoS 決定這則消息要保證送到幾次。等級越高越可靠，但來回確認的封包越多，broker 要記的東西也越多。工廠裡大多數資料用 0 或 1 就夠了。

我們的做法是預設用 QoS 1，再在後端用每則訊息的流水號去重，比全面開 QoS 2 好維護。這套「設備只管發、系統各自訂」的架構，就是工廠管理系統的現場資料入口。像我們做的 生產力管理系統，重點就是生產可見性與異常管理，現場資料怎麼進門，直接決定看板準不準。

MQTT 跟 HTTP 差在哪？什麼時候不需要 MQTT

先講結論：設備要「一直報」就用 MQTT，系統之間「偶爾問」就用 HTTP。兩個都是好工具，差別在資料怎麼流。

HTTP 是一般網頁和 API 用的方式，一問一答：用戶端發請求，伺服器回答，答完就結束。要知道設備最新狀態，就得每隔幾秒問一次（輪詢）。算一下就知道：50 台機台每 5 秒問一次，一小時就是 36,000 次請求，而且大部分回答都是「沒變」。MQTT 讓設備維持一條長連線，狀態有變才推一則消息過來，網路和伺服器都輕鬆很多。

HiveMQ 的協定比較也提到同一件事：HTTP 每次請求都得重帶一次標頭，MQTT 連線建好之後，每則訊息只多一點點開銷。訊息越小、越頻繁，差距就越大。

但我們不認同「做物聯網就一定要上 MQTT」這種說法。如果工廠只有兩三台設備、每分鐘回報一次，設備直接打後端的 HTTP API 完全夠用，硬上 MQTT 反而多養一台 broker、多一個要監控的東西。我們的判斷門檻大概是：設備超過十幾台、需要秒級狀態，或同一份資料要給好幾套系統用，MQTT 才開始划算。

工廠裡 MQTT 拿來送什麼資料

簡單分三類：連續量測（溫度、濕度、電流）、狀態變化（運轉、停機、待料、異常）、人或設備產生的事件（報工、掃碼、列印完成）。三類的送法不太一樣，下表是我們規劃時的起手設定。

溫度監控：多數工廠的第一步

溫度是最常見的入門題，因為感測器便宜、規則好懂、出事代價又高：冷藏庫斷電、烤箱過熱，晚發現一小時就是一整批報廢。我們接溫度感測器時，告警通常不會一超標就叫，會設成「連續 3 筆超標才通知」，不然門一開就響，兩個禮拜後就沒人理告警了。

機台狀態：稼動率的原始資料

稼動率要算得準，靠的是每一次狀態切換都有時間戳。設備在「運轉→停機」那一刻送一則消息，後端把每段時間加總，就能算出今天停了多久、停在哪個原因。這也是 工廠管理系統 從 Excel 升級時最先想補上的資料，因為人工填的停機時間幾乎都是估的。

報工與掃碼：人產生的事件

現場人員用掃碼槍掃工單條碼、輸入完工數量，這筆事件透過平板或 ESP32 用 MQTT 送進系統。這類資料一定要用 QoS 1，而且要處理重複：同一筆報工如果因為網路重送收到兩次，產量就會多算。做法是每筆事件帶一個唯一編號，後端存之前先查有沒有存過。報工資料再往下串到批號與檢驗紀錄，就是 生產履歷系統 的基礎。

PLC 那一段誰負責

很多機台的資料在 PLC 裡，要用 Modbus 或 OPC UA 讀出來。這段我們老實說：通常由設備商或系統整合商處理，他們用閘道器把 PLC 的數值轉成 MQTT 送出來，我們負責 broker 之後的系統端，包括資料怎麼存、怎麼算、怎麼呈現。分工講清楚，報價和責任就不會打架。

從 ESP32 到看板：一條完整的 MQTT 資料路線

一條最常見的路線分五段：感測器接在 ESP32 上，ESP32 透過 Wi-Fi 連到 MQTT broker，後端程式訂閱資料寫進資料庫，最後由看板和告警把資料呈現出來。下圖是整條線的樣子。

ESP32 是一顆內建 Wi-Fi 的便宜晶片，接感測器、讀數值、送 MQTT 都做得到，是工廠做概念驗證最常用的板子。想先了解這顆晶片，可以看我們寫過的 ESP32-P4 入門指南，或是用同一類晶片做的 NFC 打卡系統。

設備送出來的內容，我們建議至少帶這四個欄位：

{
  "device_id": "oven-03",
  "ts": "2026-10-19T09:15:30+08:00",
  "temp_c": 182.4,
  "seq": 10233
}

「ts」 是設備量到的時間，不要用 broker 收到的時間，斷線補傳時才不會亂掉；「seq」 是流水號，後端靠它判斷有沒有重複或漏掉。這兩個欄位一開始沒放，之後要補就得全部設備重燒一次。

這條線再往上接，就是工單、報工、品質這些 MES 功能。想看整套製造執行系統怎麼規劃，可以讀我們的 客製化 MES 開發完整指南；MES、ERP、QMS 三套系統怎麼分工，則在 ERP、MES、QMS 差在哪 有一張分工表。

選 MQTT broker 要看哪幾件事

先決定要自己架還是用雲端託管，再看預計幾台設備、斷線時訊息要不要留著、需不需要多台備援。下表是常見的四種選項。

綁平台這件事要特別小心。Google 在 2023 年 8 月停掉了 Cloud IoT Core，當時用它的公司都得在期限內把所有設備搬家。所以我們的原則是：設備端只講標準 MQTT，不用任何平台專屬的 SDK，哪天要換 broker，只要改連線位址和帳號就好。

規劃 broker 時可以照這張清單問一輪：

• 設備數和訊息量：幾台設備、每台多久送一次，算出每秒大概幾則
• 斷線要不要補：設備或後端斷線期間的訊息要不要留著，影響持久連線狀態的設定
• MQTT 5 支援：訊息有效期限、遺囑延遲這些 5.0 才有的功能，對工廠很實用
• 監控：連線數、訊息量、broker 本身有沒有活著，要有人收得到通知
• 備援：broker 掛了產線資料會斷，可以接受斷多久
• 帳號權限：哪台設備能發哪些 topic，細節見 MQTT 三層防禦

MQTT 常見踩坑：斷線、重複、舊指令

大部分 MQTT 的問題，都出在「以為送到了」。協定本身很穩，出事的通常是設定和資料設計。下面是我們最常看到的幾種：

• 斷線期間的訊息全不見：用戶端用 clean session（乾淨連線）登入，broker 就不會幫它保留斷線期間的訊息。後端訂閱服務要改用持久連線，並搭配 QoS 1
• 報工數量多算：QoS 1 保證送到但可能重複，後端沒有用流水號去重，就會一筆報工算兩次
• 設備執行一週前的舊指令：指令主題設成 retained，設備重開機一連上就收到上次留下的指令又執行一次。指令不要用 retained，或用 MQTT 5 的訊息有效期限讓它過期
• 網路一抖就狂報離線：Wi-Fi 不穩時設備頻繁上下線，Last Will 一直觸發。MQTT 5 可以設遺囑延遲，短暫斷線不發離線通知
• 時間軸錯亂：用 broker 收到的時間當資料時間，斷線補傳的資料全擠在同一秒。設備端要校時並自帶時間戳
• topic 越長越亂：沒有命名規則，半年後沒人知道 test/abc/temp2 是哪台

這幾個坑都不難修，難的是上線前沒人想到。系統導入失敗常常死在這些小地方，MES 導入失敗原因 那篇整理過更多類似的例子。

MQTT 資安先顧三件事

最低限度要做到三件事：每台設備有自己的帳號或憑證、連線走 TLS 加密（常用 8883 埠，未加密是 1883 埠）、用存取控制限制每台設備只能發布或訂閱自己的 topic。還有一條最基本的：1883 埠不要直接開在網際網路上。

這三層要怎麼設、Mosquitto 的設定檔長什麼樣子，我們在 MQTT 帳密認證夠安全嗎？三層防禦架構 寫得很完整，照著做就可以。工廠設備一旦被接管，影響的是產線，資安不要留到最後才補。

MQTT 專案自己接還是找人做？分工與預算怎麼抓

先講結論：兩三台設備做概念驗證，有工程背景的同事可以自己來；要進正式生產、接進 MES 或 ERP、讓很多人看同一面看板，就值得找人把系統端做好。

預算最容易漏估的是佈線和現場安裝。我們估價時會把軟體、硬體、佈線三塊拆開，佈線以市場行情來說每點大約 1,000 到 2,500 元，現場環境越複雜越高。完整的拆法可以看 MES 系統價格怎麼算，要比較套裝、系統整合商、客製開發三種廠商，則看 MES 廠商怎麼選。

如果你的工廠現在是這樣：溫度靠人每兩小時抄一次、停機時間月底才憑印象補、想看產線狀況得走到現場問，這三件事中了兩件，就很值得先把一條產線的資料接進系統試試看。整體轉型的順序怎麼排，台灣製造業智慧製造導入指南 和 製造業內部系統開發指南 都有整理。

想聊聊你的設備適不適合用 MQTT 接進系統，我們很樂意 聽你說說現場的情況，或直接 加 LINE 把設備清單丟過來。這個階段我們陪你一起看哪一段最值得先做，真的要動手再談範圍跟費用。