設備遙測用 MQTT 還是 HTTP
設備遙測要先寫明誰發布讀數、誰訂閱、斷線時誰接手，再決定用 MQTT 還是 HTTP。MQTT 是客戶端與伺服器之間的發布與訂閱；HTTP 是無狀態的請求與回應。讀數最後仍要寫進同一筆設備紀錄。
先寫讀數要到哪裡
每一類讀數先寫四項：哪一件設備、哪一個欄位、誰會收到、斷線或請求失敗時交給誰。四項缺任何一項，協定還沒有可選的對象。
讀數要接到貴司已經在用的維修或租賃，見 方案評估、原型及整合。租賃紀錄的五段見 設備租賃管理系統怎麼選。維修工單見 設備預測性維護怎麼做。設備識別碼見 設備追蹤用條碼還是 RFID。
MQTT 5.0 在標準裡是什麼
MQTT Version 5.0 是 OASIS 標準，日期為 2019 年 3 月 7 日。它取代 2014 年 10 月 29 日的 MQTT 3.1.1。摘要把 MQTT 寫成客戶端與伺服器的發布／訂閱傳輸，輕量、開放，並寫明適合機器對機器與物聯網這類程式體積要小、或頻寬寶貴的環境。協定跑在 TCP/IP 上，或跑在其他能提供有序、不丟資料、雙向連線的網路上。
同一份標準寫明三種交付品質。「最多一次」依運作環境盡力交付，訊息可以遺失，標準舉的例子是環境感測：單筆遺失無妨，因為下一筆很快會再發布。「至少一次」保證抵達，但可以重複。「恰好一次」保證恰好抵達一次，標準舉的例子是計費，遺失或重複會造成錯誤收費。標準並寫明，承載內容與協定無關，以及異常斷線時通知有關的一方。本文不把計費例子寫成貴司的收費規則，也不補上標準沒有寫的距離或電量。
HTTP 在 RFC 9110 裡是什麼
RFC 9110 是 HTTP Semantics，標準號 STD 97。摘要把 HTTP 寫成無狀態的應用層協定，用於分散、協作的超文字資訊系統。同一節把 HTTP 寫成一組無狀態的請求／回應協定：一次請求可以單獨看待，伺服器不必把它綁成預定的一連串步驟。
同一文件把配套的 HTTP/1.1（RFC 9112）、HTTP/2（RFC 9113）與 HTTP/3（RFC 9114）都標為 2022 年 6 月。擷取到的頁首沒有另印 RFC 9110 自身的出版行，本文以上述配套文件的日期為這一批說明的日期，並只引用 9110 對請求與回應的定義。本文不補上該頁沒有寫的延遲或吞吐。
依讀數怎麼交出來選
同一筆讀數要交給一個以上的訂閱者，而且單筆環境讀數遺失可以等下一筆：這一小步對上 MQTT 的發布／訂閱，以及標準自己舉的「最多一次」。主題、代理伺服器，以及異常斷線時誰會收到通知，都要寫在旁邊。承載內容由標準留白，設備識別碼與讀數單位要由你放進承載，並與軟體裡的同一筆紀錄相同。
由人或其他系統來要一筆紀錄，回應只對這一次請求負責，例如查詢某件設備此刻能否出租：這一小步對上 HTTP 的請求與回應。網址、方法、成功時寫回哪個欄位、失敗時誰重試，都要寫明。兩種可以同時存在：週期讀數走 MQTT，單筆查詢走 HTTP。本文不把同時存在寫成必須。
重複與斷線要有人接
選了「至少一次」，標準寫明訊息可以重複。軟體要把同一筆讀數認成一次寫入，依據是設備識別碼加上讀數時間，或其他你已經寫明的鍵。沒有這條規則，儀表板會把同一筆顯示兩次。
選了 MQTT，異常斷線的通知要落到有負責人的清單。只停在代理伺服器日誌裡的通知，還沒有人接手。選了 HTTP，請求失敗同樣要落到這份清單。沒有人按固定週期看這份清單時，兩種協定都先不要上線。
什麼時候先不要用 MQTT
沒有人營運代理伺服器、主題還沒命名、或唯一的消費者只是偶爾來要一筆紀錄時，先不要為了這一個查詢架設 MQTT。用一次 HTTP 請求把該筆紀錄要回來，並寫明失敗時誰重試。
「恰好一次」只在遺失或重複會造成你已經寫明的錯誤時才考慮，標準舉的是計費。環境讀數沒有這條後果時，用「最多一次」或「至少一次」，並把重複怎麼合併寫進軟體。本文不給出省下的頻寬或電量。
什麼時候先不要用 HTTP
設備必須維持連線，斷線要主動通知，而你目前只能寫出「由伺服器輪流向每一件詢問」時，先讀 MQTT 標準裡的異常斷線通知，再決定是否改為發布／訂閱。輪詢的網址、間隔與失敗負責人若寫得出來，HTTP 仍可以留在短名單。間隔要來自貴司自己的維修規則並註明日期，本文不代填秒數。
識別碼還沒定、讀數沒有單位、也沒有人把失敗交給維修工單時，兩種都先不要接上設備。先補這三項。沒有試傳紀錄之前，用「每一筆是否帶識別碼、斷線或失敗是否有人接手、重複讀數是否併成一筆」來檢查遙測有沒有在按流程走。