将 AWS IOT 用于间接连接的设备

Question

我正在考虑将 AWS IoT 用于一个应用程序，其中在（可能数百个）分布式网关（PC 或 Raspberry Pi）后面有数千个小型位图显示器（通过专有无线协议连接）。

到目前为止，我提出了以下概念：

1. 网关 PC 终止 MQTT 会话。它没有自己的设备表。

2. thingname = <gatewayId>_<displayId>

3. 显示位图存储在 S3 上（文件名 = 事物名）

4. 更新显示只是替换 S3 文件，然后更新设备阴影所需状态的位图版本（例如 SHA）。

5. 网关必须订阅更新，例如/update/<gatewayId>/#

6. 会有一条规则从/update/<gatewayId>_<displayId>重新发布到/update/<gatewayId>/<displayId>（因为东西名不能包含斜杠，MQTT中的通配符必须是完整的路径组件）

7. 对于每条收到的消息，网关都会从 S3 下载位图，将其发送到显示器，然后将报告的状态更新到新版本。

如何处理断开连接但又重新联机的网关？

订阅不是持久的，所以我需要找到所有东西（从那个网关），其中期望的状态！=报告状态并再次更新它们。

可以有一个规则来做到这一点吗？这个想法是让网关在它重新联机时发布重新连接消息（如/reconnect/<gatewayId>）。该规则必须找到该网关的所有设备影子，其中期望状态！= 报告状态并发布它们。

注意：我知道我可以在没有设备影子的情况下使用自己的数据库对机制进行编程。但这个想法是为此使用物联网机制。

另一个问题： 创建位图非常快（可能是每秒 1000 个），发送到显示器可能非常慢（尤其是发送一堆的第一个位图可能需要一分钟）。因此，在确认第一条消息之前，可能会创建数千个位图（用于一个网关）。这是个问题吗？

Answer 1

如果我正确理解您的用例，我认为您的概念可能需要进行一些更改以使其更好地工作。我将尝试将您的问题分解成更小的部分来回答。

1. 状态同步： 由于您的显示器与 AWS IoT 没有直接通信，如果您将网关视为 things 并将每个显示器视为一个属性（例如 @987654325 @) 的相应网关thing。这样，每当必须将新图像上传到显示器时，您只需将 nested attribute 的 desired state 更新为相应的显示属性（例如，<bitmap_version> 嵌套到 <display_id>）。您可以使用thing shadow UPDATE 主题（例如$aws/things/<gateway_id>/shadow/update）来做到这一点。您可以使用 Lambda 向 UPDATE 主题触发消息，以检测新版本的显示位图何时已上传到 S3。

2. 图像下载： 每当新版本的位图上传到 S3 时，网关都会通过 @987654335 接收显示属性的特定位图版本的新 desired state @ 的ACCEPTED UPDATE 主题（例如$aws/things/<gateway_id>/shadow/update/accepted），下载新位图，通过您的专有无线协议更新显示并更新thing shadow UPDATE 主题上属性的reported state。

3. 处理断开连接的网关：是的，订阅不是持久的，但是如果您将网关视为things 并且每次显示都作为该thing 的一个属性，只要它回来在线它可以向GET主题（例如$aws/things/<gateway_id>/shadow/get）发布消息，在ACCEPTED GET主题（$aws/things/<gateway_id>/shadow/get/accepted）上检查thing的当前状态，然后继续下载新的位图以防万一新版本。

4. 处理大数据量：如果您需要每秒更新多个位图的网关的每个显示，考虑到每个网关有数千个显示，我认为您可能遇到的问题遇到带宽瓶颈并将所有这些 MQTT 消息与您的 thing shadow 主题同步。如果您只需要偶尔更新每个显示，我认为您的概念可以很好地工作。

需要考虑的一些事项：

1. AWS IoT MQTT 实施无法保证order in which messages are received。如果您需要按特定顺序接收消息，则必须在您的应用程序中实现。

2. AWS IoT 仍然是 beta service，因此许多实施细节可能会发生变化。