Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IoTビジネスの現場で学んだNode-RED活用術

701 views

Published on

2018/11/28 Node-RED UG勉強会 2018 年末LTパーティ @ ウフルで発表したスライドです。

Published in: Technology
  • Be the first to comment

IoTビジネスの現場で学んだNode-RED活用術

  1. 1. IoTビジネスの現場で学んだ Node-RED活用術 吉野祥之(Yoshino Akiyuki) 2018/11/28 @ Node-RED UG
  2. 2. • NTTコミュニケーションズ株式会社 • 経営企画部 IoT推進室 • 主にIoTデバイスのエンジニアリングや プロトタイピングを担当 • EnOcean芸人ともいう • 2児(3歳♂/1歳♀)の父親やってます 吉野 祥之(よしの あきゆき)
  3. 3. Things Cloud ® データ収集・可視化がすぐに実現できるIoT向けAEP* *AEP=Application Enablement Platformの略称
  4. 4. オフィス移転進行中
  5. 5. IoT仕込みました
  6. 6. Meeting Space Monitoring • Up to 200 devices (GW, Sensor) Restroom Monitoring • Up to 1,000 devices (GW, Sensor, Light) Node-REDで作りました
  7. 7. IoT × Node-REDの親和性 ■ IoTあるある • ビジネスモデルが超ゆるふわ -> プロトタイピングが有効 • 必要な機能はシンプルかつ大概似てる -> 再利用率が高い • センサ入力 -> データ加工 -> クラウドへのPOST • クラウドへのPolling -> 処理内容取得 -> ローカルデバイスの制御 ■ Node-REDの利点 • 習熟コストが低い -> GUIエディタ、同期処理的な記法 • 開発スピードが早い -> デバッグノード、豊富な入出力、再利用性 IoTにはNode-REDが有効
  8. 8. 本題:Node-RED活用のノウハウ データモデル デザインパターン Tips
  9. 9. 本題:Node-RED活用のノウハウ データモデル デザインパターン Tips
  10. 10. データモデルの考え方 • Node-RED初学者に対して真っ先に伝えるべき点(だと思う) • 必要な変数はメッセージ変数(msg)のプロパティとして扱うのが基本 • デバッグノードが使える、msg._msgidで一意性が担保される、などいいことが多 い • ただしmsg.payload、msg.url、msg.req、msg.resなど予約語的にノードで利用さ れる変数があることは知っておく(利用を避ける) • サブフローへのパラメータ受け渡しはmsg.paramにする、などしておくと汚染さ れづらい
  11. 11. データモデルの考え方 • Functionノード内だけで利用する変数はメッセージ変数にしない • メモリ節約観点でも重要 • タブ間でデータを共通して利用する必要があればグローバルコンテクス ト(global)の利用はアリ • コンフィグパラメータか状態値(フラグ)など • その他のデータを受け渡しする場合はUI&APIパターンを検討すべき • 基本は各タブでフロー完結させる方が望ましい • コンテクストオブジェクト(context)やフロー変数(flow)はあまり使ったこと がない • コンテクストオブジェクトは使い所ありそうな気もするけれど
  12. 12. 本題:Node-RED活用のノウハウ データモデル デザインパターン Tips
  13. 13. デザインパターン • Node-REDの癖が如実に現れる部分、生産性/メンテナンス性が大 きく変わる • Node-REDの基本ノードを最大限活用するのが前提 • Functionノードの利用は必要最小限とし、1つのFunctionノード内のコード量 は極力小さくする • https://qiita.com/zuhito/items/e9abfd6f1ba188f908ed は必読 • ただし全部を使うことはない
  14. 14. よく使うデザインパターン 2. UI & APIパターン • 特にAPIパターンの方で内部ロジックを実装 • ログ出力をこのパターンで実装するのもアリ • クラウド環境ではlocalhost指定ができない場合があることに注意 4. Whileパターン • 基本中の基本
  15. 15. よく使うデザインパターン 5. Sequenceパターン • サブフロー内での値退避など • さっと作るには重宝 6. Aggregatorパターン • 設定ファイルの読み出し • APIの並列呼び出し
  16. 16. 本題:Node-RED活用のノウハウ データモデル デザインパターン Tips
  17. 17. その他のTIPS • Cron的にメッセージ出力したい • 定期的に死活メッセージを飛ばす、試験用データ作る、etc. • Injectノードでできる
  18. 18. その他のTIPS • 初期化待ち • 初期化処理を確実に終わらせてから後続処理したい時に • 複数の機能を持たせたい時に共通仕様にしておくと楽 • 初期化フラグはglobal変数にしておけばタブまたぎで使える
  19. 19. その他のTIPS • ロギング • Debugノードを利用するよりFunctionノードの方が自由度高い • node.debug() / node.trace() がv0.18.5で使えるようになった • しかしNode-REDのVersionによって処理分けないと怖い • ロギング用ノードをつける時にはノード接続順に注意 • ノード接続順次第でログ出力順序が狂いやすくなる
  20. 20. その他のTIPS • Functionノード内でのrequire • Moment.js使いたいよね、、、 • settings.jsに書けば使える(公式に書いてある) https://nodered.jp/docs/writing-functions
  21. 21. その他のつらみ • 構成管理辛すぎるぉ • 愚直にコメントノード置いて涙ぐましく管理 • diff取れないの怖い • サブフローの管理はさらに大変、、みなさんどうしてますか • VersionUP激しいぉ • メジャーなノードにもゴリゴリ更新入るので互換性確保が怖い • contrib系のノードに手を出しづらい一因でもある • Node.jsもLTS出たことですし、、、 • テストのノウハウ貯めたいぉ • 複雑なことやりだすと死ねそう
  22. 22. まとめ • IoTとNode-REDの親和性 • 習熟コストの低さ、再利用性の高さ、Try&Errorの高速化 • Node-RED特有の開発ノウハウ • データモデル設計 • デザインパターン • UI&API / While / Sequence / Aggregator • その他tips • Cron実行 / 初期化待ち / ロギング / require • 困りごと • 構成管理、VersionUP、テスト方法、etc.
  23. 23. Thank you!

×