はじめに
約 2 年ぶりの Qiita 投稿となります。
今回は AWS IoT Core にある Device Shadow を触ってみたのでそこで自分が気になったところをまとめたいと思います。
Device Shadow とは
Device Shadow どのようなサービスかは @MCYamamoto さんの記事が大変参考になるのでこちらを読んでいただくのがいいかと思います。僕も最初にこの記事を読んで機能を理解しました。
https://qiita.com/MCYamamoto/items/b133a819650db386c132
メリット
エッジは電源が入っていなかったり、設置先のネットワークが悪かったりすることが往々にしてあります。
エッジの設定ファイルを手動で ssh や MQTT などで変更しようとすると上記の理由でできなかったりすることがあり、運用上厳しかったりします。
そこでシャドウを使うと IoT Core に対して設定値（desired）を変更するようにすればよく、エッジの状況を考慮する必要がなくなるため、とても便利です。
フィールドの変更
ShadowTopicPrefix/update トピックを publish することで変更可能です。
Shadow を追加した時のデフォルトが "welcome": "aws-iot" なので desired を "welcome": "aws-iot2" としてみます。
{
"state": {
"desired": {
"welcome": "aws-iot2"
}
}
}
delta も変更されていることが確認できるかと思います。
フィールドの追加
僕がドキュメント読んだだけだとよくわからなかったところです。
機能追加等で既存のエッジに新たな設定値を追加したいケースはあるかと思います。
ShadowTopicPrefix/update/delta ドキュメントの方には
属性が desired セクションにあるが、reported セクションに同じ属性がない場合、その属性は含まれません。
とあり、フィールドを追加した時には delta に反映されないと思ってました。
ただ、delta に関するドキュメント のほうには
delta 状態は、desired 状態と reported 状態の違いを含む virtual 型の状態です。desired セクションに含まれるが、reported セクションに含まれないフィールドは、差分に含まれます。
とあり、フィールドを追加した際も delta に反映されるとありました。
実際に desired へ追加したところ、確かに delta は更新されており、フィールドの追加にも対応しているようでした。
実際に動かした後もう一度ドキュメントを読み直し、
属性が desired セクションにあるが、reported セクションに同じ属性がない場合、その属性は含まれません。
の 属性 が IoT thing のほうの属性 のことを言っているのだろうと無理矢理納得しました。（）
フィールドの削除
残っていても邪魔なので、仕様変更で今まで使ってた設定値を削除したいケースはあるかと思います。
ただ、desired の更新を行うことでエッジのフィールドを削除する方法はなさそうでした。
なので、使っていないことを明示的にするために "welcome": "not used" 等のチームで決めた値にしておくのがいいかもしれません。
さいごに
今回はドキュメントと AWS コンソールでポチポチしただけで終わったので、今後はラズパイとかに導入して使ってみたいと思います。