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>from toを再発行するルールがあります/update/<gatewayId>/<displayId>(モノの名前にスラッシュを含めることはできず、MQTT のワイルドカードは完全なパス コンポーネントでなければならないため)。

  7. 受信したメッセージごとに、ゲートウェイは S3 からビットマップをダウンロードしてディスプレイに送信し、報告された状態を新しいバージョンに更新します。

オンラインに戻った切断されたゲートウェイをどのように処理しますか?

サブスクリプションは永続的ではないため、(そのゲートウェイから) 目的の状態 != 報告された状態のすべてのものを何らかの方法で見つけて、それらを再度更新する必要があります。

それを行うためのルールはありますか？アイデアは、ゲートウェイが/reconnect/<gatewayId>オンラインに戻ったときに再接続メッセージ ( など) を発行することです。ルールは、望ましい状態 != 報告された状態である、そのゲートウェイのすべてのデバイス シャドウを見つけて公開する必要があります。

注:デバイス シャドウを使用せずに、独自のデータベースを使用してメカニズムをプログラムできることはわかっています。しかし、アイデアはそのために IoT メカニズムを使用することでした。

別の質問: ビットマップの作成は非常に高速です (1 秒あたり 1000 の可能性があります) が、ディスプレイへの送信は非常に遅くなる可能性があります (特に、最初のビットマップの送信には 1 分かかる場合があります)。したがって、最初のメッセージが確認される前に、(1 つのゲートウェイに対して) 数千のビットマップが作成される可能性があります。これは問題ですか？

4

1 に答える 1

4

ユースケースを正しく理解していれば、コンセプトを改善するためにいくつかの変更が必要になる可能性があると思います。私はあなたの質問にそれらをより小さな部分に分解して答えようとします.

  1. 状態の同期:ディスプレイは AWS IoT と直接通信しないため、ゲートウェイを、すべてのディスプレイをそれぞれのゲートウェイのthings属性 (例: )として扱うとよいでしょう。そうすれば、新しい画像をディスプレイにアップロードする必要があるときはいつでも、ネストされた属性の をそれぞれのディスプレイ属性 (たとえば、ネストされた to ) に簡単に更新できます。トピックを使用してそれを行うことができます(例: )。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. 大量のデータの処理:ゲートウェイのすべてのディスプレイを 1 秒あたり数ビットマップで更新する必要がある場合、ゲートウェイごとに何千ものディスプレイがあることを考えると、帯域幅のボトルネックとそれらすべての MQTT メッセージの同期が発生する可能性がある問題だと思いますあなたのthing shadowトピックで。各ディスプレイを時々更新するだけでよいのであれば、あなたのコンセプトはうまく機能すると思います。

考慮すべき事項：

  1. AWS IoT MQTT 実装は、メッセージが受信される順序を保証できません。メッセージを特定の順序で受信する必要がある場合は、それをアプリケーションに実装する必要があります。

  2. AWS IoT はまだベータ サービスであるため、多くの実装の詳細が変更される可能性があります。

于 2015-11-13T13:29:42.100 に答える