4

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

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

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

  2. thingname = <gatewayId>_<displayId>

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

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

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

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

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

如何处理断开连接的网关，然后重新联机？

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

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

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

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

4

1 回答 1

4

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

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

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

  3. 处理断开连接的网关：是的，订阅不是持久的，但是如果您将网关视为things每个显示的属性thing，则每当它重新联机时，它都可以向GET主题发布消息（例如$aws/things/<gateway_id>/shadow/get），检查thing当前状态在ACCEPTED GET主题 ( $aws/things/<gateway_id>/shadow/get/accepted) 上，然后继续下载新的位图以防出现新版本。

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

需要考虑的一些事项：

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

  2. AWS IoT 仍是一项测试服务，因此许多实施细节可能会发生变化。

于 2015-11-13T13:29:42.100 回答