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