作ってみた! 遠隔地の親を見守るIoTアプリ
IoTアプリを簡単に開発する例として、山崎氏は実家にて独りで暮らす母親のためのIoTアプリ開発を紹介。高齢となり、寒さで風邪をひかないか、夏は熱中症にならないか、息子としては心配になる。そこで「IoTな感じの見守りアプリ」を開発することにした。
システム的な要件を抜き出すと、「規定値以下または以上の気温になる」と、「遠隔地に通知する」となる。
手軽に作るため、山崎氏はAmazonで入手できるデバイスで試作することにした。選んだIoTデバイスは「NETATMO ウェザーステーション」。天候センサー(温度、湿度、気圧、二酸化炭素、騒音など)が一通りそろっていて、スタイリッシュなデザインが特徴だ。ネットワークに接続し、設定値になるとスマホにアラートを送ることかできる。
この要件をNode-REDのフローエディタで開発してみる。5分間隔のトリガーを繰り返して気温を取得し、測定温度により処理を分岐する。寒すぎる、または暑すぎるとメールとSlackに通知し、それ以外であれば確認のためのデバッグメッセージを出力する。
注目は分岐処理。温度により処理が分岐するところを「switchノード」にて、分岐条件を記入する。「<=」や「is between」を選んで気温を記入することで、コーディングせずに条件分岐できる。ループ処理もコーディング不要だ。
今回の処理はクラウドサービス間だけでデータをやりとりする。IoTデバイスから開発環境となるenebularへデータが受け渡され、実行環境のHerokuにデプロイされた。もちろん、Raspberry Piのようなデバイスを使うフローも可能だ。
またデータの蓄積にFirebase、データ可視化に「enebular INFOMOTION」を用いることで発展させることもできる。これらはenebular標準機能として提供されている。
山崎氏はオススメ記事も紹介した。Node-REDで効率がいい設計パターンをまとめた「目からウロコ!Node-REDのデザインパターン10選」がある。これは2015年にQiitaに投稿された記事で、多くの人に読まれている。山崎氏によると、この記事の投稿者は後日上司に「この記事には良いことが書いてあるから、君も読むといい」と勧められてしまったという。
最近では続編となる「目からウロコ!Node-REDのアンチパターン10選」が、同じ投稿者から発表された。前回とは逆に、アンチパターンをまとめたものとなる。
チームで開発するときのポイント――役割分担や初期設定の管理
企業などチームで開発する場合には、役割に応じた権限付与が必要になる。enebularではプロジェクト管理者「Project Owner」、プロジェクトメンバー「Project Collaborator」、1つのアセットにひも付いたメンバー「Outside Collaborator」といった役割を使うことができる。また「owner」「superdev」「developer」「operator」「user」で権限を分けることができる。
またチームでフローを共有すると、マジックナンバーやマジックストリングが分散してしまう問題が起きてくる。1つの有効な対策となるのが各種設定をまとめた初期化フローを作成し、設定するノードを1つにまとめることだ。
開発コミュニティも、ある意味、協力し合える、より大きなチームと言えるだろう。enebularのフローなどの開発用資産(Asset)の公開・共有機能を使ってAssetをインポートして開発を効率化したり、自分の開発したAssetをコミュニティに還元したりするもまた楽しい(Fun)。
ところで、こうしたコーディング不要のツールに対して「(慣れたプログラマなら)コーディングしたほうが早いのでは」という疑問が投げられる。それに対して山崎氏は、IoTLT主催者である菅原のびすけ氏のコメントを紹介した。
「確かにデバイスだけなど、1つのテクノロジーのプログラミングならそうですね。でも、デバイスや複数のクラウドテクノロジーが重なってくると、コードも複雑になって訳がわからなくなるので、そんなときはenebularなどのノンコーティング開発がいいですね」(菅原のびすけ氏のコメント)
将来を見据えた保守性を考えると、ノンコーディングで複雑性を減らしたほうがメリットがあるということだ。
最後に山崎氏は「コーディングを減らして楽しくやりましょう。試行錯誤が低コストで素早くできる開発環境を選びましょう。そして先人の知恵をうまく借りましょう。ただし借りたら返すことも大事です。得た知見をコミュニティに発表することや、フィードバックを送ることで恩返しができます。ぜひまずは第一歩を踏み出しましょう」と述べてセッションを締めた。
お問い合わせ
株式会社ウフル