设备遥测用 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 仍可以留在短名单。间隔要来自贵司自己的维修规则并注明日期，本文不代填秒数。
识别码还没定、读数没有单位、也没有人把失败交给维修工单时，两种都先不要接上设备。先补这三项。没有试传记录之前，用「每一笔是否带识别码、断线或失败是否有人接手、重复读数是否并成一笔」来检查遥测有没有在按流程走。