○きっかけ
社内のIoT通知機（窓開閉、着座、降雨）を、（UDPマルチキャストで）数週間運用してみたが、どうにも実用に耐えない。
85％ぐらいは、キチンと動作するが、15％くらいは通知が受信機(M5Stack)に届いていないようだ。
◯考えられる原因
- パケットがロストしているUDPは信頼性を確保する仕組みがなく、 再送制御もないので、1ショットの送信には向かないことはわかっていた...。
- TTLの問題255にしてみたが変わらなかった。IoT機のWiFiのAPが異なると、受信機まで届きにくい傾向にあった。
- プログラム・ロジックの問題これも考えられなくないが、あれこれいじっても改善しなかった。
◯Node-REDへ移行を決意
2年ほど前から運用しているIoT機（TCP）は、きちんと動作しているので、いちばん怪しいUDPを諦め、TCPへ変更することにした。TCPにすると投げる相手（サーバー）が問題になってくる。そこで前から気になっていたNode-REDの使用に本腰をいれてみることにした。
当社では、QNAP製のサーバーを使用しており、その中にQIoT Suite Liteというアプリがある。用途的にドンピシャだったので、以前、使ってみたが、CPUが非力のせいか、すぐ「応答なし」になってしまいどうにも使えない（QNAPサポートに連絡して問題は解消した）。また、その仕様もなかなか理解できず、結局、使用を諦めてしまった経緯がある。
今回は、WinodowsにNode-REDをインストールして、地道に理解することにした。
○どうにか運用にこぎつける
ようやくUDPから、mqtt+Node-REDでのシステム再構築が完了した。今回、良かったのは、素のNode-REDから使ってみて、なんとなくQIoTの構造が理解できたことだ。QIoTは簡単にいえば、IoTで必要になりそうなアプリをまとめたものなのだが、以前は、1つのものとしてしか見えていなかったため、構造がわからず途方にくれていた。
[QIoT Suite Liteの構成]
+IoTアプリケーション
+ダッシュボード
+ルール（Node-RED）
+モノ
素のNode-REDからはじめてみて、社内のIoT通知機システム程度なら、QIoT Suite Liteを使うまでもなく、かえって煩雑になることがわかった。
○構築したフロー
今回は、brokerに送られてきたメッセージを、接続されている端末に送り返すだけなので、下記のようなフローになった。
injectで、疑似的にメッセージを送信できるのが非常に便利で助かった。いままでC#で、シュミレータソフトを作ってデバッグしていたが、今後はそんな手間もなくなる。
着座というのは、トイレ使用中の通知機。
表示機というのは、M5Stackで各通知からのメッセージを表示するもの。
○Node-REDでロジック処理
前記の例（着座や降雨通知機）では、ただメッセージを転送しているだけなので、UDPのマルチキャストとあまり変わり映えしない。
着座通知機は、常時電源がONなので、現在の状態の問い合わせ（状態取得）に応答させることができるが、
窓開閉通知機はバッテリー駆動なので、状態の問い合わせをしようにも、スリープ状態のため応答が返せない。
そこで、通知の内容をファイル保存して、状態の問い合わせがあった時には、Node-REDが直近の状態を返すようにした。
なかなか参考事例がなくて困ったが、できてしまえば、実に簡潔できれいなフローで実現できることがわかった。
状態取得は別なノードにした方がすっきりしたようにも思うが、とりあえず、これで運用してみることにした。
○まとめ
Node-REDは、IoT関連ならかならず紹介されるツールだ。確かにコード記述なしにできることも多いが、どういう場合にコードが不要で、どういう場合に必要なのかを区別できるようになるには、ある程度、使っていかないとわからない。今回、多少の目星がつくようになったので、運用している別なIoTシステムもNode-REで構築しなおすことにした。
以上