2009年創業。埼玉県川越市一筋のIT企業です。
イー・レンジャー株式会社 電話
イー・レンジャー株式会社 > 【IoT】久しぶりのラズベリーパイ。MQTTでパブリッシュしたセンサーデータの保存と可視化。

【IoT】久しぶりのラズベリーパイ。MQTTでパブリッシュしたセンサーデータの保存と可視化。

最終更新日: 2021/05/20 12:05pm

カテゴリー: IoT, 先進技術

こんにちは。

経理の小高です。

 

オクトパスの開発が忙しくなって以来、IoT関連の研究が疎かになっていました。

弊社開発の製品としては、プラットフォームサービスとしてのオクトパスがあり、その上にシェアが乗っかっています。

そして、直近で(コロナ禍で伸び伸びになってしまったのですが)新サービスのリリースをするつもりでおりまして、それもオクトパスに乗っかっていて、シェアの技術を流用しています。

 

将来的にはここにIoTの要素技術(たとえば、MQTTやデバイスのステート管理など)を入れ込む予定です。

他の記事でもたくさん書いてきましたが、AWSに関するノウハウも相当蓄積しているので、AWS IoT Coreもこれに取り込んでいきます。

 

以前、IoT関連はいつやっていたのかなぁ、と思って記事をみると2017年-2018年になっていますから、もう3年も経っていて驚きました。

当時の作業ログやコードが残っていますので、それをベースに当時やったところまではサクッとキャッチアップしたいと思います。

 

今回のブログでは、

・役割を割り当てた複数台のラズベリーパイがMQTTをPub/Subする。

・MQTTはLAN内に設置したブローカーを経由させる。(これはAWS IoTにブリッジさせますが、今回のエントリーには関係ありません)

・MQTTで流れるデータをデータベースを保存する。

・データベースに保存するデータを可視化する。

・データを簡単に加工したメトリクスによってAlertを上げる。

といった基本的な流れを確認します。

 

さて。

以下は、3台のラズベリーパイです。ラズベリーパイ3台の構成

1.3軸センサー(ジャイロ+加速度)をラズベリーパイ3にI2C接続したもの。

2.温度・湿度・気圧センサーをラズベリーパイ3にI2C接続したもの。(実際には、写真に映っていませんがもう1台あります)

3.ラズベリーパイ3のGPIOから信号を出力させてLEDを点滅させるもの。

となっています。

センサーは接続&コードしやすいI2C接続できるものを使っています。ジャイロはMPU6050、温度・湿度・気圧はBME280。

 

システムの構成図は以下です。

左側のラズベリーパイはセンサーでデータを取り出してそれをMQTTでサーバーに対してPublishします。これを上の写真の1と2にあたります。

真ん中にあるのは、MQTTサーバー(ブローカー)にデータベースサーバーと視覚化ツールを導入したUbuntu Serverです。

データベースサーバーにはInfluxDB2、視覚化ツールとしてはGrafana7.5を使いました。

最後に右端のラズベリーパイはアクチュエーターとして機能させます。上の写真だと3にあたります。

ラズベリーパイ、UbuntuでのプログラムはPython3で行いました。

MQTTでのpub/subの間隔は原則的に3秒間隔としました。

 

今回の実験で一番感銘をうけたのが、(ラズベリーパイではなく)InfluxDB2でした。

以下はBME280を接続したラズベリーパイがパブリッシュした温度情報(時系列データ)を、UbuntuサーバーでサブスクライブしてInfluxDB2に保存したものです。

時系列データなので本質的に以下のようなグラフになりますが、InfluxDBはV2以降、このようなGUIをバンドルしています。

 

 

Grafanaは他のシステムで使ったことがあります。

以下はInfluxDB2に保存されたBME280(2箇所)の温度・湿度・気圧データをgrafana7.5で表示させたものです。

InfluxDB2の画面(上)と似ていますが、こちらの方が(役割として当たり前ですが)きれいですね。

 

 

さて。

下の左上に「ジャイロ」と書いたグラフがあります。

これは3軸センサーを動かしたときにジャイロで検出される「変位」を表示しています。ここでいう「変位」とは「時系列データの移動平均」です。

ジャイロで動きを検出する場合など、「動き」を表すデータは「変位」として計測しますが、これは小さいデバイスには不向きな作業です。

「変位をとる」場合には、すくなくとも「前回と今回の2回分のデータ」を保持する必要がありますし、移動平均法なら平均する数だけデータをスタックする必要があります。

データを保持するためには(揮発性メモリ上で作業するなら)デーモンを常駐させる実装になりますし、そうでなければシリアライズのための機能をデバイスがもっている必要があります(そして、持っていたとしても重たい処理になります)。

 

InfluxDB2が「いい」と思ったのは、この部分をサーバーサイドで行える点です。

今回の実験では、InfluxDB2のサーバー上にInfluxDB2をクエリーする(そしてその結果をパブリッシュする)MQTTクライアントを動かしましたが(3秒間隔でのクエリでは)性能になんら問題は発生しませんでした。

LEDをつけたラズベリーパイは、このデータをサブスクライブして、それが閾値をこえた場合に「ジャイロで変位を検出した」と判断してLEDを点滅させます。

 

今後もやっていることなどブログで発信していきます。

 

←「」前の記事へ   次の記事へ「」→