AWS IoT Core Device Advisor で Device Shadow のテストケースを実施する

前回の記事で AWS IoT Core Device Advisor の基本的な使い方を「MQTT Connect」のテストケースを用いて確認しました。

今回はデバイスシャドウのテストケースを試してみたいと思います。

デバイスシャドウのテストケース

デバイスシャドウのテストケースは 2 種類が用意されています。

• Shadow Publish Reported State
• Shadow Update Reported State

テストケース：Shadow Publish Reported State を試す

「Shadow Publish Reported State」のテストケースでは、該当するシャドウのトピックにデバイスからメッセージを正しく送信できるか（reported 情報を送信できるか）をテストします。

今回は、前の記事で作成したテストスイートをそのまま使います。もしなければ新規に作成して下さい。
作成済みのテストスイートを使うので「Edit」を押して編集していきます。

画面左のテストケースから「Shadow Publish Reported State」をドラッグ・アンド・ドロップで中央のテストグループに追加します。「MQTT Connet」のテストはなくてもいいですが、事前に接続テストを行いたかったので残しています。

次に Device role をこのテストケース用に新規に作成します。それぞれ次のようにセットしました。

Subscribe と Receive は、特に使わないと思ったので適当なものをセットしています。
（入力は必須ですが、上記のような内容でも問題ありませんでした）

次のレビュー画面で内容確認して「Create a new version」をクリックすれば新しいバージョンのテストスイートが作成されます。

新しいバージョンが作成できたら「Actions」から「Run test suite」をクリックしてテストを開始します。

テストを行う thing を選択して「Run test」をクリックしてテストを実行します。

テストが開始されましたが、最初の「MQTT Connect」のテストケースが「in Progress」で実行中になっています。

前回と同じようにテスト用のエンドポイントに接続できると、テストステータスが「Passed」になり、次の「Shadow Publish Reported State」が「in Progress」に変わりました。

最初のテストが成功すると一度切断されて、しばらく画面のようなエラーが出て接続できなくなります。
少し時間が経つとまた接続できるようになります。

接続できるようになれば、シャドウの $aws/things/testDevice01/shadow/update に reported のメッセージを送信します。

正常に送信できればテストが成功してステータスが「Passed」に変わります。

テストケース：Shadow Update Reported State を試す

次に2つ目のテストケース「Shadow Publish Reported State」を試します。このテストケースでは、デバイスが状態データを受け取り、デバイスから状態を同期できることをテストします。

先程と同じテストスイートを引き続き使います。前回とは違いテストケース「Shadow Update Reported State」を追加しています。

テストケースを追加したら、デバイスが受け取る「Desired state」を定義します。
「Shadow Update Reported State」にある「Edit」をクリックすると、画面左側に設定画面が出るので、こちらの「Desired state」にある「Edit」をクリックします。

「Desired state」を編集できる画面が開くので、ステータス情報を入力します。今回はシンプルに下記のようにしました。

{"power": "off"}

「Desired state」を入力したら、元の画面で「Done」ボタンをクリックして編集を確定させます。忘れないようにしましょう。

次の画面では、またあらためて新しく Device Role を作成します。これはテスト内容が変わり、デバイス側で実行する動作が変わるためです。

今回は次のようにセットしました。

thing の名前が長かったりして 50 文字を超えると入力できないので注意してください。
文字数超過の場合は、直接 IAM Role のポリシーを編集すれば対応できます。

最後にレビューして「Create a new version」をクリックします。

テストスイートの新しいバージョンが作成できたら、先程と同じ手順でテストをスタートしてください。テストがスタートしたら、先程と同じ手順で最初のテストである「MQTT Connect」のテストを終了させてください。

「MQTT Connect」のテストが完了したら、次のテストケースに移ります。ここでは最初に Desired の情報を受け取る必要があります。
メッセージを受け取るには、MQTT でテスト用のエンドポイントに接続した上で、サブスクライブを実行します。MQTTX では「New Subscribe」ボタンを押します。

サブスクライブしたいトピック（$aws/things/testDevice01/shadow/update/delta）を入力して「Confirm」をクリックします。

正常に subscribe できたら、次の画面のように事前に設定した Desired の情報がテスト環境から受信できます。テスト環境から送られているメッセージの clientToken は DeviceAdvisorShadowTestCaseSetup となっています。

Desired の情報を受け取ったので、デバイス側の状態を同期させます。同期させるといっても今回はデバイスのLED状態を変更するとか、そういうことはやらないので、そのまま reported の情報を送ります。
desired と同じ "power": "off" で送っていますね。

送信先のトピックは $aws/things/testDevice01/shadow/update です。

{
  "state": {
    "reported": {
      "power": "off"
    }
  }
}

これでデバイスとクラウド側で状態が同期されたので、テスト結果も「Passed」になりました。

Desired state の注意点

前回のテストでは次のようなメッセージをデバイスから publish していました。

{
  "state": {
    "reported": {
      "power": "on"
    }
  }
}

そのためテスト環境側から見ると、デバイスは "power": "on" という状態を送ってきたと見えています。今回のテストで、Desired の情報も "power": "on" とすると「既にデバイスから送られている情報と同じである」ということでテストがエラーになります。

そのため、今回は先程とは異なる "power": "off" を Desired にセットしています。新規にテストスイートを作り直せばこのような事象は発生しません。

最後に

今回は、AWS IoT Device Advisor で デバイスシャドウのテストを試してみました。
ドキュメントだけだとなかなか使い方が把握できず、試行錯誤でトライ&エラーを重ねながらの検証となりましたが、おおよその動作は理解できたかと思います。

引き続き他のテストについても確認していきたいと思います。

以上です。