我正在开发一种可测量温度,湿度和质量的设备。当前,它使用HTTPS将数据上传到远程服务器。现在我知道有一个称为MQTT的协议,它被称为“物联网协议”。 br />

评论

我们应该结束这个基于观点的老问题。已添加足够的意见。可以在谷歌上找到许多可能的答案。

我同意。最初,这个版本幸免于难,因为它是在私人Beta版中被询问的。

#1 楼

MQTT是设备之间的“信使”:


您的设备在时间T测量X度的温度
它(通过自身或通过zwave集线器)连接到MQTT代理。
创建一条主题为/domotics/myplace/mydevice/temperature的消息

在消息中,它仅将X(作为“有效载荷”)放入

房子的其他地方: >

您的Raspberry Pi已连接到MQTT代理(可以是MQTT实例本身)
它订阅了主题/domotics/+/+/temperature,以从使用该主题的所有设备接收所有温度信息格式。请参阅MQTT规范以获取有关MQTT主题通配符(+#)的更多信息。
它将收到一条带有有效负载X的消息,并执行所需的任何操作! br />

您的计算机已连接到MQTT代理,并订阅了主题/domotics/myplace/mydevice/#,可从设备中获取所有信息并进行记录
,它将收到一条带有有效负载X的消息,并且做任何想做的事情!

MQTT对于避免将Web服务和套接字放在服务器周围非常有用。 Node-RED使用MQTT,可以配置Domoticz来获取in并设置out信号。

我个人在家中使用MQTT关闭计算机:/house/computers/mycomputer负载:0

评论


很好的一点是,我不必麻烦套接字和其他Web服务。

– Bence Kaulics
16 Dec 6'在18:54

您能在安全方面发表评论吗?交通是明文吗?

–莫格说要恢复莫妮卡
16 Dec 7'在11:34

另一个答案是MQTT支持TLS; iot.stackexchange.com/a/69/39

–古法利特
16 Dec 7'在12:06

#2 楼

称为MQTT的MQ遥测传输协议是为低功耗和低带宽运行的设备设计的。它是一种轻量级的发布/订阅消息传递协议,这意味着任何其他设备都可以订阅特定主题。

HTTP / HTTPS被设计为用于客户端-服务器计算的请求-响应协议,它永远不会影响功能使用率高且有大量数据开销。

如果满足以下条件,则使用MQTT:每x天(MQTT已针对电池使用进行了优化,而HTTP / S并非如此)
需要更快的响应
需要具有发布/订阅机制(如果您希望将消息推送到许多客户端)
需要以不同级别的QoS可靠地发送数据吗?MQTT提供的安全性是否与HTTPS一样高?



MQTT依赖于TCP传输协议,这意味着默认情况下该连接不使用加密的通信。为了加密整个MQTT通信,大多数MQTT代理(例如HiveMQ)都允许使用TLS而不是纯TCP。

参考:HiveMQ

评论


MQTT是否提供与HTTPS一样高的安全性?

– Bence Kaulics
16 Dec 6'在18:55

它可以使用SSL / TLS,因此应与HTTPS一样安全。

–加纳马
16 Dec 6'在18:59

就像@Ghanima所说的那样,我用参考文章更新了答案,以检查有关保护MQTT的内容。

–bravokeyl
16年6月6日19:00



#3 楼

MQTT(消息队列遥测传输)似乎非常适合所建议的应用程序。

它在带宽(最小的数据包大小,只有2个字节的标头)和客户端代码占用空间(两者都轻巧)方面是轻量级的使其能够在ESP8266等瘦客户端(典型的IoT客户端)上运行。减少的传输数据有利于延长电池离网供电客户端(如传感器)的电池寿命。

MQTT还提供了非常适合IoT任务的简单方法(动词),例如持久订阅,可在客户端意外断开连接后恢复连接。与HTTP / HTTPS相比,从包中提取数据也更加简单(无需解析器)。

#4 楼

在这里,我写了一篇文章,展示了我们项目中通信系统的发展。它涉及微服务,但您可以将任何传感器视为微服务,因为它的工作是收集和发布任何种类的遥测数据。

因此,最重要的结论是使用MQTT更好当您只需要将事件发送到某个地方而对接收者一无所知时。当您对接收者有所了解并需要一些响应时,最好使用HTTP(通常是REST)-例如在使用任何命令的情况下。

从流量,CPU,内存和能耗的角度来看,MQTT和HTTP基本上是相同的。

#5 楼

关于您的报价MQTT是“物联网协议”:

是的,有很多开发人员正在使用此协议(请参阅IoT Developer Survey 2018),但CoAP(针对IoT调整了HTTP (基于UDP),如果您想在应用程序中使用轻量级的请求/响应功能,则可以提供HTTP的替代方法。另一方面,MQTT提供了内置的发布/订阅逻辑,使其非常适合扩展(您可以将更多网关用于更多设备)。还有一个称为MQTT-SN(用于传感器网络的MQTT)的UDP替代方案(如HTTP的CoAP)。与CoAP相比,这提供了甚至更小的开销,但没有使用R / R。

#6 楼

为什么和何时使用MQTT:

(如果有)能够运行MQTT Broker /服务器的服务器(显然)。您可以在raspberry pi上安装或在具有ARM linux的任何其他SBC上编译Erlang MQTT代理。
当您要使用主题wildchars时。在Goufalite答案中进行了解释。
当您要使用持久性功能时。例如,在第1天在/device/board_1/should_be_active上进行持久性发布,而对该主题没有任何发布。当新设备在第2天或任何其他日期订阅该主题时,他将收到在第1天发布的数据。即使代理重新启动,该主题的永久数据也不会丢失,并且会再次通知订阅者。

当您不想使用MQTT时


您并不需要这些功能


您不需要加密。例如,在汽车中,并非所有数据都是经过加密的,尤其是它们的数据是通过CAN发送的。如果您只能使用微控制器,那为什么呢?
您可以使用其他服务器,如CoAP(Pepe Bellin解释)。
NodeMCU固件支持CoAP服务器,这意味着您不需要昂贵的
linux电源服务器。
您可以使用原始套接字UDP或TCP-IP并自己加密数据。这样,您无需使用HTTPS。



几年前,在设备之间进行通信时,我总是使用MQTT。但是如今,为了更有效地利用资源,即使在与Android设备通信时,我也总是喜欢原始套接字。

评论


我倾向于同意最后的评论。使用UDP比MQTT或MQTT-SN更简单。

– Marc Compere
20-10-20在3:24