我想知道MQTT是否被认为是用于传输其读数（短而频繁的突发消息）的合适协议。
许多博客/文档都认为MQTT适用于“ IoT应用程序”，因为它是与HTTP相比，重量更轻，并且省电。但是，据我所知，它要求保持开放连接，而BLE或其他适用于IoT的通信协议则不是这样。 BLE不会长时间保持连接打开以保留能量。显然，当使用MAC层协议（例如WiFi）时，MQTT是合适的。首先，这几乎打破了使用MQTT的基本原理（即，如果设备可计算地处理诸如WiFi之类的协议，则它可能不需要诸如MQTT之类的协议）。您是否看到这种逻辑上的缺陷？
是否为此目的有其他可选的应用程序层协议？当它们与网关通信以及直接与服务器通信时，这类消息（例如原始二进制数据，JSON，XML）中最常见的结构是什么？
#1 楼
MQTT必须在TCP / IP上运行（我不记得它是否确实在规范中，或者是否做出了足够的假设），但它的姊妹协议MQTT-SN可以在几乎任何可以传递数据的协议上运行，我已经看到了UDP和串行方式的实现。我已经说过，我不确定通过BLE来运行会带来什么好处，BLE的内置Feature提供了很多相同的好处（如果仅在
我想记住的重要一件事是物联网中“ I”的含义，这意味着在某个时候访问互联网（甚至是（如果是网关设备或电话）。到那时，MQTT可能非常有用，但是并不一定意味着一直到（出血）边缘。
评论
首先，感谢您让我知道MQTT-SN的存在。绝大多数文献都具有误导性，因为它暗示MQTT主要是由于其节能特性而使边缘设备具有功能。在那种情况下，降低功耗并不是真正的理由，因为在具有该配置文件的设备中，根本就没有关系。这些设备应实现完整的IP堆栈，并且由于MQTT保持开放连接，因此节能MAC层协议不是一种选择。
–dr.doom
17年7月19日在18:52
与HTTP之类的东西相比，MQTT确实节省了功率，因为一旦您已经运行了TCP堆栈，打开的TCP连接实际上并不会消耗那么多的能量来保持打开状态，并且保持活动的数据包很小。此外，协议开销比HTTP低得多，因为HTTP头与MQTT数据包头相比非常庞大。许多计算文献都基于蜂窝设备，例如蜂窝电话。电话
– hardillb
17年7月19日在19:15
边缘也发生了变化，它曾经是TCP / IP停止的地方，诸如ble和ZigBee（尤其是lpwan）之类的东西，甚至更低功耗的处理器也已经转移到了更薄的设备上
– hardillb
17年7月19日在19:22
显然，它不仅仅是TCP / IP；唯一的要求是协议必须提供“有序，无损，双向连接”。就像文档摘要的第二段一样。存在SN是因为该要求对小型系统（尤其是基于无线电的系统）的要求很高。也许这就是“做出足够的假设才能做到”的意思，但这绝对不依赖于TCP / IP。
–戴夫·牛顿
18年7月24日在15:37
#2 楼
可以说，最好将数据从BLE范例简单映射到MQTT，而不是尝试通过BLE从字面上发送MQTT。BLE通常以特征形式交换数据。它们具有各种BLE独特的机制，可发现您可能会发现有用的价值变化。但是它们的最大数据长度为20个字节。
可以通过BLE流式传输串行数据，一次移动20个字节。有时是通过实现虚拟串行端口来完成的，您可以通过它来建立完整的MQTT。
但是使用BLE特征集合来承载不同主题的数据可能会更好。 BLE具有将特征标识映射到MQTT主题，并将值映射到MQTT有效负载的桥梁。可能您应该弄清楚BLE的哪种用法最适合您的应用程序，然后将其映射到MQTT维护连接的意义上。 -> MQTT和MQTT-> BLE
评论
如果您想使用MQTT 2 BLE桥接器，请查看我的github.com/hardillb/mqtt2ble
– hardillb
17年7月19日在16:14
感谢您的链接，我现在正在研究它。
–dr.doom
17年7月19日在18:55
评论
本地BLE机制是否由于任何特定原因而不合适？肖恩（Sean）的问题最好分为两部分-A）本地BLE协议机制是否可用于设备的直接链接，以及B）数据最终需要存放在哪里？如果B部分的答案超出了BLE的范围，则需要一座桥梁（至少在无线电格式之间，但也可能在协议之间）。
网关使用原始读数还是直接读取原始读数？在这种情况下，有意义的是端对端地隧道传输MQTT，而不是在网关处桥接MQTT本身的BLE？