ラズパイZEROとモーションセンサーで見守りシステムをつくる(その3 AWS IoT Core等の設定)
Contents
前回からのつづき
ラズパイとモーションセンサーで実家用の見守りシステムを構築した時の3回目。
初回の「全体構成とハードウェア編」はこちら。
2回目の「事前設定編」はこちら。
今回は検出した件数情報を保管する為の、
- AWS IoT Coreの設定
- AWS DynamoDBの設定
に関する記事とする。
尚、初回の全体構成編でも書いたがDynamoDBへの検知件数の格納は必須の機能というわけではない。
見守りシステムとしては直近数十時間の状態と通知が重要なのであって過去数ヶ月(数年)の蓄積は必須の要件では無い。
しかしデータを蓄積しておけば機械学習で異常値を自動で検出する事も出来るようになるのではないかとも思い、DynamoDBに10分毎の検出結果を書き込むことにした。
またAWS IoT CoreとDynamoDBの使用料金が一ヶ月使用しても数ドルにしかなりそうにないのもデータを保存格納する事にした理由の一つ。
尚、記事の最後に今回の設定について動画で説明をしているので見てみてほしい。
AWS関連の設定
最初にAWS IoT Coreの初期設定を行った後にDynamoDBを作成して、再度IoT Coreに戻りIoT Coreにpublishされた時に自動的にDynamoDBにデータが連携されるようにルールの設定を行う。
大まかな流れは、
- モノの作成(IoT Core)
- 証明書の作成と追加(IoT Core)
- ポリシーの作成とアタッチ(IoT Core)
- エンドポイントを控える(IoT Core)
- MQTTのテスト(IoT Core)
- テーブルの作成(DynamoDB)
- ルールの作成(IoT Core)
- 有効化(IoT Core)
の順番となる。
モノの作成(IoT Core)
AWSのコンソールにログインしてサービスからAWS IoT Coreを選択する。
以前もAWS IoT Coreの設定に関する記事を書いたが当時と画面レイアウトも若干変わってきているので再度記事にしておく。
見守りシステム用のRaspberryPi Zero WHをモノとしてAWS IoT Coreに登録する。
左のメニューから管理ー>モノを選択して右上の「作成」ボタンをクリックする。
「単一のモノを作成する」をクリックする。
名前に”RaspZWatchOver”を設定して「タイプの作成」ボタンをクリックする。
尚、タイプは必須では無いが今後モノを沢山作成した時にタイプで分類できると便利なので作成しておくことにした。
名前に”RaspberryPiZero”、説明にも”RaspberryPiZero”を設定する。
※説明欄には日本語が使えなかった。
「モノのタイプの作成」ボタンをクリックする。
AWSではリソースにタグをつけて管理する事ができる。
タグの命名規則を調べてみたが特に決まったルールは存在しないようで各自工夫して管理用のタグを作成している様だ。
まだリソースの数が少ないので今回はタグを付けなかったがリソースが増えてきた段階でまとめてタグをつけようと思っている。
先程作成したタイプがプルダウンリストで選択されているので”グループの作成”をクリックする。
グループについても作成が必須ではないが作成しておいた。
名前に”WatchOver”、説明に”WatchOver”を入力する。
画面ショットでは説明欄は”見守りシステム”となっているが日本語が使えなので登録時にエラーになってしまったので”WatchOver”に変更している。
下にスクロールして「モノのグループの作成」をクリックする。
※グループの属性およびタグは設定していない。
「次へ」ボタンをクリックする。
※”検索可能なモノの属性の設定”と”検索可能なモノの属性の設定”は行わなかった
恐らくだがIoT機器は数百、数千、万の機器を登録する事もあるのでタグや属性や検索設定をしっかりやらないと後で管理ができなくなってしまうので色々と属性の設定ができるようになっているのだと思う。
今回は多くても数個の登録なのでタイプとグループは作成したが一連の属性の設定は省略した。
証明書の作成と追加(IoT Core)
証明書を発行してモノに証明書を追加する。
複数の証明書の発行方法があるが推奨の1-click証明書作成(推奨)ー>「証明書の作成」をクリックする。
証明書が作成されるので、
- このモノの証明書
- パブリックキー
- プライベートキー
をそれぞれダウンロードしてファイルで保存した後、CAダウンロードをクリックする。
Server Authentication(サーバー認証)のページが表示されるので”CA Certificates for Service Authentication”をクリックする。
RSA 2048 bit keyの”Amazon Root CA 1”をクリックする。
画面に表示されるテキストをコピーしてファイルに名前をつけて保存する。
文字コードはUnicode(UTF-8)、ファイル名は”AmazonRootCA1WatchOver.pem”で保存した。
ダウンロードしたファイル類はPythonのプログラムディレクトリに./certディレクトリを作成して全てそこに格納した。
先程の画面に戻って「有効化」ボタンを押す。
右上に”署名書は正常に有効化されました”とメッセージが表示されるので「完了」ボタンをクリックする。
※ポリシーをまだ作成していないので「ポリシーをアタッチ」は押さない
ポリシーの作成とアタッチ(IoT Core)
IoT Coreにアクセスする為のポリシーを作成する。
中央に表示されているのでは既に作成済みのポリシー。
左のメニューの安全性ー>ポリシーを選択して「作成」ボタンをクリックする。
- 名前:WatchOver-Policy
- アクション:iot:Connect
を設定する。
アクションに”iot:*”を設定すれば取り敢えず接続する事は可能になるがConnect(接続)とPublish(IoT機器からのPublish)とそれぞれでリソースARN(Amazon Resource Name)を設定することにした。
アクションに”iot:Connect”を入力するとリソースARNに自動的に、
”arn:aws:iot:ap-northeast-1:XXXXXXXXX:client/replaceWithAClientId”が表示される。
ここのreplaceWithAClientIdの部分を”RTRP*”に打ち替える。
”*”はワイルドカード、接続時のClient IDがRTPR始まりのconnect(接続)だけを許可している。
尚、Client IDはプログラムの中で指定する。
効果の”許可”をチェックして「ステートメントを追加」ボタンをクリックする。
- 名前:WatchOver-Policy
- アクション:iot:Publish
を入力するとリソースARNに
”arn:aws:iot:ap-northeast-1:XXXXXXXXX:topic/replaceWithATopic”が表示されるので
replaceWithATopicの部分を”dt/WatchOver/*”に打ち替えた。
ここにはTopicを指定するのだがTopicの設計思想がイマイチ分からなかった。
AWSの資料を検索した所、AWSのデザインペーパーのMQTT Telemetry Topic Syntaxにて、
dt/<application>/<context>/<thing-name>/<dt-type>
の記述をみつけたので、dtに続いてアプリケーション名(WatchOver)を指定して後はワイルドカードにした。
TopicはMQTTメッセージの分類方法で、左から大分類、中分類、小分類の様にOSのディレクトリ構成みたいに分類するものと自分なりに理解した。
許可にチェックを入れて「作成」ボタンをクリックする。
ポリシーが作成された。
ポリシードキュメントは自動的に生成される。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:ap-northeast-1:XXXXXXXXXXXX:client/RTRP*"
},
{
"Effect": "Allow",
"Action": "iot:Publish",
"Resource": "arn:aws:iot:ap-northeast-1:XXXXXXXXXXXX:topic/dt/WatchOver/*"
}
]
}
先程発行した証明書にポリシーをアタッチする。
証明書を選択してアクションー>ポリシーのアタッチをクリックする。
ポリシー一覧が表示されるので今回作成したポリシーを選択して「アタッチ」ボタンをクリックする。
”ポリシーは正常にアタッチされました。”のメッセージが表示される。
エンドポイントを控える(IoT Core)
モノを選択してメニューから”操作”を選択してエンドポイントを表示した後、控えておく。
このエンドポイントは後ほどプログラム中で使用する。
今は左のメニューから”設定”を選択すればエンドポイントが表示される。
MQTTのテスト(IoT Core)
プログラムの作成後であればMQTTのテストをIoT Coreのメニューから行うことが出来る。
※プログラムについては別記事とする
メニューからテストを選択してトピックのサブスクリプション欄に”dt/WatchOver/#”(#はワイルドカード)を入力して「トピックへのサブスクライブ」ボタンをクリックする。
- Publish:データ送信
- Subscribe:データ受信
以下の待受ページが表示されてデータを受信すると表示される。
今回受信する予定のメッセージは以下のJSON形式とした。
{
"ClientID": "RTRPZ0003",
"CountTimeFrom": "2020-01-11 10:50:00",
"CountTimeTo": "2020-01-11 11:00:00",
"Count": 54
}
ClientID | 端末を識別するID 複数箇所に設置する可能性もあるのでラズパイ毎に識別IDを持つ設計にした |
CountTimeFrom | 検知開始時刻(YYYY-MM-DD HH:MM:SS) |
CountTimeTo | 検知終了時刻(YYYY-MM-DD HH:MM:SS) |
Count | 開始から終了までの時刻で検知された件数 |
テーブルの作成(DynamoDB)
IoT Core側の設定は一旦終了。
今度はデータの格納先のDynamoDBのテーブルの作成を行うのでAWSのサービスからDynamoDBを選択する。
表示されたページの「テーブルの作成」ボタンをクリックする。
- テーブル名:WatchOverTBL
- パーティションキー:CountTimeFrom(文字列)
- ソートキー:ClientID(文字列)
を設定した。
パーティションキーを設定した後、ソートキーの追加をチェックするとソートキーが設定できるようになる。
パーティションキーとソートキーでプライマリキー(ユニーク)になる。
同一端末で同じ時刻の検知をカウントする事は無いのでCountTimeFromとClientIDでユニークになる。
またパーティションキーの値でDynamoDB上に保存するパーティション(場所)が決まる模様。
アクセス頻度の高い項目を分離して保存する事により高スループットを実現する設計になっている。
この辺はAWSの資料を参考にした。
その後、”デフォルト設定の使用”のチェックを外した。
セカンダリインデックスは後からでも設定できるので未設定。
読み書き/キャパシティモードは”プロビジョンド(無料利用枠の対象)”がチェックされているのでそのままにする。
オンデマンドを選択すると利用量に応じてキャパシティが増加する。
トラフィックが急速に増加してもキャパシティを確保する必要があるシステムの場合はこちらを選択する。(利用料は上がる)
今回のシステムでは1端末では1メッセージ/10分とメッセージ量が事前に見積もれているのでプロビジョンドを選択した。
読み込み/書き込みともにキャパシティがデフォルトでは5(推定コストは3.32ドル/月)に設定されている。
これは1秒間に5件(サイズは1K)までの読み書きが可能な設定だが実質1端末なので2(1秒間に2回まで)に変更した。
※1でも良かったのだが念の為
IAMロールは自動で設定されているのでそのまま、保管時の暗号化もデフォルトのままで「作成」ボタンをクリックする。
作成されたテーブル
項目はCountTimeFromとClientIDだけが設定されている状態。
キャパシティユニットのサイズは2に設定されていて推定コストは1.33ドル/月。
インデックスは今は設定されていないがこちらの画面から追加設定することが出来る。
DynamoDB側の設定は以上で終了。
ルールの作成(IoT Core)
IoT Coreに戻ってメッセージをサブスクライブ(受信)したら先程作成したDynamoDBのテーブルに追加(INSERT)するようにルールの設定をする。
IoT CoreのメニューからACTー>ルールー>「作成」ボタンをクリックする。
- 名前:to_dynamodb
- 説明:Dynamodb WatchOverTBL Insert
を記入して下にスクロールする。
ルールクエリーステートメント
ルールクエリーステートメント欄に、
SELECT * FROM 'dt/WatchOver/#'
を入力する。
つまりIoT Coreでサブスクライブした全てのメッセージをDynamoDBに追加する条件にしている。
またFROM句にはTopicを指定するのだが、ワイルドカードは”#”なので注意が必要。
そして「アクションの追加」ボタンをクリックする。
DynamoDBに追加設定
アクションの一覧が表示されるので”DynamoDBテーブルにメッセージを挿入”するを選択する
一番下にスクロールして「アクションの設定」ボタンをクリックする。
アクションの設定
テーブル名:WatchOverTBLをプルダウンから選択するとパーティションキーとレンジキーとタイプ(属性)が自動的に表示される。
- パーティションキー値:${CountTimeFrom}
- レンジキーの値:${ClientID}
を設定する。
”この列にメッセージデータを書き込む”欄に”Data”を設定する。
※この項目名でデータが書き込まれる
最後に”操作”欄に”INSERT”を設定する。
ロールの作成
”ロールの作成”をクリックしてこのアクション用のロールを作成(名前は”IoTCoreToDynamoDBRole”)した後に「アクションの追加」をクリックする。
DynamoDBテーブルにメッセージを挿入するアクションが作成された。
エラーアクション
エラーアクションも同様の手順で作成する事ができる(任意)。
何らかの理由でDynamoDBへのメッセージの追加(INSERT)が失敗した時にIoT Coreのトピックにメッセージを再パブリッシュする様用に設定した。
エラーアクションのアクションの追加で”AWS IoTのトピックにメッセージを再パブリッシュする”を選択する。
トピックに”er/WatchOver”を指定してロールを作成した後に「アクションの追加」ボタンをクリックする。
エラーアクションが設定された。
エラーの例。
操作欄に何も設定しなかったら以下のエラーになる。
何らかの理由でDynamoDBにメッセージが追加されない時にこの方法でデバッグする事ができる。
下にスクロールして「ルールの作成」ボタンをクリックする。
※タグは設定していない
有効化(IoT Core)
一覧の右側のメニューより”有効化”をクリックする。
IoT Coreのルールの設定は以上で終了。
メッセージをサブスクライブすると自動的にDynamoDBにメッセージが挿入される。
DynamoDB
DynamoDBに格納された項目。
Data欄にはCountTimeFrom、ClientIDも含んだデータ部が格納されている。
項目の編集
クエリ
ドロップダウンリストから”クエリ”を選択するとクエリが実行できる。
パーティションキーは”=”でしか検索できない。
ソートキーは”=”以外の”<”、”>”、betweenなども指定出来る。
フィルター
”フィルターの追加”で条件式を追加してフィルタリングができる。
続く
今回の記事は以上で終了。
次回はプログラミングの記事とする。
動画
AWS IoT CoreとDynamoDBの設定を動画で説明している。
こんにちは。
私も実家の見守りシステムを作りたいと思っており、とても参考にさせていただいております。
私の場合はデータの保存は不要かな と思うのですが、その場合は今回の「その3 AWS IoT Core等の設定」は不要という認識で合っていますでしょうか?
よろしくお願いします。
ヤッチャさん こんばんは。
そうですね、データの保存が不要であればAWS関連の設定は不要です。
自分は過去データの分析から普段と違う動きをした時に自動で検知してアラートメッセージを送りたかったのでデータ保存をしています。
ご返信ありがとうございます。
また何か不明点等があった際は、教えてください。
よろしくお願いします。
そう備忘録
管理人 さま
こんにちは
突然のご連絡すいません。
こちらを参考にして、部屋の使用状況確認をしたいと考えております
AWSの設定でルールを作成している際に「SELECT * FROM ‘dt/WatchOver/#’」となっておりますが
WatchOverの箇所は作成したタグからのメッセージを許可しているイメージでしょうか
こちらの投稿とても参考になっております、プログラミング・AWSが全くの初心者ですので
もしかしたら度々ご質問するかもしれませんがその際はお手数お掛け致しますがご教授頂けますと幸いです。
やまとさん こんにちは
dt/WatchOver/# の箇所はTOPICを表しています。
次の記事のプログラムでTOPICを指定してAWS IoT CoreにデータをPublish(送信)するのですが、見守りシステムのデータのTOPICを収集するようにしています。
違うシステムも混在している環境で動作させているので、この様な指定をしています。