我想写一篇有关该主题的详细文章，但是很显然，我的手没有伸手。 因此，一条短消息。 我以几种语言开发和实现了MQTT协议版本的原型代码，其工作名称为MQTT / UDP。 对于不耐烦的人和已经了解一切的人，显然，
Github上的代码
为何我居住在几乎完全由自己的智能家居系统完全控制的公寓中。 照明，气候控制，传感器，简单的自动化就这样。
在这段时间里，我发现（是的，我已经了解了）UD系统的主要特性是可靠性。
根据定义，所有带有中央节点的系统都不可靠。 因此，人们希望在不使用任何中央集线器的情况下获得系统组件的互连（并且在真正的智能家居中有很多组件）。
同时，我们从以下事实出发，总的来说，UD系统的流量很小-传感器很少需要每分钟更新一次以上，而其余数据是基于事件的（亮起），并且流量是完全微不足道的。 即使每秒更新系统中的所有数据，不仅是灾难，而且是一个重大问题。
合理的结论是UDP广播是理想的工具。
（是的，我假设公寓的内部网络已被防火墙关闭。）
优点：难以置信的简单实现。 内存很少的最小微控制器可以发送UDP数据包。 对于传感器，甚至不需要UDP接收。
极低的延迟。 中央集线器中没有转发，UDP数据包的传送时间实际上是现代系统中的最小时隙。
集线器/代理中没有故障的中心点。 考虑一个简单的方案：两个温度传感器，一个加热地板控制器，一个加热电池控制器。 使用MQTT / UDP时，此类系统任何部分的故障都不会导致整个系统的故障。
网络流量低。 无处不在。 TCP和确认只会增加流量，而不会增加可靠性。 发生故障的传感器无法在收到TCP ACK时工作。 而且我们通过缺少更新来识别失败。
UDP协议本身的可靠性是微不足道的-传感器仍会定期更新数据，并且计数的消失是完全不可见的，并且例如目标系统的故障从视觉上确认了来自开关的命令的消失。 一个人做什么？ 再次点击。 但是，这是该协议适用性的主要限制。 定期民意测验的理想选择。
无需系统配置。 无需注册经纪人，中心等的地址。 但是，仍然需要传感器配置-您需要注册传感器ID。 但是，当将系统的其他部分传输到其他服务器时，不需要重新配置响应组件。
有趣的是，这种数据交换模型非常适合自然广播的媒体，例如无线电频道或RS / 485。 我尚未对此进行试验，因此需要控制此类环境中的协议。 顺便说一句，从modbus应用CRC16是合乎逻辑的。
缺点也很明显：传送的可靠性仅取决于网络上的硬件和流量，如果敌人进入网络，则该协议会立即被击败。 诚然，坦率地说，入侵其他典型的智能家居协议仅需几秒钟，因此这是MQTT / UDP的有争议的缺点。 另一个明显的减号是每个IP地址最多一个接收器。
已完成的工作并位于源代码存储库中：- 多种语言的客户端/服务器实现。 有C，Python和Java。 我没有精通Lua（无法将您需要的一切都放进去，您如何生活在其中？）和Codesys（无法编译该包，谁发明了这种语言？）。
- 用Python最小化传统MQTT的门
- 用于在网络上显示MQTT / UDP流量的原始工具
如果我有更多时间该怎么办：- 我会为openHUB编写一个模块。
- 将在另一个端口上的JSON上使协议变型，并转换为主要格式和端口。 或双向闸门。
- 我会将主要平台的实现空白。 对于Arduino，我提出了一种权重方法，并确实测试了代码，但并未正确设计所有内容。 对于Raspberry，Python中的测试用例是合适的。
- 是否可以进行数字签名和加密，但具体方式尚不清楚。
- 多播。
谢谢你，
欢迎来到仓库PS：本文介绍了
一种类似的方法，但具有多播。