Node-REDの基本的なノード:MQTT,JSON,Websocket,TCP等


Node-RED: Lecture 3 – Basic nodes and flows

In this lecture you will get to see a few of the more commonly used nodes and build on some of the things you learnt in previous lectures. You’ll start off with a series of examples based around the popular MQTT protocol that shows how to wire together a set of basic but very useful message processing nodes. Then you’ll briefly look at other ways to get messages into and out of your flows using protocols such as TCP, UDP and websockets.

このレクチャーでは、いくつか一般的に使われるノードの紹介と、既に以前のレクチャーで紹介したものの詳細については触れていなかったものを再度取り上げます。まずはよく知られたMQTTプロトコルに基づいたサンプルから始めていきます。これによって、基本的な、しかしとても便利なメッセージ処理をするノードを、どのようにつなげていいかがわかるはずです。次に、メッセージを取り込んだり出力するための他の方法として、TCPやUDPやwebsocketといったプロトコルの扱い方もとりあげます。

At the end of this lecture you will have a better understanding of some of the basic nodes used in Node-Red flows. You will also have seen how easy it is to build sophisticated processing flows that take real-world events, process them and generate responses that use popular Internet protocols to communicate the results outside of your flow.

このレクチャーが終わる頃には、Node-REDフローに用いられる基本的なノードの理解ができることでしょう。また洗練された処理のためのフローが、如何に簡単につくれるかということも理解できるはずです。現実世界のイベントを取得して、それを処理し、返答を生成して、インターネット上の一般的なプロトコルを用いて、フローの外の世界と通信します。

We use a cloud hosted version of Node-RED for these lectures called FRED. Sign up for a free account at FRED. Examples in the early lectures will work with other installations of Node-RED, later lectures use nodes you will need to install yourself if you don’t use FRED.

例によってFREDを使っていきます。

Examples

Example 3.1 Receiving JSON via an MQTT message

Example 3.2 Using the switch node to handle a JSON object

Example 3.3 Using a change node to change or manipulate a message payload

Example 3.4 Using the rbe (report by exception) node

Example 3.5 Scaling input with the range node

Example 3.6 Using an mqtt output node to test the flow

Example 3.7 Using Websockets with Node-RED

Example 3.8 Sending TCP requests.

例3.1 MQTTメッセージを介してJSONを受け取る

Example 3.1 Receiving JSON via an MQTT message

The following series of examples builds on the mqtt node, which provides a convenient way to take input from an MQTT broker. For those not familiar with MQTT, it is an example of a publish/subscribe system (usually shortened to pub/sub system) which lets sensors publish updates that all delivered to client subscribed to that sensor. MQTT uses a topic model allowing publishers (eg sensors) to create topics and publish data to the topics Equally, others can subscribe to a topic and will receive asynchronous notification of data posted to the topic.

これから続く一連のサンプルは、MQTTノードを構築していきます。MQTTノードはMQTTブローカーからの入力を簡単に取得する方法を提供します。MQTTについてあまり馴染みのない人のために説明をすると(訳注:次の日本語の記事がわかりやすかったので参照)、これはpublish /subscribeシステムを持ち、sensorたちに更新をpublishさせ、そのsensorをsubscribeしているクライアントに、その情報を届ける仕組みです。MQTTはトピックモデルによって運用され、パブリッシャー(sensor)にトピックをたて、トピックをpublishし、パブリッシャー以外はそのトピックをsubscribeして、そのトピックへポストされたデータを非同期に受け取ります。(訳注:ちょっと翻訳変ですけど、pulishとかtopicとかはもうそのまま用語を理解したほうが早いと思うので、そのままで)

Pub/Sub systems are a great way to connect loosely coupled distributed systems and they map well to typical IoT patterns where devices or things generate events that you want to share. The MQTT protocol, apart from being asynchronous, is also lightweight and doesn’t have as high an overhead as HTTP; which for resource-constrained devices is often an important advantage. MQTT was originally developed in the late 1990s and has been used in a variety of IoT settings. MQTT became an OASIS standard in 2014 and is a standard part of many IoT toolboxes. MQTT actually stands for Message Queueing Telemetry Transport.

Pub/Subシステムは、ゆるく連結した分散型のシステムをつなぐためにとてもいい方法です。またこのシステムは典型的なIoTで用いられるパターンにマッチしていて、デバイスやThingsがイベントを生成し、それを他のデバイスやThingsと共有するような場合に向いています。MQTTプロトコルは、非同期であることを除けば、軽量で、HTTPよりも負荷が低いです。これは、リソースが限られたデバイスにとっては、重要な利点です。MTQQは元々1990年代後半に開発され、それ以来様々なIoTにおいて使われてきました。MQTTはOASISとして2014年に標準化され、IoTで使用される規格としては標準的なものとなっています。MQTTはMessage Queueing Telemetry Transportの略記です。

To use the mqtt node, you need to have access to a broker. There are a number of free MQTT servers running, for example http://test.mosquitto.org/, or the one that will be used in this lecture, www.hivemq.com. Using the broker address and the topic, you can configure the mqtt input node to subscribe on that topic, causing it to generate a new message whenever new data is published on that topic. The message will contain information on the published data, including the data itself in msg.payload and the MQTT broker topic in msg.topic.

MQTTノードを使うためには、Brokerにアクセスする必要があります。フリーのMQTTサーバーがいくつもあり、たとえばhttp://test.mosquitto.org/や、このレクチャーで使うwww.hivemq.comなどがあります。Brokerアドレスと、topicを使うことで、MQTTインプットノードを、そのトピックをサブスクライブし、そのトピックでpublishがされた際に、新しいメッセージを生成させることにしましょう。そのmessageはpublishされたデータに関する情報を含み、データはmsg.playloadに、MQTTブローカーのtopicはmsg.topicに含まれています。

To get you started with the mqtt node, you’ll be using the free mqqt broker hivemq – which is available via (http://www.hivemq.com/showcase/public-mqtt-broker/). Of course you can use any MQTT broker, including your own, if you have installed one.

MQTTノードを使うために、MQTTブローカーであるhivemqを使います。もちろん他のどのMQTTブローカーを使うこともできます。例えば自分でインストールしたサーバーを使うこともできます。

First, drag and drop an mqtt input node and configure it for the broker. Don’t forget to configure the topic to something unique, in the case of this example we are using noderedlecture/sensor but you should use your own unique topic, i.e. <your name here>/sensor

まずはいつも通りMQTTインプットノードをドラッグ・アンド・ドロップでは位置して、設定画面からborkerのための情報を入力しましょう。大事なことは他の人とかぶらないtopic名を設定することです。例えばこの例ではnoderedlecture/sensorというトピックたて使用していますが、あなたはそれとは違う名前のトピックを建てるようにしてください。例えば 自分の名前/sensorとか、ですね。

(訳注:よくわからないが、とにかくトピックと、サーバーだけ同じにしておけば、受信できる模様。ポートとかクライアントIDは異なっていても受信できる。)

Figure 3.1 Configuring the mqtt node with broker address and topic

 

There are many ways you can send mqtt messages to hivemq. You can use their websockets client showcase (http://www.hivemq.com/demos/websocket-client/), the mqtt dashboard (http://www.mqtt-dashboard.com/dashboard) or your own library. You’ll be using their websocket client in this example, so navigate to that page and connect to the broker. You will publish a JSON encoded string to the topic you configured to see both the use of the mqtt node and the json node.

MQTTメッセージをhivemqに送る方法はたくさんあります。上の2つのリンクは、公式が提供しているものでこれを使うこともできますし、自分でライブラリをつくってもいいでしょう。このサンプルでは、上記のリンクのうち、最初のもの、WebSokcetクライアントをつかっていくことにします。

Figure 3.2 Sending an MQTT message (publishing) using the HiveMQ client page.

Since you are sending a JSON string, you will need to parse the message that the mqtt node generates when it receives the MQTT message. To do that, you’ll need to drag and drop a json node and connect it to the mqtt node’s output.

ここではJSON形式の文字列を送っているので、MQTTノードが受け取って、そして生成したメッセージをパースする必要があります。そのためにJSONノードを配置し、MQTTノードのアウトプットをこれに入力します。

Node-RED’s json node is a sort of convenience function, in that it parses the incoming message and tries to convert it to/from JSON. So if you send it a JSON string, it will convert it to a JavaScript object, and vice versa.

Node-REDのJSONノードは、JSONを変換してJSオブジェクトに変換してくれますし、またその反対もできます。

If you wire up the usual debug node to the json node and deploy, then use the HiveMQ dashboard to send the JSON string {“analyze”:false, “value”:10} as shown in Fig 3.2. You will see it printing in the debug tab (Fig 3.3).

結線して、debugノードをつかってみましょう。ディプロイした後にHiveMQダッシュボードを使ってJSON文字列を送りましょう。するとdebug窓で確認できます。

 

Figure 3.3 Receiving and parsing an MQTT message sent as a JSON string

If you look closely at the output, you can see that the msg.payload contains an object, which itself has two fields, analyze and value, each with their own values. As you saw in lecture 2, you can access these fields via msg.payload.analyze and msg.payload.value. Let’s take a look at a node that can do that.

Outputの内容をより詳細にみてみると、msg.payloadはオブジェクトをもっていることがわかります。そのオブジェクトは、2つのフィールドを持ち、1つはanalyzeでもう一つはvalueで、それぞれそのフィールドに対応する値を持っています。レクチャー2でみたように、これらのフィールドにmsg.payload.analyzeでアクセスすることができます。やってみましょう。

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-1_mqqtmessages.json

例3.2 スイッチノードを使って、JSONオブジェクトを扱う

Example 3.2 Using the switch node to handle a JSON object

One of the nice features of having a JSON object is that you can easily act on its properties. A useful node for this is the switch node. Its role is to ‘switch’ or route messages depending on the incoming message properties.  For example, you can check the msg.payload.analyze property and, depending on its value (true/false), decide to route a message to one of the switch node’s outputs.

JSONオブジェクトをもちいる利点の一つは、そのプロパティに簡単にアクセスできることです。そのために便利なのは、Switchノードです。このノードは、入力されたメッセージのプロパティの値によって、スイッチングし、その経路にメッセージを送ります。例えば、msg.payload.analyzeプロパティをチェックして、その値によって(tureかfalse)switchノードのいずれかのアウトプットにメッセージを送ります。

Drag a switch node and double-click on it. Configure it to evaluate the property “msg.payload.analyze”. If true, send the message to the first output; if false, send it to the second output as shown in in Fig 3.4.

switchノードをいつも通りドラッグ・アンド・ドロップして配置して、ダブルクリックして設定画面に入りましょう。そしてmsg.payload.analyzeプロパティを評価するように設定します。もしこの値がtrueであれば1st Outputに出力します。falseだった場合には、2nd Outputから出力します。

Figure 3.4 Configuring the switch node to route based on a message property

Now you can connect two debug nodes as shown in Fig 3.5 – when you set up multiple outputs for a node, they are numbered from the top, so output 1 is the top output and output 2 is at the bottom in  Fig. 3.5.

次の図では2つのdebugノードにswitchノードのアウトプットをつなぎました。switchノードに複数のアウトプットを設定した場合には、上から順番にアウトプットの番号がつけられます。ですからFig.3.5ではoutput1が一番上にあって、その下にあるのがoutput2です。

 

Figure 3.5 Connecting a switch node to two debug nodes

If you now go back to the HiveMQ input page and send the MQTT message {“analyze”:true, “value”:6}, you will see that the first (top) output is activated and the incoming messages is routed, or ‘switched’, to output 1. If you send the original message {“analyze”:false, “value”:10}, the switch node will activate output 2 and the original debug node will fire. Hovering the pointer over the debug message will show which debug node is printing out the message as shown in Fig. 3.6.

さきほど作成したHiveMQを受け取るフローを少し修正してSwitchノードを使ってみましょう。MQTTメッセージの内容が{“analyze”:true, “value”:6}の場合には、1st Outputが有効になり、ここに入力されたメッセージが出力されます。反対に、{“analyze”:false, “value”:10}を送った場合にはOutput2が有効になり、下のデバグノードがメッセージを受け取ります。デバグ窓でデバグメッセージにマウスを重ねると、どのデバグノードがメッセージを出力されたかを示してくれます。

Figure 3.6 Confirming the operation of the switch node

As you can see, this provides you with a built-in Node-RED node that allows you to quickly determine the contents of incoming messages and direct the message through to different parts of the flow depending on the input.

このノードを使えば、入力されたメッセージの値に基づいて、フローの異なる場所へメッセージを流していくことができます。

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-2_switchnode.json

例3.3 Chageノードを使って、メッセージを変更する。もしくは単にメッセージを扱う。

Example 3.3 Using a change node to change or manipulate a message payload

Another useful node is the change node, which will allow you to change a message payload or add new properties. You can use this node to affect the properties in a message, either by changing existing ones, deleting them or adding new properties.

どんどん便利なノードを紹介していきましょう。今回はChangeノードです。これをつかえばmessageのpayloadを変更したり、新しいプロパティを追加することができます。既にあるプロパティを変更したり、削除したり、加えたりすることができます。

In this example, you’ll continue with your MQTT theme and see how, now that you have successfully ‘switched’ the message flow based on the incoming MQTT message, you can add a new message property msg.payload.note.

次の例はさきほどから使用しているMQTTフローをそのまま使用、追加していきます。これは入力されたメッセージによってスイッチするものでしたが、さらにこれに新しいmessageプロパティであるmsg.payload.noteを追加することにしましょう。

First, let’s drag and drop a change node and connect it to the second output of the switch node (Fig 3.7). As you will remember, this is the output that fires when msg.payload.analyze is set to false.

Changeノードをドラッグ・アンド・ドロップして追加し、switchノードの2nd Outputに接続してください。このアウトプットには、msg.payload.analyzeがfalseのときにだけ、メッセージが届きますね。

Figure 3.7 Adding in a change node to set a new message property.

 

Now configure it to set the property msg.payload.note to “this is not being analyzed” as shown in Fig 3.8.

では設定していきましょう。msg.payload.noteプロパティを“this is not being analyzed”に設定します

 

Figure 3.8 Using a change node to add a new message property

 

When you receive a message that the switch node sends on the 2nd output, it will be modified to contain a “note” element with the string “this is not being analyzed”. If you deploy and test the flow by sending the MQTT message from HiveMQ, you’ll see the output as shown in Fig 3.9.

メッセージを受け取ってその内容がswitchノードのoutput2に出力されるものであれば、メッセージは変更されて、noteエレメントを持ち、内容が“this is not being analyzed”という文字列のものが追加されます。

 

Figure 3.9 The result of switching and then changing the message

 

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-3_changenode.json

例3.4 rbe (report by exception-例外報告?)を使う

Example 3.4 Using the rbe (report by exception) node

In this example, you’ll continue your message analysis theme and add nodes to the part of the flow that is used when you determine that the flow should be analyzed. You’ll be using the rbe (report by exception) node which only passes on data if it has changed. You can set it to examine a message payload and either block until a message changes (rbe mode) or when a messages changes by a specified amount (deadband mode). In rbe mode, it works on numbers and strings. In deadband mode, it works on numbers only and uses the configured deadband as a + or – ‘band’, so that the incoming value can fluctuate within a range before it fires.

次の例でも引き続き、さきほどのものを使っていきます。今回追加するのはRBEノードで、これを使うことで値が変更されたときだけ、メッセージを通すことができます。messageのpayloadを検査して、メッセージが変更されるまでブロックしたり(rbaモード)、メッセージの変更が特定の範囲の間にだけ機能するようにすることができます。(deadbandモード) rbaモードでは、数字に対しても文字列に対しても動作します。deadbandモードにおいては、数字にたいして動作し、その値の範囲設定は、最後に発火したときの値から、どれくらいの範囲なのかで指定することができます。

You’ll start by adding in another change node which you’ll connect to output 1 of the switch node. You’ll then connect an rbe node to the switch node as shown in Fig 3.10.

下の図のようにつないでください。

Let’s connect a change node, and an rbe node like this. To remind us that this output deals with the flag “analyze”, add a comment node and write “Analyze = true”. Comments are useful when writing complex flows.

コメントノードを使うと、複雑なものに対して説明がつけられるので便利です。

Figure 3.10 Adding an rbe node to check if our input data has changed by more than 20%

Edit the change node to set the msg.payload to msg.payload.value. This will set the output of this node to the value found in the msg.payload.value element of the input received (Fig 3.11).

changeノードを変更して、msg.payloadに対してmsg.payload.valueを与えるようにしましょう。こうすることで、このノードのoutputを、インプットから受け取ったmsg.payload.valueの値に変更することになります。

Figure 3.11 Using a change node to set payload

Since you want to determine if this value has changed by 20% or more, you’ll need to double-click on the rbe node and configure it to block unless the value changes by more than 20%.

値の変化が20%以上のときにだけ反応するように設定しましょう。20%以上の変更がない場合には、ブロックする、という設定にします。

Fig 3.12 Setting the rbe node to check msg.payload.value

To test the flow, deploy this flow and then return to the HiveMQ page and send a series of messages. Firstly, you’ll need to set the analyze value to true so that the switch node sends through a message on output 1. If you use the original message value of 6, this will fail to pass the rbe node. If you then send a second message of value 10, the rbe node will evaluate the difference between 6 and 10, see it is greater than 20%, and send on a message to the final debug node which will print on the debug pane as shown in Fig 3.13.

ではHiveMQのページにいってメッセージを送り、このフローをテストしてみましょう。まず最初に、送るメッセージのanalyzeプロパティの値をtrueにし、スイッチノードがOutput1にスイッチするようにしましょう。最初にvalue:6をおくると、rbeノードを通りません。次に、value:10を送ると、rbeノードは先程の6と今回の10の差を比較して、それが20%以上あれば、debugノードへと値を送ります。そしてその値がdebug窓に表示されます。

Fig 3.13 Confirming that 10 is more than 20% larger than 6 using an rbe node.

 

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-4_rbenode.json

例3.5 インプットを特定の範囲にスケーリングするnode

Example 3.5 Scaling input with the range node

When dealing with real world input from sensors and other devices, an ability to scale input data is often required. Node-RED provides the scale node to support this and allows you to scale (linearly) an input value. Let’s assume you want to scale your value (originally in the range 0-10) to a range (0-255) when you aren’t doing any analysis. This means we are dealing with the lower part of the flow fired when the switch node evaluates the Analyze property as false.

実世界の入力を、例えばセンサーといったデバイスから受け取って処理する場合には、インプットされたデータをスケーリングする機能はよく必要になります。Node-REDはscaleノードを提供し、これをサポートしています。仮に0〜10の値を0から255の値にしたいが、自分ではわざわざ分析をしたくはない、という状況があるとしましょう。今回は、analyzeプロパティがfalseの時に発火する、フローの下側の部分を扱います。

To do this, select the change node you configured above (set msg.payload) and copy it with ctrl+c, then ctrl+v. Attach a range node as shown in Fig 3.14.

次のように変更してください。コピペコマンドも普通に使えます。

 

 

Figure 3.14 Scaling input values using the range node.

Double-click on it, and configure it to map the input from 0-10 to 0-255 as shown in Fig 3.15.

Rangeノードをダブルクリックして編集していきましょう。inputを0-10の範囲を0-255に対応するようにアウトプットします。

The scale node has three options set by the action field. The default will scale according to the mapping given but will happily scale values outside the given ranges, using the same mapping. Scale and limit to target range means that the result will never be outside the range specified within the result range. A third option, Scale and wrap within the target range means that the result will essentially be a “modulo-style” wrap-around within the result range.

スケールノードには3つのオプションがあります。デフォルトでは、与えられたマッピング範囲によってスケーリングをするのですが、その際に、与えられた範囲外の値も同じように処理をします。Scale and limit to target rangeは同じようにスケーリングをするのですが、その出力結果は、result rangeからは決して外れません。3つめのScale and wrap within the target rangeは、数学の「割り算の余り」スタイルで、result レンジの中で折り返します。

Then return to the HiveMQ test page and post {“analyze”:false, “value”:10} as a new MQTT message to the same topic.

ではHiveMQのテストページにいって、 {“analyze”:false, “value”:10}と新しいメッセージを、さきほどと同じトピックにポストしましょう。

Figure 3.15 Setting the scaling ranges for input and output of the scale node

If you return to your Node-RED window, you will see that the debug node associated with the lower part of the flow has fired, showing that the msg.payload.value property that you set as 10 when you published it to MQTT, has been scaled up 255 as shown in Fig 3.16.

ではNode-REDウィンドウに戻って、フローの下側と関連付けられたdebugノードが発火し、msg.payload.valueプロパティが示されていますね。MQTTで10の値をパブリッシュしたわけですが、これがスケーリングされて255という値になっています。

Figure 3.16 Final scaled output when analysis is turned off

 

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-5_rangenode.json

MQTTアウトプットノードを使って、フローをテストする

Example 3.6 Using an mqtt output node to test the flow

As an alternative to using the HiveMQ test page to publish on the MQTT topic, we can configure an mqtt output node. This is the mirror of the mqtt input node and allows you to configure an MQTT service and the topic you are publishing on. You can then send the node messages with the exact same JSON string we’ve been sending via the HiveMQ test page.

HiveMQのテストページを使ってMQTTトピックを発行する以外に、MQTTアウトプットノードを使う方法もあります。これはMQTTインプットノードとついになるもので、MQTTサービスを使う設定をし、そこで発行するトピックの設定もします。これによって今までHiveMQテストページで送信してきたようなJSON文字列のメッセージを送信することができます。

To try that, drag and drop three inject nodes and an mqtt output node as shown in Fig 3.17, and configure and wire up as shown

やってみましょう。

Figure 3.17 using an mqtt node to publish on the noderedlecture/sensor topic

You can now test the flow you created to analyze the MQTT message directly from the workspace by clicking on the three inject nodes in sequence. The first will exercise the part of the flow handling the case when analysis is turned off; the 2nd two messages will cause the path with the rbe node to be exercised.

インジェクトノードの左側のボタンをおしてMQTTメッセージを送信し、テストしてみましょう。

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-6_mqqtout.json

訳注:細かい設定方法が書いてなかったので、自分が設定したものを画像でのせます。

まずはinjectノードで文字列をフローに挿入します。Json形式で記録。

次にMQTT アウトノードの設定です。サーバーを先程受信していたものと同じにしました。トピックも。

MQTTインプットは、アウトプットと同じにします。当然トピックも同じにします。

例3.7 ウェブソケットをNode-REDで使う

上手く行かなかったので、パス。

Example 3.7 Using Websockets with Node-RED

Websockets are another useful communication capability that is built into Node-RED via the the websocket node. Websockets provide a duplex TCP connection and were designed to allow web browsers and servers to maintain a ‘backchannel’ that could be used to augment traditional HTTP interactions, allowing servers to update web pages without the client making a new pull request.

Websocketも便利なコミュニケーションのために使える機能で、Node-REDではwebsocketノードを使って実装できます。Websocketは双方向通信可能なTCP接続で、ウェブブラウザとサーバが?

The websocket node comes in two flavours, input and output, allowing you to listen for incoming data (input) or to send (output) on a websocket. The output version is designed to check to see if the output payload originated at a websocket in a node, in which case it responds to the original sender. Otherwise it will broadcast the payload to all connected websockets.

Websocketノードは、inputとoutputの二種類があり、ウェブソケットの入力をまったり、送信したりすることができます。Outputのほうは、?

In addition, both input and output websocket nodes can be configured as either server or client – in server mode they ‘listen on’ a URL, and in client mode they connect to a specified IP address.

To see how the websocket nodes work, you’ll use a public websockets echo server which runs on the public site: (https://www.websocket.org/echo.html).

Drag an inject, websocket in, websocket out and a debug node onto the workspace and connect them as shown in figure 3.18.

Figure 3.18 using websockets to communicate with a Node-RED flow

Configure the inject node to send a string payload of “Hello There” (Fig 3.19)

Figure 3.19 Configuring an inject node to send on a websocket

Configure the websocket nodes to connect to wss://echo.websocket.org as shown in Fig 3.20.

Figure 3.20 Configuring the websocket to send to a public echo server. Do the same for the websocket out node.

Deploy. When you click on the inject node you will see the message printed out as shown in Fig 3.21

 

Figure 3.21 Output from a websocket listening for incoming data

 

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-7_websockets.json

Example 3.8 Sending TCP requests.

TCP 接続をする。読めばわかる!

This example shows you how to send TCP requests using the tcp node. In this case you will make an HTTP request following the specifications in (http://tools.ietf.org/html/rfc2616#section-5.1.2).

This example shows the use of the tcp node. It could equally be configured with the udp or http nodes in a similar manner.

 

To get started, let’s connect an inject, function, tcp request, and debug nodes as shown in Fig 3.22.

Figure 3.22 building a TCP request and sending on a tcp output node

Edit the first function node to add a function that sets the string “GET / HTTP/1.1\r\n\r\nHost: www.google.com” as payload as shown in Fig 3.23.

This string is a standard HTTP request, indicating it is a GET request, the protocol is HTTP 1.1 and the host is www.google.com. The \r\n\r\n is two return/newline pairs which is required in the HTTP protocol.

Figure 3.23 Building a TCP request in a function node

Configure the tcp request node to connect to the www.google.com server, on port 80. Configure it to close the connection after 1 second (1000 ms) as shown in Fig 3.24.

Figure 3.24 Configuring the end-point for a TCP request

The tcp request node response is a buffer and needs to be parsed. Configure the second function node to parse the tcp request node response as shown in Fig 3.25

Figure 3.25. A function node to parse a response buffer into a string

If you deploy the flow and click on inject, you will make a request to Google and will get a TCP response. The debug node will print the response as a string as shown in Fig 3.26.

Figure 3.26 Printing out the response to a well formed HTTP request sent over a TCP connection.

Some of you may be wondering why you need to use a function node to build the HTTP request that we sent over TCP. Why not just use the inject node to input the string? The reason is that the inject node ‘escapes’ the string it uses, causing the return/newline you inserted to be removed. This in turn confuses the receiving server (Google) into not returning a response as it waits for the missing return/newlines. So instead, you build the string in a function node. This is one of those ‘gotchas’ that trips up even experienced Node-RED programmers, so always read the info pane for nodes to make sure you understand any limitations or constraints.

 

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-8_tcp.json

Summary

In this lecture you have seen a series of small examples that use a number of the processing and communication nodes that are available in Node-RED. As you have seen, it is both easy and fast to wire together basic flows that take real-world input, carry out some processing, such as simple data analysis, and return results.

In these examples, you have done little or no coding, but still have been able to build quite complex programs – this is the power of Node-RED.

The next lecture is a quick summary of the basic set of nodes that are available in both vanilla Node-RED as well as the extended set that the FRED service provides. You can read through the lecture to understand the default capabilities, or you can treat the lecture as a reference and use it to look up examples of each node as used in this lecture series

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です