OpenBlocks（PD Repeater）の設定
OpenBlocksでPD Repeaterの設定を行います。
ここから先の設定はAWS IoTに接続するための設定ですが、実は前の章のNode-Redを活用すればAWS IoTに接続は出来てしまいます。なので冗長 な構成 （ここでいう冗長は保守的な意味の冗長ではなく、一般的な意味の）になっていますが、通信のお勉強ということでやっていこうと思います。
PD Repeater とは、
PD RepeaterはWEB UIにて設定したデバイス番号を元に、抽象名前空間(abstract)のUnix ドメインソケットを作成します。(作成する対象は送信対象を”送信する”とし、送信先が有効でかつlocal以外が設定されているデバイスです)このUnixドメインソケットに対して書き込みを行った場合、書き込んだデータをクラウドへデータを送信します
https://www.plathome.co.jp/wp-content/uploads/openblocks-iot_data-handling-guide_v4-0-0.pdf
公式ドキュメントから引用でしたが、いくつかわからない単語が出てきたので調べたところ、
Unixドメインソケット
UNIXドメインソケット（英: UNIX domain socket）や IPCソケット とは、単一のオペレーティングシステム内で実行されるプロセス間でデータを交換するためのデータ通信の終点
http://bit.ly/2wrnw2F
UNIXドメインソケットは、アドレス・名前空間としてファイルシステムを使用している。これらは、ファイルシステム内のinodeとしてプロセスから参照される。これは、2つのプロセスが通信するために、同じソケットを開くことができる。しかし、コミュニケーションは、完全にオペレーティングシステムのカーネル内で発生する
こちらはソケット通信の種類の一つで、INETドメインソケットがネットワーク上でマシンを超えてのプロセス間通信を行え、IPアドレスやポート番号で通信相手を特定するのに対し、UNIXドメインソケットは同じマシンの中で動いているプロセス同士が通信を行うための仕組みで、通信相手の特定方法にはファイルシステムを使用するので、pathなどで特定する。という認識でいます。
抽象名前空間
abstract (抽象): 抽象ソケットアドレスは、
https://scrapbox.io/shimizukawa/%E6%8A%BD%E8%B1%A1%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93sun_path[0]がヌルバイト (‘\0’) であることから (パス名ソケットから) 区別できる。 この名前空間におけるソケットのアドレスは、 sun_path の残りのバイトの、 アドレス構造体の指定された長さの範囲で表される (名前中のヌルバイトには特別な意味はない)。 この名前はファイルシステムのパス名とは何の関係もない。 抽象ソケットのアドレスを返される際には、 返される addrlen は sizeof(sa_family_t) より大きく (つまり 2 より大きく)、 ソケットの名前は sun_path の最初の (addrlen – sizeof(sa_family_t)) バイトに格納される。 ソケットの抽象名前空間は Linux による拡張であり、移植性はない。
そして抽象名前空間はUNIXドメインソケットの特徴であるファイルシステムでの特定を利用し、実際に存在しない（ファイルシステムに関係ない）パスを作成し、そこにUNIXドメインソケットを作成し、通信できるようにする仕組み、と認識しました。
このPD Repeaterを使用することで、OpenBlocks内部で動いているNode-Redから送信されてきたデータをOpenBlocksの設定に従いクラウドにあげることが出来ます。
PD Repeaterを使うための設定をやっていきます。
[サービス]からIoTデータを選択し、[IoTデータ]タブのアプリ設定でPD Repeaterを使用するにチェック。このときデフォルト使用アプリも同様にチェックを入れること。
[基本]タブからUserデバイス登録でUserデバイス登録をします。ユーザーメモ欄には今回使用する「CO2センサ」と記入します。保存ボタンを押すと、デバイス登録が完了します。
次はIoTデータ送受信設定です。[IoTデータ]タブから送受信設定、本体内とAWS IoT（awsiot)を使用するにチェック。AWS IoT内の設定は前回の記事の「OpenBlocks IoT ⇒ AWS IoT」の章に書いてありますのでそちらをご覧ください。
更に下のユーザーデバイス登録もEnOcean機器の登録と同じ要領で設定します。保存をしたら設定完了です。
設定後、反映させるために再起動を行ってください。
これでPD Repeaterを使用したデータの受け渡しの準備が整いました。送信先のAWS側の構成は前回の記事とほとんど同じなのでそちらをご覧ください。
Node-Redに戻り、injectのボタンをクリックし、AWS S3のバケットにうまくデータが送信されていたら完成です。
可視化
今回はNode-Redのinjectノードを編集し、10秒間に1回測定を行い50分間データ収集を行いました。ノードの設定は以下です
データ測定方法は、
- 小部屋の窓を解放し完全に換気を行ってCO2値を限界まで下げる
- 窓とドアを閉め、センサを置いて無人状態で10分放置
- 窓とドアを閉め、中で20分間一人で作業（PC1台）
- 窓とドアを閉め、センサを置いて無人状態で10分放置
- 窓を解放し、換気を行いながら10分測定
のルーチンでデータ測定を行いました。温度、湿度ともにほとんど変化はありません。
収集したデータを基にAWS Quicksightで2つのセンサをグラフ化し比較してみました。
両者のグラフを見比べてみるとK-30の方が推移がなめらかでCDM-7160の方があまり安定していない印象です。（お値段に多少の差があるせいかな…と邪推したり）
K-30は入室タイミングと換気のタイミングがはっきりと見て取れます。一方CDM-7160の方はガタついてはいるものの、何とか入退室の状況はわかります。ただ、見やすさでいうとやはりK-30に軍配が上がりそうです。CO２を使った入退室判定等の処理でもがたつきがあると大変そうですしね。
今回の検証ではセンサメインではなかったのでイニシャライズや設定を特にしていないので正確な値かどうかはわかりませんが、少なくとも人の有無や換気のタイミング、詳しく見ると人数まで推定できそうなことがわかりました。
おわりに
今回はCO2センサをシリアル通信でWRoom-02に接続し、
WRoom-02でWebサーバを立ててリクエストを待ち受け、
Node-Redでhttpリクエストを投げてデータを整形してPDRepeaterに投げ、
OpenBlocksのPDサービスでAWSにデータを上げる。という内容でした。
前回に比べてやることは多かったものの、一番の難所であろうクラウドへの接続をOpenBlocksが一手に担ってくれたおかげでだいぶ楽に進められました。
CO2センサはあまり使う機会はなかったですが、その場所の情報を得るという意味ではたくさんの情報を得られるパラメータなのでした。活用の機会はたくさんありそうです。
次はこれまでとは異なり、とあるものを使ってよりスムーズかつパワフルなIoTをしてみようと思います！