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 をこのテストケース用に新規に作成します。それぞれ次のようにセットしました。
Action | Resource | 備考 |
---|---|---|
Connect | testDevice01 |
MQTT におけるクライアントID |
Publish | $aws/things/testDevice01/shadow/update |
シャドウに Publish するトピック |
Subscribe | MyTopic* |
- |
Receive | MyTopic* |
- |
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 を作成します。これはテスト内容が変わり、デバイス側で実行する動作が変わるためです。
今回は次のようにセットしました。
Action | Resource | 備考 |
---|---|---|
Connect | testDevice01 |
MQTT におけるクライアントID |
Publish | $aws/things/testDevice01/shadow/update |
シャドウに Publish するトピック |
Subscribe | $aws/things/testDevice01/shadow/update/* |
desired の情報の受け取り |
Receive | $aws/things/testDevice01/shadow/update/* |
desired の情報の受け取り |
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 で デバイスシャドウのテストを試してみました。
ドキュメントだけだとなかなか使い方が把握できず、試行錯誤でトライ&エラーを重ねながらの検証となりましたが、おおよその動作は理解できたかと思います。
引き続き他のテストについても確認していきたいと思います。
以上です。