前回の記事ではIoTお猪口のハードウェアについて解説しました。IoTお猪口の最後の記事ではシステム構成を解説します。POC段階のため、とにかく取り回しの良さと変更の容易さを重視しています。
ネットワーク
ネットワークは全て私用スマホのテザリングを使用しております。社内ゲストwifiを使う方法も考えましたが、まだPoC段階であるため影響が個人に閉じるスマホのテザリングにしております。2台のIoTお猪口を2時間稼働させてほぼ毎秒に1回データを送信し、それをmqttサーバーで受信してGCP datastoreへ転送しても通信量や通信プランの料金で支障が出ることはありませんでした。
各種プロトコル
Raspberry Pi Pico W はHTTP・BLEともに対応していますが、今回はHTTPのみとしました。理由としては最終的にdatastoreへ格納するデータのタイムスタンプをデバイス側で管理したいこと、BLEの接続が複数台運用する前提を考えると手間であったことです。データのタイムスタンプについてもう少し説明しますとdatastoreにはmqttサーバーを経由して書き込んでいますが、IoTお猪口から送信したデータをmqttサーバーで受信するタイミングが頻繁に遅延します。そのため、仮にmqtt上の処理が実際のデータ取得時間から数十秒ずれてもその遅延の影響を受けないように、データ取得時のタイムスタンプを用いる必要がありました。Raspberry Pi Pico Wは時刻の情報を持っておりませんので基準となる時刻を取得してそこからの経過時間を計算することで送信するデータにタイムスタンプを追加しています。
時刻の取得には当初NTPを使用していましたが接続が悪く、しばしば結果が戻ってこないため別の方法を採る必要がありました。代替案としてHTTPでgoogleにアクセスした際のサーバータイムを利用しております。この方法は安定性が高く、かつ1,2秒の誤差は許容できるシステムであるため正確性も問題ありませんでした。
クラウド
現在、GCPにマネージドのIoTサービスはありません。
AWSにはIoT系のサービスが存在しますが手間を考えるとAWSを経ずにGCPのみで完結することが理想でした。大規模な運用であればdataflowを立ててmqttを受けるという選択肢もありますが、dataflowは非常に高額かつ大掛かりであるため今回の用途には不適です。結局、mqttサーバーからdatastoreへ格納する方式を取っています。
可視化
datastoreに格納した結果はStreamlitで可視化しています。
最終的にはGCPのCloud Runに置くつもりでしたが、まだ頻繁に編集するためローカルのdockerで稼働させております。PoC当日はモバイルディスプレイにstreamlitの結果を投影しており、複数名で挙動を確かめたり結果について議論したりとIoTらしいモニタリングを行うことができました。
システム的な展望
今回は結果をほぼ毎秒mqttサーバーへ送信していましたが将来的な利便性を考えると飲んだ・注いだ瞬間だけ通信を行うことにして、かつ通信はmqttサーバーを排してスマホのテザリングにhttpで行うと構成がコンパクトになって理想的です。ついでに現在は私物PCで確認しているstreamlitをGCP Cloud Runに置けば手元のスマホで進捗が確認可能で、私物PCを排すことができます。これで私物PCに誤って日本酒をかけたりスルメをキーボードに落としたりする心配もなくなります。
また、IoTお猪口側からGCPにアクセスして蓄積しているデータを取得し活用するような双方向のやり取りを安定した通信のもとに行うことでデバイスの可能性は格段に拡がります。GCP datastoreに溜まっているデータを加工して戻す Cloud Run Function は構想しております。例えば、その日飲んだ量を端末に戻すことも可能なはずです。
コードについて
コード自体はあまりに拙いので掲載はやめておきました。MicroPythonで書かれており、時刻の取得や各種センサーからの値の取得とmqttサーバーへの通信が書かれているくらいです。次のプロトタイプではジャイロセンサー（MPU-6050）は無くして現在はアームの動きを検知しているホールセンサーの設置位置を変えて傾きも同時に取得することを考えておりますのでコード自体が大幅に変わる都合もあります。
続報をお楽しみに！