MQTT-SN 仍然是“新的”还是已经过时？

物联网 MQTT 紫蜂 蚊子 emq
2021-06-27 09:09:10

我有一个基于 MQTT 的现有物联网项目，并且正在考虑扩展应用程序以包括使用 Zigbee 网格的电池供电的终端节点。出于以下原因，逻辑上似乎最合适的方法是通过 Zigbee 使用 MQTT-SN：

  • 我已经有一个 MQTT 基础设施
  • MQTT-SN 支持电池供电的节点，这些节点可以进入休眠状态以节省电量
  • 它旨在在基于非 TCP 的通信平台上运行
  • 它最大限度地减少了需要发送的数据量

然而，在研究了如何实施 MQTT-SN 之后，在过去几年中似乎没有太多的开发活动。

那么 MQTT-SN 仍然是一种可行的技术，还是已经被其他技术取代了？我还没有发现任何具有类似功能集的东西可以完成我需要它做的事情。我可以只为 MQTT-SN 规范开发新代码，但如果它已经是一种死技术，我不想花很多精力让它工作。

编辑- 希望澄清一下，我假设以下一项或多项是正确的：
1. MQTT-SN 仍然足够新，可以成为最前沿的，只是还没有被广泛采用。（太好了，我会继续推进它）
2.有更简单、更实用的定制方法来完成 MQTT-SN 提供的更少的开销。（好吧，我不会担心使用标准）
3.还有另一种技术平台取代了 MQTT-SN。（它是什么？）
4.大多数 IoT 通信现在通过 WiFi 或蜂窝而不是 BLE 或 Zigbee，因此 MQTT-SN 不是必需的。（我需要重新考虑我的项目扩展）

3个回答

首先，好问题（并以 favo(u)rite +1 为主角）。

然而，在研究了如何实施 MQTT-SN 之后，在过去几年中似乎没有太多的开发活动

这可能发生在技术成熟时。

我还没有发现任何具有类似功能集的东西可以完成我需要它做的事情

那么为什么不坚持你所知道的呢？我仍在编写 AngularJS v1.x，因为我懒得学习 Angular（非 JS）的 TypeScript，它现在是 v 8 并且还在计数。

到目前为止，您必须拥有大量可用于未来 MQTT 项目的通用代码，就像我为 AngaulrtJs 所做的那样。

对于放弃一个成熟的产品，我能看到的唯一理由是，你已经通过了学习曲线，现在变得富有成效且知识渊博，那就是宣布不会有未来的安全补丁，而我还没有听说过 MQTT。

tl; dr - 如果它没有坏掉，草可能不会更绿

我只能推测问题的一方面：

  1. 大多数物联网通信现在通过 WiFi 或蜂窝而不是 BLE 或 Zigbee 进行，因此不需要 MQTT-SN。（我需要重新考虑我的项目扩展）

这似乎不太可能。许多设备都有电池供电（或能量收集）的要求。尽管 WiFi 和蜂窝可以在超低占空比下实现，但它们从来都不是为低带宽/高效率应用而设计的。

在我使用的设备中，我的一些照明和加热系统都是 Zigbee - 我希望它们都在“实时”路线图中。

是的，未来几年协议栈可能会有一些精简，但看起来 Zigbee 还没有被取代。

MQTT-SN 在寻找产品与市场的契合点时可能会有些困难。

以下是反对它的力量：

  • RAM 和带宽一天比一天便宜。

  • 它仍然需要一个经纪人。

  • 我还没有看到“块传输模式”（如 CoAP 的 RFC7959）。

  • CoAP 一直适用于受限设备，并且已经发展出块传输、观察模式并且不需要代理。

  • CoAP 库已经成熟，CoAP 拥有庞大的社区。

这是它的力量：

  • 一些开发人员熟悉 MQTT 范式。

因此，MQTT-SN 适用于使用 MQTT 并且现在想要使用小型设备并希望在那里传输这些知识和/或想要范式的 UDP 方面并且不想做一次性的普通 UDP 的开发人员或使用其他基于 UDP 的协议，例如可用于流媒体的协议。使它成为一小群人，并且有其他选择。

其它你可能感兴趣的问题
上一篇从 IFTTT 获取触发器 - 使用 ESP8266 下一篇有人可以解释为什么不能使用 Olimex ESP32-EVB 上的某些引脚吗？