なにがでるか

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。前回に引き続き、機械的にHTTPノードのサンプルフローを見ていきます。 ファイルを送受信する 確認するサンプルは、「 読み込み > サンプル > flows > node-red > network > http > 06 - Post file to a flow 」です。フローは2段階に別れており、それぞれ以下の動作をします。 上部フロー：ファイルアップロード用フォーム生成 ファイルのアップロード用ページを表示するためのフローです。パス「 /hello-upload 」でGETメソッドによるアクセスを待ち受けています。ブラウザから「 http://localhost:1880/hello-upload 」にアクセスすると以下のページを表示します。 HTMLボディ部は上部フローのTemplateノードで生成しています。 ブラウザ画面上に表示されている「 選択... 」ボタンを選択するとファイル選択ダイアログが表示されるので、適当なファイルを選択して、ブラウザ画面上の「 OK 」ボタンを選択すると、上述のHTMLの通り、選択したファイルをパス「 /hello-uplad 」にPOSTします。 下部フロー：アップロードされたファイルを受信 上部フローにてアップロードされたファイルを受信するフローです。パス「 /hello-upload 」でPOSTメソッドによるアクセスを待ち受けています。ファイルがアップロードされるとブラウザ画面上に「 Hello <ファイル名> 」を表示します。 ページの内容は下部フローのTemplateノードで生成しています。「 {{req.files.0.originalname}} 」という表記を使ってPOSTデータ内の1つ目のファイル名にアクセスしています。 reqオブジェクトに他にどんなプロパティがあるのかはhttp inノードに載っています。 まとめ ここまで確認したことをまとめます。 アップロードされたファイルには「 {{req.files.<ファイルIndex>...}} 」でアクセスできます reqプロパティ配下のプロパティについて知りたい

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。前回に引き続き、機械的にHTTPノードのサンプルフローを見ていきます。 リクエストヘッダを扱う 確認するサンプルは、「 読み込み > サンプル > flows > node-red > network > http > 04 - Access HTTP request headers 」です。リクエストヘッダの扱い方を確認できます。フローは 前回の記事 で紹介したものとほぼ同じなので、細かい説明は省略します。ポイントはTemplateノードにある「 {{req.headers.user-agent}} 」です。これでHTTPリクエスト内のUser-Agentヘッダの値が取得できます。 ペイロードを扱う ペイロード＝HTTPボディ部ですね。確認するサンプルは、「 読み込み > サンプル > flows > node-red > network > http > 05 - Post data to a flow 」です。これも 前回紹介したフロー とほぼ同じなので詳細は省略します。ポイントは「 {{payload}} 」でHTTPリクエストのボディ部（つまりペイロード）にアクセスできる点です。 まとめ 内容は薄めですが、ここまで確認したことをまとめます。 リクエストヘッダには「 {{req.headers.<ヘッダ名>}} 」でアクセスできます headers配下に個別のヘッダに対応したプロパティがぶら下がります ペイロードには「 {{payload}} 」でアクセスできます まだまだ次回に続きます。

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回から何回かにわけてHTTP関連ノードを使ってみます。実はだいぶ前の記事「 Node-REDでWebサーバを作ってみる 」でHTTPノードのサンプル01は確認済みなので、残りのサンプルを見ていきます。 クエリパラメーターを扱う 最初に確認するサンプルは、「 読み込み > サンプル > flows > node-red > network > http > 02 - Handle query parameters 」です。クエリパラメータの扱い方を確認できます。 まず、上半分のフローです。エンドポイント「 http://localhost1880/hello-query 」にてHTTPのGETリクエストを待ち受けます。Templateノードでは「 {{req.query.name}} 」の形式でクエリ内の「 name 」パラメータにアクセスして、値をHTMLに埋め込んでHTTP responseを返しています。 続いて下半分のフローでは、上半分のフローで待ち受けているエンドポイントに対してHTTPリクエストを送信しています。リクエストではクエリパラメーター「 name 」に値「 Nick 」を指定しています。そして、HTTPレスポンスをDebugノードで出力しています。 フローを実行すると、以下のログが出力されます。さきほどの「 {{req.query.name}} 」が値「 Nick 」に置き換わっていますね。 URLパラメータを扱う 続いて、URLパラメータを扱う方法を確認します。確認するサンプルは、「 読み込み > サンプル > flows > node-red > network > http > 03 - Handle URL parameters 」です。さっきと似ていますが、今度はクエリストリングではなく、URLの一部をパラメータ化して扱っています。 さきほどのサンプルと同じく、上半分のフローはHTTPのリクエスト待受とレスポンスの構築を行っています。http inノードでは「 :name 」という形式で、URLの一部をパラメータ化しています。Rub

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はMQTTノードを使ってみます。私はMQTTについてはあまり詳しくなく、うっすらIoTの分野で使われていることを聞いたことがある程度です。まずはMQTTについて調べるところから開始しました。 MQTTの概要 Wikipedia によると、こんな感じの説明があります。 M essage Q ueuing T elemetry T ransportの略 TCP/IPによるPub/Sub型のデータ配信モデル 軽量な通信電文 メッセージブローカーが必要 Pub/Sub型と言えば、トポロジー的にはAWSで言うところのSNSみたいなもんですかね。軽量なのでスペックの低いIoT機器でも扱いやすいということなのでしょう。だいたい理解しました。 ブローカーのインストールと起動 Node-REDのドキュメントに 使い方の説明 があるので、実際にやってみます。ブローカーが必要なので、まずは mosquitto なるものをインストールおよび起動します。ちなみに、Mac上で作業しています。 $ brew install mosquitto $ mosquitto 1640008513: mosquitto version 2.0.14 starting 1640008513: Using default config. 1640008513: Starting in local only mode. Connections will only be possible from clients running on this machine. 1640008513: Create a configuration file which defines a listener to allow remote access. 1640008513: For more details see https://mosquitto.org/documentation/authentication-methods/ 1640008513: Opening ipv4 listen socket on port 1883. 1640008513: Opening ipv6

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はFilterノードを使ってみます。大量のメッセージを入力して、条件を満たした場合のみメッセージを出力するノードです。大量のデータを発生させる加速度センサーみたいなものを扱うのに使えそうです。 入力値が変化したら出力する Filterノードには標準のサンプルが提供されていないのでやむを得ず自作します。最初に作ったのはこんな感じのフローです。 Filterノードのプロパティは次のとおりです。 動作は「 値が変化したときのみメッセージを中継 」 対象プロパティは「 msg.payload 」 ここに2つのInjectノードでメッセージを流し込みます。 1つ目は、msg.payloadに「 aaa 」という文字列を設定したメッセージを1秒に1回繰り返し流す 2つ目は、msg.payloadに「 bbb 」という文字列を設定したメッセージを単発で流す デプロイすると、「 aaa 」のログが1回出力されます。msg.payloadの値が変化したのでメッセージが中継されたようです。その後、Injectノード「 bbb 」を実行すると、「 bbb 」のログと「 aaa 」のログが1件ずつ出力されます。Injectノード「 bbb 」を選択したことによりmsg.payloadの値が変化したのでメッセージが中継され、その後、Injectノード「 aaa 」の定期的な動作により再びmsg.payloadの値が変化したので中継されたようです。Filterノードのヘルプではこの設定のことを「 RBEモード（Report by Exception） 」と表現しているようです。 ちなみに、Filterノードの動作で「 値が変化したときのみメッセージを中継（初期値を無視） 」を選択すると、デプロイ時の「 aaa 」が出力されなくなります。フローリセット時に値が変化しないものとしてFilterノードの動作を抑制するのに利用できそうです。 入力値が指定した値を超えて変化したら出力する 続いて、入力値が指定した値を超えて変化したらメッセージを出力する動作を確認するために以下のようなフローを作成しました。 ポイントは以下の点です。 Filterノードの動作が「 最後の

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はExecノードです。Execノードを使うと外部のコマンドを実行することができます。コマンドが出力した、標準出力や標準エラー出力などをノードから出力できます。 標準出力の内容を出力する 最初に確認するサンプルは「 flows > node-red > function > exec > 01 - Get standard output from external command 」です。 Execノードのプロパティを見ると以下の通りになっています。 実行コマンドは「 echo 」 msg.payload で受け取った値を引数として利用 出力モードは「 コマンド終了時 - execモード 」 コマンド終了時に結果を出力します Execノードには出力ポートが3つあります。 標準出力 標準エラー出力 返却コード 実行すると、標準出力には「 Hello World! 」、返却コードには「 {code : 0} 」が出力されます。この挙動は特に説明することはないかと思います。 標準エラー出力の内容を出力する 次に確認するサンプルは「 flows > node-red > function > exec > 02 - Get error output from external command 」です。外部コマンドのエラーをポートに出力します。中身は先程のサンプルフローとほぼ同じですが、Execノードで存在しないコマンドを実行しています。 実行すると、以下のログが出力されます。これも説明不要かと思います。 実行中に出力する 最後に確認するサンプルは「 flows > node-red > function > exec > 03 - Run external command in spawn mode 」です。出力がコマンド実行中に行われるのがこれまでのサンプルと違う点です。 コマンドはwhieループ内で2秒おきに「 Hello 」を標準出力に出力し続けます。Spawnモードで実行するとループ内でechoコマンドが実行されるたびにログが出力されます。サービスっぽい挙動をす

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回からTriggerノードシリーズです。 メッセージが来なくなったら定期的にメッセージを送り続ける 見出しを読んだだけだとなんのこっちゃ？という感じではありますが、サンプルを見ていきます。確認するサンプルは「 flows > node-red > function > trigger > 03 - Send placeholder message when a stream stops sending 」です。 Triggerノードが2つあるのでそれぞれ確認していきます。まずは下流の「 resend every 2s 」から。内容を言葉で表現すると以下の通りです。 メッセージを受け取ったら、それ以降2秒間隔でmsg.payloadに「 0 」を設定したメッセージを出力する msg.payloadの値が「 reset 」だったら初期化（繰り返し動作を停止）する 続いて左側の「 trigger 2s 」。内容は以下のとおりです。 メッセージを受け取ったらmsg.payloadに文字列「 reset 」を設定したメッセージを送信する 2秒以内に新たなメッセージを受け取らなければmsg.payloadに「 true 」を設定したメッセージを送信する この2つのTriggerノードを組み合わせると、以下の挙動になります。 2秒以内にTriggerノード「 trigger 2s 」がメッセージを受け取っていればログ出力されません Injectノードを連打し続けると確認できます Triggerノード「 trigger 2s 」がメッセージを受け取らない時間が2秒以上あくとTriggerノード「 resend every 2s 」がメッセージを出力し続けます 常に動き続けていてほしいシステムが止まったら警告メッセージを出す、みたいな用途で使えそうです。 タイムアウト機構を実現する2 次に確認するサンプルは「 flows > node-red > function > trigger > 04 - Timeout processing using trigger node 」です。タイムアウト機構を実現

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回からTriggerノードシリーズです。 間隔を開けて2つの値を出力する 今回確認するサンプルは「 flows > node-red > function > trigger > 01 - Outputs two value with interval 」です。直訳すると間隔をあけて2つの値を出力するようです。Triggerノードのプロパティはこんな感じです。 最初にメッセージを受け取ったタイミングで送信データ「 1 」を出力した後、2秒待機して再送信データ「 0 」を出力するようです。遅延させるという意味では前回紹介したDelayノードと似ていますが、あるメッセージ受信をトリガとして、別のメッセージを送信できるのがこのノードの本質的な機能でしょうか。何に使うことを想定したノードかはわかりませんが、とりあえず挙動は確認できました。 タイムアウト機構を実現する 次に確認するサンプルは「 flows > node-red > function > trigger > 02 - Trigger a flow if a message is not received after defined time 」です。今度は、規定の時間メッセージを受信しなかったらトリガを発動させるパターンです。Triggerノードのプロパティを確認すると、赤枠の部分が先程のサンプルと違っています。 送信データ「 なし 」は最初にメッセージ受信時に出力しないことを意味しています。「 新たなメッセージを受け取った時に遅延を延長 」はメッセージを受信したら再送信データの送信を待機時間分（この例だと5秒間）遅らせることを意味しています。逆の見方をすれば、待機時間内にメッセージを受け取らなかったら再送信データを送信します。 整理すると、 Triggerノードはメッセージを受信すると5秒間待ちます 5秒以内にメッセージを受け取ったら何もしません 5秒を超えてメッセージを受け取らなかったらmsg.payloadに「timeout」の文字列を設定してメッセージを出力します 何か時間のかかる処理を実行して、指定した時間内にその処理が

ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回も 前回 に引き続きDelayノードを使ってみます。Delayノード編最終回です。 トピックごとに流量を制御する 今回確認するサンプルは「 flows > node-red > function > delay > 05 - Limit message rate for each topic 」です。トピックごとに流量を制御できるようです。 ざっと各ノードのプロパティを見てみたのですが、内容がよくわからなかったので、以下のようにDebugノードを追加・編集して各ノードが出力するmsgオブジェクトまるごと見てみます。 フローを実行すると瞬間的に10個ログ出力した後、2秒ほどタイムラグがあって、以下のように、topicの値が「apple」「orange」「banana」でそれぞれpayloadの値が「3」のログがまとめて出力されます。 ここでDelayノードのプロパティを確認してみます。動作は「 メッセージの流量制限 」「 msg.topic毎 」となっており、流量は「 2秒あたり1メッセージ 」、「 指定した時間後にキューにある全トピックのメッセージを出力 」となっています。 どうやら、topicごとに2秒あたり1メッセージの流量制限がかかり、各キューに溜まっているメッセージがまとめて出力されるようです。 一方、「 指定した時間後にキューにある先頭のトピックのメッセージを出力 」に変更すると、3つのログが2秒毎に出力されます。今度はまとめて出力するのではなく、流量制限がかかるようです。 まとめ 今回の内容をまとめます。 トピックごとに流量を制御できる