Node-RED: Lecture 4 – A tour of the core nodes

This lecture will take a look at the core set of nodes that Node-RED installs by default and then show you the extended set of nodes that the cloud-based Node-RED service – FRED – supports.

This lecture will take a look at the core set of nodes that Node-RED installs by default and then show you the extended set of nodes that the cloud-based Node-RED service – FRED – supports.

For each node, you’ll see a brief overview of its functionality and an indication of which example in this lecture series uses the node, so you can look in more detail at how to work with the node. This lecture is mostly a reference section. However, it is worth looking quickly through the nodes, so that you have an idea of the basic functionality available to you as you begin to craft your own flows.

Node-RED’s default set of nodes

When you install Node-RED for yourself on a device such as a Raspberry Pi or Beagleboard, it starts up with a default set of nodes. There are 8 main categories of nodes in the default install: inputs, outputs, functions, social, storage, analysis, advanced and Raspberry Pi (See Figs 4.1 and 4.2) Let’s take a look at each category in turn.

 

Figure 4.1 The default input, output, function and social media nodes.

Input nodes

There are 7 basic input nodes installed by default. They cover the basic communications mechanisms that IoT applications are likely to use. Ranging from lower-level internet protocols such as UDP and TCP through to the higher-level HTTP and the publish/subscribe MQTT.

Node name Description Examples
inject Injects a timestamp or user-configured text into a message. Can be configured to inject manually, at a set interval, or at specific times (using Cron). Examples 2.1, 3.6, 3.7, 3.8, 5.1-5.4, 6.1-6.8
catch Catches errors thrown by nodes on the same tab. If a node throws an error whilst handling a message, the flow will typically halt. This node can be used to catch those errors returning a message with an error property detailing the error and the source node and type. Examples
mqtt Subscribes to an MQTT broker and listens on a topic, returns any data published on the topic as a new message. Supports Quality of Service levels and last data retention. Examples 3.1-3.5
http Receives HTTP requests, allowing Node-RED to act as a basic web server. HTTP body is delivered as an output message along with any response. Message can contain standard URL-encoded data or JSON. Example 1.3, 5.7
websocket Provides an endpoint for a browser to establish a websocket connection with Node-RED. Offers a duplex connection for browser/server combinations. Example 3.7
tcp Used to accept incoming TCP requests on a specified port or to connect to a remote TCP port. Generates messages containing the TCP data as a single – or stream of – buffer, string or base64 encoded. Examples lecture 7
udp Used to accept incoming UDP packets (or multicast packets) on a specified port. Generates messages containing the UDP data as a BUFFER, string or base64 encoded string. Examples lecture 7
serial in Reads from a serial port on the local device. Can be configured to read buffers, a specific time period or wait for line breaks. Examples lecture 7

Output nodes

The output nodes are essentially the mirror images of the basic set of input nodes and provide a way to send data on the same set of protocols, i.e. mqtt, http, udp etc.

Node name Description Examples
debug Provides a simple way to view messages which are displayed in the debug pane. Can be configured to display just the msg.payload or the entire msg object. Various, examples 2.1, 2.2, 3.1-3.6, 5.1-5.4, 6.1-6.5
mqtt Subscribes to an MQTT broker and posts any data (msg.payload) it receives in incoming messages to a topic. Supports Quality of Service levels and last data retention. Example 3.6
http Sends responses back to HTTP requests received from a HTTP Input node. The response body is determined by msg.payload, and can have headers and status code defined. Examples
websocket Sends msg.payload out on the websocket configured. If msg._session is defined, sends to the origination client, otherwise broadcasts to all connected clients Example 3.7
tcp Replies to a configured TCP port. Can also be used to send to a specific port. Example 3.8
udp Sends a UDP message to the configured host (ip address) and port. Supports broadcast. Like most nodes, configured through UI or message properties. Examples
serial out Sends to the defined serial port. Can be configured to send an optional newline after any message payload. Examples lecture 7

 

Function nodes

The function category contains a variety of nodes that carry out specific processing functions. These range from the simple delay and switch nodes to the programmable function node that can be adapted to almost any programming need.

Node name Description Examples
function Generic programmable function node. Using standard JavaScript, the node can be tailored to carry out complex processing on its input messages generating one or more output messages. Examples 2.1, 2.2, 3.8, 5.1-5.4, 5.7, 6.1-6.8
template Configured with a template (using moustache format) of arbitrary complexity, this node takes an input message containing name:value pairs and inserts into the template. Useful for constructing messages, HTML, config files, etc. Example 1.3
delay A generic node that delays messages by a specific or random time. Can also be configured to throttle a message flow (e.g. 10 msg per sec). Examples 5.6, 6.8
trigger Creates two output messages separated by a configurable time interval whenever an input message is received. Can also be used as a watchdog timer. Example 1.1
comment A simple visual comment configured with title and body. Example 2.1
http request Allows you to construct and send a HTTP request to a specific URL. Method (PUT, GET, etc), headers and payload are all configurable through the UI or programmatically. Examples 1.3, 6.1, 6.6
tcp request A simple TCP request node. It sends the msg.payload to a server tcp port and expects a response. Can be configured to wait for data, wait for a specific character, or return immediately. Example 3.8
switch This node routes messages based on their properties. Properties are configured using the UI and can be a variety of logic (>, <, >= etc) applied to a message property. Examples 3.2-3.5, 5.5
change The change node can be used to set, change or delete properties of incoming messages. A variety of configurable rules allow complex changes including search and replace in the msg.payload Examples  3.3-3.5

 

range A simple scaling node that will map numerical input to a new output. Useful for converting or bounding ranges of input values, e.g. temperature. Undefined for non-numeric data. Example 3.5

 

Node name Description Examples
csv This node parses msg.payload and tries to convert to/from CSV. If it receives a string, it outputs a JavaScript object, and if it receives a JavaScript object, it outputs a CSV string. Examples
html Extracts elements from an html document in msg.payload using a configurable selector (CSS selector syntax). Essentially allows you to parse out the HTML and returns an array of the elements that match. Example 6.1
json This node converts to/from a JSON object. If it receives a JavaScript object, it outputs JSON, and if it receives JSON, it outputs a JavaScript object. Examples 3.1-3.5, 5.7, 6.6
xml This node converts to/from XML format. If it receives a JavaScript object, it outputs an XML string, and if it receives an XML string, it outputs a JavaScript object. Examples
rbe Report By Exception node. Generates a message only when its input is different from the previous input (string or number) or if the input has changed by a configurable amount (deadband mode) – only for numbers. Example 3.4

Social nodes

The basic social media nodes support interaction with email and with Twitter. They enable flows to send or receive email, or to send or receives tweets.

Node name Description Examples
email in Can be configured to repeatedly read from an IMAP server returning new email as it arrives. Sets msg.topic to email subject and either msg.payload to email text body or msg.html if the email is HTML. Example
twitter in Returns tweets as messages. Can be used to search the public or a user’s stream for tweets containing the configured search term or all tweets by specific users or direct messages received by the authenticated user. Example 1.1
email out Sends the incoming message as an email via the configured IMAP server. Topic and recipient all configurable. Will convert binary data to an attachment. Example 1.2
twitter out Tweets the msg.payload on the configured account. Can send direct messages and will send binary data as an image. Example 2.2

 

Storage nodes

The default node set for storage, because it is targeted at devices such as the Raspberry Pi are quite limited and focus on file based storage.

Figure 4.2 The default storage, analysis, advanced and Raspberry Pi nodes.

 

You should note that FRED, because it’s a cloud service, doesn’t support the basic file nodes. Instead it replaces these with a variety of storage nodes ranging from Mongo to Dropbox. However, for completeness the default nodes are covered here, so that you can use them, if you install Node-RED yourself (see lecture 7).

Node name Description Examples
tail Tails (i.e. watches for things to be added) to the configured file. (Linux/Mac ONLY)

This won’t work on Windows file systems, as it relies on the tail -F command.

Examples
file in Reads the specified file and sends the content as msg.payload, and the filename as msg.filename.

The filename can be configured in the node. If left blank, it should be set on msg.filename in an incoming message.

Examples
file Writes msg.payload to the file specified, e.g. to create a log. The filename can be configured in the node. If left blank, it should be set on msg.filename in an incoming message.  The default behaviour is to append to the file. This can be changed to overwrite the file each time; for example, if you want to output a “static” web page or report. Examples

Analysis nodes

Analysis nodes perform standard analyses on incoming messages. In the default node set, the only node provided is the sentiment node, which can be used to try and determine the sentiment of an incoming message based on the words used in the message, for example, an email or tweet.

Node name Description Examples
sentiment The sentiment node analyses the msg.payload and scores the sentiment of the message based on word analysis. It adds a msg.sentiment object that contains the resulting AFINN-111 sentiment score as msg.sentiment.score. Score typically ranges from -5 to +5. Example 5.5

Advanced nodes

A set of miscellaneous nodes offering various types of functionality.

Node name Description Examples
watch Watches a directory or file for changes. You can enter a list of comma-separated directories and/or files. You will need to put quotes “…” around any that contain spaces. On Windows, you must use double backslashes \\ in all directory names.

The full filename of the file that actually changed is put into msg.payload, while a stringified version of the watch list is returned in msg.topic.

msg.file contains just the short filename of the file that changed. msg.type has the type changed, usually file or directory, while msg.size holds the file size in bytes.

Examples
feedparse This node monitors an RSS/atom feed for new entries and delivers new entries as messages. It can be configured to query the feed at a specific interval. Examples
exec Calls out to a system command and provides 3 outputs: stdout, stderr, and return code. By default uses exec(), which calls the command, blocks while waiting for completion, and then returns the complete result in one go, along with any errors. Examples

 

Raspberry Pi nodes

Node name Description Examples
rpi_gpio in Raspberry Pi input node. Generates a msg.payload with either a 0 or 1, depending on the state of the input pin. You may also enable the input pullup resistor or the pulldown resistor.

The msg.topic is set to pi/{the pin number}

Requires the RPi.GPIO python library version 0.5.8 (or better) in order to work.

Note: we are using the actual physical pin numbers on connector P1 as they are easier to locate.

Examples lecture 7
rpi_gpio out Raspberry Pi output node. Expects a msg.payload with either a 0 or 1 (or true or false). Will set the selected physical pin high or low, depending on the value passed in. The initial value of the pin at deploy time can also be set to 0 or 1. When using PWM mode, expects an input value of a number 0 – 100.

Requires the RPi.GPIO Python library version 0.5.8 (or better) in order to work.

Examples 1.1, lecture 7
rpi_mouse Raspberry Pi mouse button node. Generates a msg.payload with either a 1 or 0 when the selected mouse button is pressed and released. Also sets msg.button to the code value, 1 = left, 2 = right, 4 = middle, so you can work out which button or combination was pressed. Examples lecture 7

 

The extended FRED node set

The FRED service adds a number of nodes to the standard default set. These new nodes, which have either been written for FRED or collected from the public repository, have been added, as they offer useful functionality that expands the capabilities of the vanilla node set.

Note: these nodes are available in FRED by installing them using the FRED installation panel. For a quick example of how to install nodes check out this tutorial.

As you will see, the majority of these additional nodes focus on services and capabilities that match well with FRED’s nature, i.e. a cloud-based service. In many cases they focus on using Node-RED for web based integration or to access enterprise level services.

Screen Shot 2015-10-09 at 3.03.41 PM.png

 

Figure 4.3 The extended FRED nodes

 

Extended set of social media nodes

As you can see, the FRED service adds a large number of social media nodes ranging from Pushbullet to Slackbot to Instagram.

Node name Description Examples
pushbullet in Connects to the popular Pushbullet service and receives Pushbullet data items from all your connected devices. Supports data, links and files. Examples
pushbullet out Allows you to send Pushbullet messages to all devices that have the Pushbullet app installed. Examples
XMPP in Receives messages from an XMPP instant messaging server. The buddy field indicates the buddy or room you are receiving from. Presence information is delivered on a second output link. Examples
XMPP out Sends messages to an XMPP instant messaging server. Uses topics to send to rooms (channels) and supports presence notification. Examples
slack A general node that provides a simple way to post on a slack channel specified via its webhook URL.  Can be configured with user name, emoji and to support attachments. Examples
slackbot in A node to use a bot you’ve created on Slack and provides a listener in any channel of which the Slack bot is a member. Outputs the msg.payload as the incoming message. and outputs msg.SlackObj with full Slack message details. Examples 5.7
slackbot out A node to use a bot you’ve created on Slack Sends the msg.payload to Slack based on the Bot API token provided. You can optionally override the destination channel if required – either in the edit dialogue or by setting msg.channel. Examples 5.7
delicious A node to save bookmarks to your Delicious account. The payload should contain the URL to save, and msg.title contains the bookmark name. An optional description field can be set. Examples
pinboard A node to save bookmarks to your Pinboard account. The payload should contain the URL to save, and msg.title contains the bookmark name. An optional description field can be set. Examples
flickr Saves photos to the configured Flickr account. msg.payload requires a Buffer with the image and can set the optional title, description and tag properties. Examples
foursquare Queries your Foursquare account for venues that meet a configurable set of requirements based on your location. Results can be passed back as a single message or a configurable set of messages. Examples
swarm in A node to poll every 15 minutes for Foursquare storm check-ins. Returned as a JSON object. Examples
swarm out Swarm query node that can be used to search for all Swarm check-ins by the authenticated user. Examples
instagram in Queries the configured Instagram account every 15 minutes for new photos which are delivered one per message, either as Buffer objects or URLs. Examples
instagram Same as Instagram in node, except from being triggered by an incoming message. Examples

Extended set of storage nodes

As you can see, the FRED service adds a large number of social media nodes ranging from Pushbullet to Slackbot to Instagram.

Node name Description Examples
amazonS3 watch Amazon S3 watch node. Watches for file events. By default, all file events are reported, but the filename pattern can be supplied to limit the events to files which have full filenames that match the glob pattern. The event messages consist of the full filename in msg.payload property, the filename in msg.file, the event type in msg.event. Examples
amazonS3 in Amazon S3 input node. Downloads content from an Amazon S3 bucket. The bucket name can be specified in the node bucket property or in the msg.bucket property. The name of the file to download is taken from the node filename property or the msg.filename property. The downloaded content is sent as msg.payload property. If the download fails, msg.error will contain an error object. Examples
amazonS3 out Amazon S3 out node. Uploads content to an Amazon S3 bucket. The bucket name can be specified in the node bucket property or in the msg.bucket property. The filename on Amazon S3 is taken from the node filename property or the msg.filename property. The content is taken from either the node localFilename property, the msg.localFilename property or the msg.payload property. Examples
box watch Box is an enterprise version of Dropbox. This node watches for file events on Box. By default all file events are reported, but the filename pattern can be supplied to limit the events to files which have full filenames that match the glob pattern. The event messages consist of the full filename in msg.payload property, the filename in msg.file, the event type in msg.event and the full event entry as returned by the event API in msg.data. Examples
box in Box input node. Downloads content from Box. The filename on Box is taken from the node filename property or the msg.filename property. The content is sent as msg.payload property. Examples
box out Box out node. Uploads content to Box. The filename on Box is taken from the node filename property or the msg.filename property. The content is taken from either the node localFilename property, the msg.localFilename property or the msg.payload property. Examples
dropbox watch Watches for file events on Dropbox.

By default all file events are reported, but the filename pattern can be supplied to limit the events to files which have full filenames that match the glob pattern.

The event messages consist of the full filename in msg.payload property, the filename in msg.file, the event type in msg.event and the dropbox.js API PulledChange object inmsg.data.

Examples
dropbox in Dropbox input node. Downloads content from Dropbox. The filename on Dropbox is taken from the node filename property or the msg.filename property. The downloaded content is sent as msg.payload property. If the download fails, msg.error will contain an error object. Examples
dropbox out Dropbox out node. Uploads content to Dropbox.

The filename on Dropbox is taken from the node filename property or the msg.filename property. You can pass in content either as a filename by setting the localFilename field or msg.localFilename property, or you can pass in content directly using msg.payload.

The file will be uploaded to a directory on Dropbox called Apps/{appname}/{appfolder}, where {appname} and {appfolder} are set when you set up the Dropbox application key and token.

Examples
MongoDB in Calls a MongoDB collection method based on the selected operator.

Find queries a collection using the msg.payload as the query statement as per the .find() function. Count returns a count of the number of documents in a collection or that match a query using the msg.payload as the query statement.

Aggregate provides access to the aggregation pipeline using the msg.payload as the pipeline array.

You can either set the collection method in the node config or on msg.collection. Setting it in the node will override msg.collection.

Examples
MongoDB out A simple MongoDB output node. Can save, insert, update and remove objects from a chosen collection.

Save will update an existing object or insert a new object, if one does not already exist.

Insert will insert a new object.

Update will modify an existing object or objects.

Remove will remove objects that match the query passed in on msg.payload. A blank query will delete all of the objects in the collection.

Examples
mysql Allows basic access to a MySQL database.

This node uses the query operation against the configured database. This does allow both INSERTS and DELETES. msg.topic must hold the query for the database, and the result is returned in msg.payload.

The returned payload will typically be an array of the result rows. If nothing is found for the key, then null is returned.

Examples
postgres A PostgreSql I/O node.

Executes the query specified in msg.payload with optional query parameters in msg.queryParameters. The queryParameters in the query must be specified as $propertyname.

When receiving data from the query, the msg.payload on the output will be a JSON array of the returned records.

Examples

FRED’s IoT nodes

FRED adds a number of nodes to access popular IoT platforms, including Sense Tecnic’s Community edition of its popular IoT platform, WoTKit, and Bug labs’ dweet.io.

IoT platform nodes
wotkit in WoTKit Sensor Input Node which retrieves new data from a WoTKit Sensor. The node generates a message each time new data is received on the sensor within the WoTKit IoT platform. The message.payload contains a map of sensor field names to sensor values. The node is configured with WoTKit user credentials. The sensor name should be in the form {username}.{sensorname}, or you can use the numeric sensor id. Examples
wotkit out WoTKit output node to send data to a registered WoTKit sensor. The node will use the message.payload to create a data object.

The message.payload must contain an object of key-value pairs matching the sensor fields. The node is configured with WoTKit user credentials.The sensor name should be in the form {username}.{sensorname}, or you can use the numeric sensor id.

Examples
wotkit data WoTKit Historical Data Node which retrieves historical data from a WoTKit sensor by either number of elements or relative time before the request. The message.payload contains a map of sensor field names to sensor values. The sensor name should be in the form {username}.{sensorname}, or you can use the numeric sensor id. Examples
wotkit control out The WoTKit Control Output Node provides the ability to send events to the control channel of a registered WoTKit sensor/actuator. This node will use the message.payload object to create a control event. The message.payload must contain an object of key-value pair for each message. The sensor name should be in the form {username}.{sensorname}, or you can use the numeric sensor id. Examples
wotkit control input The WoTKit Control Input Node provides access to the control channel of a registered WoTKit sensor/actuator. When a control event is received by a WoTKit sensor this node will create a message.payload object containing the event. The sensor name should be in the form {username}.{sensorname}, or you can use the numeric sensor id. Examples
dweetio in Listens for messages from Dweet.io

The Thing ID should be globally unique, as they are all public. It is recommended you use a GUID. The Thing ID is set into msg.dweet, and the TimeStamp into msg.created.

Examples
dweetio out Sends the msg.payload to dweet.io

Optionally uses msg.thing to set the Thing ID, if not already set in the properties.

You need to make the Thing ID unique – you are recommended to use a GUID.

Examples

Extended set of analysis nodes

The FRED platform only adds a limited number of analysis nodes as the default set is quite extensive.

Node name Description Examples
smooth A simple but flexible node to provide various functions across several previous values, including max, min, mean, high and low pass filters. Only works on numbers and will fail if it can’t convert the input to a number. Examples
wordpos Analyses msg.payload and classifies the part-of-speech of each word, returning msg.pos as an array of nouns, verbs, adjectives, adverbs, etc.. Examples

 

Extended set of advanced nodes

FRED adds the following advanced nodes.

Node name Description Examples
ping Pings a machine and returns the trip time in MilliSeconds.

Returns false, if no response received within 5 seconds, or if the host is unresolveable.

Default ping is every 20 seconds, but can be configured.

 

Examples
sunrise Uses the suncalc module to generate an output at sunrise and sunset based on a specified location. Several choices of definition of sunrise and sunset are available.

The first output emits a msg.payload of 1 or 0 every minute, depending if in between selected times or not. The second output emits only on the transition between night to day (-> 1) or day to night (-> 0).

Also sets msg.topic to sun and msg.moon to the fraction of the moon between 0 and 1.

Examples

Other nodes

The following nodes are available in FRED and don’t fit into the basic categories that vanilla Node-RED provides. These include nodes to access and control Google services, enterprise nodes such as Salesforce access, nodes for accessing transportation API (e.g. Transport for London) and other miscellaneous nodes for access to weather services, etc.

 

Fig 4.4 FRED’s other nodes

 

Google nodes

FRED supports several Google nodes to interact with a range of Google services.

Node name Description Examples
Google plus Interacts with the Google+ API to get information about people, activities, and comments.

People – Allows you to interact with Google+ profiles. You can get a particular profile, search for a profile, or gather a list of people that have +1’d or reshared an activity.

Activities – Allows you to interact with Google+ activities. You can get a particular activity, search for an activity, or gather a list of activities directly related to a person.

Comments – Allows you to interact with Google+ comments. You can get a particular comment, or gather a list of comments attached to an activity.

Examples
googleplaces A highly flexible node that utilizes the Google Places API in order to find and learn more about local establishments. Search can be based on ranking, radius, price, keywords, language, etc. Examples
Google calendar in A node to watch a calendar and return a message before, at or after the event in the calendar. Configurable to set exactly when the message is generated. Examples
Google calendar out Create an entry in a Google Calendar based on:

payload – either a string to describe the event using quick add format or an object representing the request body for an insert request

calendar – the calendar to which the event is added (optional, defaults to the node calendar property or the user’s primary calendar)

sendNotifications – a Boolean to determine if notifications should be sent to attendees (optional, defaults to false)

Examples

Fitness nodes

The FRED fitness nodes cover a number of popular fitness devices.

Node name Description Examples
strava Get your most recent activity on Strava.

This node returns the most recent activity in the authenticated user’s account whenever it receives a message. Returns the activity, location and time when available.

Examples
Fitbit in Polls Fitbit for new data at regular intervals. The generated messages are determined by the nodetype property (goals, sleep, or badges). Examples
Fitbit activities Retrieves user data from Fitbit and returns a msg.payload determined by nodetype properties (as fitbit in).

The msg.date property may be set to an ISO 8601 format date (e.g. 2014-09-25) to retrieve historical data for activities and sleep log. If no date is supplied, then data for today will be retrieved. In the case of sleep, this is the data for the preceding sleep.

Examples
jawbone The Jawbone Up node can be used to retrieve the workouts completed since the provided time (given as Epoch). This time can be passed in as settings on the node or as the msg.starttime section of the message input. The value set on the node will take precedence over the contents of incoming message. Examples

Weather nodes

FRED adds a set of nodes to give access to a variety of weather services.

Node name Description Examples
openweathermap A node to query the openweathermap.com site for weather information of a city/country or lat/long pair. Two nodes exist: one that is UI-configured and one that can accept the configuration info as an input message. Examples
forecastio A node to query the forecastio.com site for weather information of a lat/long pair. Two nodes exist: one that is UI-configured and one that can accept the configuration info as an input message. Examples
wunderground A node which queries The Weather Underground API for current weather data periodically and returns when a change is detected. Two nodes exist: one that is UI-configured and one that can accept the configuration info as an input message. Examples

Salesforce nodes

A set of experimental SalesForce nodes are available with FRED.

Node name Description Examples
salesforce A set of 5 nodes that interact with the popular salesforce.com service. The nodes can generate SOSL queries, DML statements, subscribe to the salesforce streaming API or parse outbound salesforce message objects. Examples

Transport nodes

Node name Description Examples
TfL bus Get live bus departure/arrival info for London (UK) buses and river buses.

This node enables the user to get bus or river bus arrival information for selected lines arriving at selected stops. The node returns the first vehicle/vessel to arrive at a particular stop. The data is provided by Transport for London.

Examples
TfL underground A node to get the underground line status for the London Underground. It returns a variety of status information for the specified line including overall status, disruption info etc Examples

Formatting nodes

Node name Description Examples
moment moment is a date/time formatter node that takes as input either a JS datetime object or a string that moment can resolve to such. If the input is null, doesn’t exist or is a blank string, the current date/time will be used. This can be used to add a current timestamp to a flow of any kind easily.

Output is a formatted string or a date object onmsg.payload by default, change by setting the output field.

Examples

Summary

In this lecture, you were presented with a summary of the default Node-RED nodes available on installation, and the extended set of nodes that FRED adds. As you have seen, there is a wide variety of nodes allowing you to build complex flows with little or no programming.

You’ve also seen that not all nodes are always available, for example the Raspberry Pi nodes don’t work unless you are actually running Node-RED on a Pi. So it always pays to check that you can run the nodes you need in your environment.

However, given the large number of nodes available, and the fact that the community is creating new nodes on a daily basis, you are likely to be able to find a node that meets your needs. If not, you can fall back on the flexible function node, or even create your own, something that will be discussed in the advanced lectures.


About Sense Tecnic: Sense Tecnic Systems Inc have been building IoT applications and services since 2010. We provide these lectures, and FRED, cloud hosted Node-RED as a service to the community. We also offer a commercial version to our customers, as well as professional services. Learn more.


 

© Lea, Blackstock, Calderon

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

 

 

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.

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.

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.

 

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.

 

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.

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.

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.

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.

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.

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

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.

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.

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.

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).

 

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.

 

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

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson3/3-1_mqqtmessages.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.

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.

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.

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.

 

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

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.

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.

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.

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.

 

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.

 

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

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.

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).

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%.

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.

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

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.

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.

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.

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

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.

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

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.

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.

 

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

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

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.

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.

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.

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.

 

 


About Sense Tecnic: Sense Tecnic Systems Inc have been building IoT applications and services since 2010. We provide these lectures, and FRED, cloud hosted Node-RED as a service to the community. We also offer a commercial version to our customers, as well as professional services. Learn more.


© Lea, Blackstock, Calderon

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

 

 

Node-RED: Lecture 2 – Building your first flows

This lecture will introduce you to the Node-RED visual tool and get you started building your first flow. You’ll learn how to create simple flows, use debug nodes to track messages through the flows and how to use the function node to write simple JavaScript code that tailors the node to your specific needs.

This lecture will introduce you to the Node-RED visual tool and get you started building your first flow. You’ll learn how to create simple flows, use debug nodes to track messages through the flows and how to use the function node to write simple JavaScript code that tailors the node to your specific needs.

To get you started, you’ll be using a free cloud service that provides you with a preconfigured Node-RED setup and a wide range of built-in nodes. Later lectures will explain how to set-up Node-RED for yourself on devices such as a Raspberry PI.

At the end of this lecture you’ll be able to create your own simple flows, you’ll know your way around the Node-RED UI and you’ll be familiar with some of the basic built-in nodes that Node-RED offers.

FRED – Front end for Node-RED

FRED is a cloud service that we’ve created that allows you to sign up and use Node-RED without the hassle of downloading and installing on a device such as a PI. It makes it easy to get started with Node-RED by managing an instance of Node-RED for you, keeping the instance up to date with the latest code releases and applying bug fixes or patches. Also included is a set of extra Nodes that are contributed by the community, which add to the standard basic set you get when you install Node-RED yourself. However, FRED is just a wrapper for Node-RED, so anything you write in FRED will work on a Node-RED instance running on a Pi or a Beagleboard.

To begin our examples, make sure you have created your own Node-RED instance in the cloud by signing up for a free account at http://fred.sensetecnic.com.

After registering, make sure to activate your account via your email. You will not be able to log in until you validate your account.

The Node-RED UI

Once you have logged in to your FRED account, you’ll see the standard Node-RED UI which consists of three main panes, as shown in Fig 2.1

Screen Shot 2015-10-22 at 4.53.21 PM.png

Figure 2.1 The Node-RED UI  – showing the node palette (left), flow canvas (centre) and output pane (right)

The main pane is the flow creation workspace in the middle. This is where you drag and drop nodes and connect them with wires. Along the top of the workspace pane is a set of tabs. Each tab opens a previously created workspace and shows any flows created using that workspace.

On the left is the node pane that contains all the built-in nodes that your instance of Node-RED supports. In the example above, you are seeing the FRED node set which contains a large selection that has been added to the basic set that comes with Node-RED. In later lectures you will learn about these nodes and use them to develop new flows. As you can see, nodes are grouped into categories. Opening up a category shows the individual nodes.

On the right-hand side is the output pane that can be toggled between the info and debug tabs. When info is selected, documentation for the selected node is shown there.  When debug is selected, it will display the output of debug nodes, errors and warnings.

Above these three main panes is the usual toolbar, and on the right-hand side are three widgets, a deploy button, a user info icon and a pulldown menu for admin and control. You’ll look in more detail at the pulldown later in these lectures. The user info icon allows you to return to the FRED front page with links to tutorials, your account information, status and other information as well as to log out of the FRED service.

The Deploy button is used when a flow has been constructed and causes the flow to be deployed onto the Node-RED system and executed. You’ll be introduced to the details of what’s actually happening under the covers in lecture 5 and beyond. For now just treat the Deploy button as the way to get your flow running.

A quick tour of Node-RED nodes and messages

As you saw in lecture 1, Node-RED allows you to wire together nodes to create flows which carry out your programming task. Messages pass between nodes, moving from input nodes through processing nodes to output nodes. Let’s take a brief look at nodes, flows and messages.

There are three main  types of nodes:

  1. Input Nodes (e.g. inject)
  2. Output Nodes (e.g. debug)
  3. Processing Nodes (e.g. function)

basic-fred-intro-02

Figure 2.2 The main types of nodes: input, output and processing

Input nodes allow you to input data into a Node-RED application or “flow”. They have at least one output endpoint represented by the small grey square only on their right side. You use input nodes to connect data from other services, for example the  Twitter, Google, serial, websockets or tcp nodes, or to manually input data into a flow using the inject node.

Output nodes allow you to send data outside of a Node-RED flow. They have a single input endpoint on their left side. You use output nodes to send data to other services, for example via Twitter, tcp, serial or email nodes, or to use the debug node to output to the debug pane.

Processing nodes allow you to process data. They have an input endpoint and one or more output endpoints. They allow you to transform the data type (e.g. json, csv, xml) nodes, use the data to trigger a message (e.g. trigger, delay) nodes and to write custom code that uses the data received (e.g. function node).

Note that some nodes, like the inject and debug messages, have a button that allows you to actuate a node (in the case of the inject node) or to enable and disable a node (in the case of the debug node).

Flows consist of multiple nodes wired together, with output tabs linked to input tabs of the next node in the flow. Messages flow along the nodes carrying data from node to node.

Node-RED nodes consume input messages and produce output messages. Messages are JavaScript objects that contain at least a “payload” parameter, like this:

Listing 2.1 A basic Node-RED message structure

  1. msg = {
  2.   payload:”message payload”
  3. };

Nodes consume and produce messages, usually using msg.payload as the main placeholder for the data they consume and produce. However, messages can be extended to contain other parameters. For example, to set the topic of a message and add a new parameter, location, you could create a new msg object as shown in listing 2.2.

Listing 2.2 A more complex Node-RED message structure

  1. msg = {
  2.   payload:”message payload”,
  3.   topic:”error”,
  4.   location:”somewhere in space and time”
  5. };

Let’s use this knowledge to create your first flow.

Example 2.1 Building your first flow: Hello World

Let’s go ahead and start building your first flow so that you can see how simple it is to use the Node-RED UI to build and deploy a flow.

Let’s start with the easiest flow possible, a node to inject some information into the flow, wired to a debug node to see the output from the flow as a debug message. Once you have that running, you’ll build it up to the full Hello World flow.

Since this is the first time you’ll be shown how to actually build a flow, let’s start slowly and explain each step with a screen-shot. Once you’ve created your first flow and seen how easy it is, you’ll mostly be shown a single picture of the final flow rather than all the screenshots.

Let’s start with the simplest Node, the comment Node. You’ll find this in the function section of the node palette. Drag and drop a comment node onto the flow workspace as shown in Fig 2.3.

 

Screen Shot 2015-07-31 at 2.03.20 PM.png

 

Figure 2.3: Using a comment node is a great way to add visible comments into flows

 

Once you’ve done that, take a look at the info pane on the right (remember to switch to info if the debug tab is selected). You’ll see a little info on the node, including the node name, a unique ID, and a properties field with a description of the node. For the comment node there’s not much to say; however, more sophisticated nodes have a lot more info.

Double-click on the comment node, and you’ll see a configuration window (Fig 2.4) You can give the comment node a name and add detailed text if you like.

 

Screen Shot 2015-07-31 at 12.16.33 PM.png

Figure 2.4 Give the comment a name and add any info you want in the text box

 

Ok, now let’s add the first node that actually does something, an inject node. The inject node is used to generate input into a flow and is one of the first nodes in the node palette under input. If you drag and drop an inject node onto the flow workspace, and then look at the info tab, you’ll see the documentation for the inject node. Note that the name of the node on the workspace changes from inject to timestamp, because the default behaviour for the node is to inject a timestamp – the current time in milliseconds since January 1, 1970.

 

Screen Shot 2015-07-31 at 12.03.59 PM.png

Fig 2.5 The inject node allows you to insert events as messages, defaulting to a timestamp

 

You’ll also notice that the inject node (now named timestamp) has a blue dot top right and a grey square centre right. The blue dot indicates that the node hasn’t been deployed since it was last changed; the grey square is the output point for the node. This is where you attach ‘wires’ that route output message from the inject node to the next node in the flow.

To get a sense for the inject node and the whole flow deployment process, let’s add a debug node to see what happens, wire them together and then deploy the flow and test it.

Start by dragging a debug node from the node palette to the workspace. Again you can look at the info for the node.

Then you’ll wire the two nodes together. To do that, click on the grey output point for the inject node and, holding the mouse button down, drag towards the debug node. An orange wire appears, which you can then attach to the grey input point on the debug node.

Screen Shot 2015-07-31 at 12.40.55 PM.png

Figure 2.6 Wiring an inject node to a debug node

 

This is the simplest flow possible and will send the current timestamp to the debug node for display in the debug pane. Let’s try it!

Click the deploy button in the Node-RED window (top right). You’ll see a pop-up saying the flow has been successfully deployed. You will also notice that the blue dots on the nodes disappear, indicating there are no undeployed changes.

Now, before you try the flow, make sure the the debug tab is selected on the right pane. Then click on the left tab on the inject node and look at what appears in the debug pane.

 

Screen Shot 2015-07-31 at 12.48.44 PM.png

Figure 2.7 Debug output from your first flow – the time when you clicked the inject node.

 

As you can see, the inject node, when clicked, generates a timestamp (number of milliseconds since January 1, 1970), which is converted to a message and sent along the output wire, which is delivered to the debug node as an input message. The debug node’s default behaviour is to show any message it receives, which it does in the debug pane on the right.

Congratulations, you created and deployed your first flow!

Let’s now augment it a little to see what else we can do with this simple flow. Firstly, we’ll edit the inject node to deliver a text message rather than a timestamp. To do that, select the inject node in the flow and double-click it. You’ll see a configuration window like the one in Fig 2.8.

 

Screen Shot 2015-07-31 at 12.54.29 PM.png

Figure 2.8 Editing an inject node to send text instead of a timestamp

 

In the payload field, select string instead of timestamp and then type any string you like into the blank field below the payload field. As is traditional, let’s start with “Hello World – from my first NR flow!”

Once you’ve made the change, click ok to save the changes and take a look at the flow. You’ll see the blue dot has appeared on the inject node (which has also returned to being called inject rather than timestamp) to indicate that you have undeployed changes. Click the deploy button again to resolve that and then go ahead and click the tab on the inject node. If you look at the debug output you’ll see that instead of a timestamp, your text has been delivered as a message to the debug node, which displays it as usual.

Screen Shot 2015-07-31 at 1.01.40 PM.png

Figure 2.9 Sending a text message rather than a timestamp

 

As you can see, it’s very easy to wire up some simple nodes and get data to pass through your flow as messages. At this stage, you’ll probably be wondering a little about the messages that are flowing between nodes. The debug node can be used to examine them in more detail.

All messages in Node-RED have three default properties: the payload, which we are seeing above, a message topic, which is a user-defined string describing what the message is about (its topic, if you will) and an internal identifier. You can actually see this information if you edit the debug node configuration. Let’s do that and look at the output (Fig 2.10)

 

Screen Shot 2015-08-06 at 11.15.08 AM.png

 

Figure 2.10: setting the debug node to show the internals of a message

 

Select the debug node, double click and change the node output field to “Complete msg object”. If you then save this, deploy again and click the inject node, you will see in the debug pane a JSON structure that contains 3 fields: a “topic” which is currently blank, a “payload” which contains the string you set in the inject node and an internal ID field “_msgid”. Generally the internal message ID field isn’t used. However, both the topic and payload are used extensively when developing flows. You’ll see more of that later in the lecture series.

These fields are extensible, so you can define new message properties, for example, msg.location, which could be used to add the latitude and longitude values for the source of the message. Let’s take a look at that in the next example flow.

 

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

https://github.com/SenseTecnic/nrguideflows/blob/master/lesson2/2-1-firstflow.json

Example 2.2 A second flow: weather alerts

In this example, which is similar to the one introduced in lecture 1, you’ll monitor the weather in your hometown and send yourself a tweet when the weather looks like it’s going to be good. You’ll use a built-in weather node – openweathermap – that retrieves the weather from openweathermap.org for the location you set it for. A simple function node will be used to check for ‘clear weather’ and a Twitter node will be used to send yourself a tweet when the weather looks good.

First you will need to get an API key at OpenWeatherMap. OpenWeatherMap offers a great service that provides detailed weather information for worldwide locations. Visit http://openweathermap.org/appid and follow the instructions as shown in the screenshots below.

 

 

You will need to sign up for an OpenWeatherAccount as shown below:

After signing up you will be redirected to your Home page where you will be able to access or re-generate your API Key. It should look something like this:

Now, let’s use that API key to build a weather alerts flow. Drag and drop a weather node from the left pane onto the workspace, as shown in Figure 2.11.

 

Figure 2.11. Drag and drop a weather node onto a blank workspace

 

If you select the info pane on the right, you can see a description of the openweathermap node with detailed information on how to configure and use it. Some interesting things to note:

  • It has a full JSON structure as its msg.payload, with quite a lot of weather detail, all presented as name:value pairs, e.g. wind speed and tempc
  • The node defines 3 new message properties, msg.location, msg.time and msg.data. As mentioned above, you are free to add properties to messages, and the openweathermap node has added these new properties to carry extra information associated with the message.

Let’s configure the node and look at the actual data structure it generates after it has queried your local weather. Start by double-clicking on the node and fill out the form with your location. Type your city and country in the fields. Add the API key you obtained from http://openweathermap.org/appid and click on “Ok” as shown in Fig. 2.12.

 

 

Figure 2.12. Set your city and country in the configuration form, use the API key you obtained in the step above.

 

Then drag and drop a debug node and wire it to the openweathermap node. Click on “Deploy” to see that the payload object from the openweathermap node in the debug pane.

 

Listing 2.3 The message payload for the openweathermap node is a JSON structure describing weather conditions, temperature, wind, cloud cover and sunrise times.

  1. {
  2.   “weather”: “Clear”,
  3.   “detail”: “sky is clear”,
  4.   “tempk”: 295.104,
  5.   “tempc”: 21.903999999999996,
  6.   “humidity”: 53,
  7.   “maxtemp”: 295.104,
  8.   “mintemp”: 295.104,
  9.   “windspeed”: 2.22,
  10.   “winddirection”: 273.007,
  11.   “location”: “Vancouver”,
  12.   “sunrise”: 1432038196,
  13.   “sunset”: 1432094081,
  14.   “clouds”: 8,
  15.   “description”: “Vancouver weather(49.25,-123.12) is Clear (sky is clear).”
  16. }

As you can see, the node delivers quite a lot of information about your local weather, all as the usual name:value pairs. For this example, you want to use the “weather” field which you’re going to test to see if it’s reported as “Clear”. If it’s “Clear” you’ll then send a tweet.

To program that logic, you’ll use a function node. You saw one of these in lecture 1, but without the details. Let’s see how they are used by dragging one onto the flow workspace and double clicking it to open up the node editor.

Figure 2.13. Add a function node and wire it to the openweathermap node.

Now double-click on the function node and type/copy this (Note if you use copy/paste – make sure you paste as plain text, wordpress sometimes inserts odd characters)

 

Listing 2.4 Function node “If Clear Weather”

  1. if (msg.payload.weather === “Clear”) {
  2.     msg.payload = “Clear skies ahead today!”
  3.     return msg;
  4. }
  5. return null;

Figure 2.14. Edit the function node adding the JavaScript shown in listing 2.4

Looking at Listing 2.4, you can see that this will parse the incoming message payload for the weather parameter and compare it to the string “Clear” (line 1). If it is equal, it will rewrite the message payload with your own string “Clear skies ahead today!” (line 2). Otherwise it will return a null message (line 5). This last bit is important because in Node-RED nodes ignore null messages.

You can do all sorts of things now, for example wire this message to an email node, or a pushbullet node. For this tutorial we will use the Twitter output node. Drag  a Twitter node onto the workspace, double-click and and fill out your Twitter account credentials as shown in Fig 2.15.

Figure 2.15. Set your Twitter account credentials into the node configuration

Once you’ve set up these credentials, Node-RED stores them and you can reuse them when you create another Twitter node in future flows.

Once you’ve wired up the flow, you can hit the deploy button and then watch your Twitter account to see the new tweet every time the weather is reported as clear.

Click on “Deploy”:

Figure 2.16. The full weather flow sending tweets if the weather report mentions clear skies.

Other useful UI features

One of the most useful features of the Node-RED UI is the ability to copy and paste nodes and even full flows using the standard cut’n’paste clipboard. Node-RED flows are simply coded as JSON strings and can be exported from a workspace, and imported into a workspace using the Node-RED pulldown menu in the top right of the Node-RED window.

Rather than building the flows in this example, or in fact anywhere in this lecture series, by hand yourself, you can simply copy them from our website and paste them into a workspace. After that all you need to do is configure them correctly, e.g. with credentials, and deploy them.

Let’s quickly show you how to do that.

Click on the link for this example which is at the end of the example below and look for the JSON code. Copy it to the clipboard using the usual CTL C or copy item in the edit menu.

Using the pulldown menu in the top right of the Node-RED window, select Import->Clipboard as shown in Fig 2.17

Screen Shot 2015-08-15 at 12.55.58 PM.png

Figure 2.17 Selecting the Import from Clipboard menu item in Node-RED

 

You will see a popup with an input field (Fig 2.18). Paste your clipboard into the input window and click OK.

 

Screen Shot 2015-08-15 at 12.56.27 PM.png

Figure 2.18 Pasting a flow into the import window of Node-RED

 

The new flow will appear in the current workspace and can be moved to a location and dropped. Once it’s in place, you can configure it as you would a flow you created yourself and deploy it.

 

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

https://github.com/SenseTecnic/nrguideflows/blob/master/lesson2/2-2_weatheralerts.json

Summary

In this lecture you have created your first flows and seen how to wire together a set of basic nodes to achieve quite complex tasks. We’ve skipped over a few of the underlying details in order to get you going quickly, and we’ll return to those in lectures 3 and 4. However, so far you’ve seen how to use the Node-RED visual flow builder, the basic classes of input, output and processing nodes. You were given a brief overview of messages and how to use the function node to write your own JavaScript code to do simple processing on messages within a flow. In the next lecture, you’ll take a more in-depth look at the programming model of Node-RED and get a better understanding of the main programming elements and nodes and how to craft more complex flows using a variety of nodes.

 


About Sense Tecnic: Sense Tecnic Systems Inc have been building IoT applications and services since 2010. We provide these lectures, and FRED, cloud hosted Node-RED as a service to the community. We also offer a commercial version to our customers, as well as professional services. Learn more.


© Lea, Blackstock, Calderon

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

 

Node-RED: Lecture 1 – A brief introduction to Node-RED

This lecture will introduce you to some examples of Node-RED, both to give you a sense of its capabilities and to introduce its basic concepts. We’ll also discuss the history of Node-RED and its origins to give you an idea of what Node-RED is good for and of what types of tasks are best left to a more traditional programming language and environments.

Node-RED is a powerful tool for building Internet of Things (IoT) applications with a focus on simplifying the ‘wiring together’ of code blocks to carry out tasks. It uses a visual programming approach that allows developers to connect predefined code blocks, known as ‘nodes’, together to perform a task. The connected nodes, usually a combination of input nodes, processing nodes and output nodes, when wired together, make up a ‘flows’.

Originally developed as an open source project at IBM in late 2013, to meet their need to quickly connect hardware and devices to web services and other software – as a sort of glue for the IoT – it has quickly evolved to be a general purpose IoT programming tool. Importantly, Node-RED has rapidly developed a significant and growing user base and an active developer community who are contributing new nodes that allow programmers to reuse Node-RED code for a wide variety of tasks.

Although Node-RED was originally designed to work with the Internet of Things, i.e. devices that interact and control the real world, as it has evolved, it has become useful for a range of applications.

This lecture will introduce you to some examples of Node-RED, both to give you a sense of its capabilities and to introduce its basic concepts. We’ll also discuss the history of Node-RED and its origins to give you an idea of what Node-RED is good for and of what types of tasks are best left to a more traditional programming language and environments.

By the end of this lecture you should have a high-level understanding of Node-RED, its programming model and some simple pre-built nodes as well as an insight into the origins and best usage of Node-RED.

Getting to know Node-RED

Let’s get started by looking at a few simple examples of the kinds of thing you can do with Node-RED. Our goal in this lecture is not to get you programming with Node-RED, but to give you a sense of its capabilities through some high level examples. If you really want to dive straight in, you can skip ahead to lecture 2 where you’ll be taken through the steps to create and run your first flow.

This first example flow will receive a message from a Twitter feed containing a hashtag and turn on and off a LED when a new tweet has arrived. For this example let’s assume that NODE-RED is running on a Raspberry PI – a common situation for many Node-RED users.

Example 1.1 Using Twitter to control a Raspberry PI

The Node-RED flow to check Twitter and to see if a hashtag #led is detected, turns on a LED connected to a Pi is shown in Fig. 1.1. As you can see, it’s quite simple; it consists of 3 nodes wired together – a twitter node on the left, a trigger node in the middle and a Raspberry Pi (gpionode) node on the right. (gpio stands for General Purpose Input/Output and is the name given to the generic Raspberry PI node that handles IO). The nodes, represented by rounded boxes, usually have an icon to represent their type, e.g. the Twitter bird icon in the first node, and a text name that can be set by the programmer.

Each of these three nodes is built into the Node-RED visual programming tool and can be dragged from a node palette onto the main workspace. They are then ‘wired’ together by joining their output tabs to the input tab of the next node in the flow (the little grey blobs on the right or left of the node boxes.) The next lecture will look at the UI in detail, but for now let’s focus on the high-level capabilities.

 

Figure 1.1 A simple 3 node flow that uses a Twitter tag to trigger a LED on a Raspberry PI.

The Twitter node is a built-in node in Node-RED and hides all of the complexity of using the Twitter API. It can be configured with a user’s account credentials and a variety of search strings, in our case it’s simply looking for hashtag ‘#led’.

When the Twitter node sees the tag either in a tweet to the user, or the public tweet feed, it creates a new message with the details of the tweet, which is forwards to the next node in the flow. In our example, since the Twitter node’s output is wired to the trigger node’s input, the trigger node receives a message with the details of the tweet.

The trigger node is another built-in node in Node-RED and its default behaviour is to wait for any message on its input. When it receives a message, it ‘triggers’, and sends a message on its output with the value “1” as the message body. It then waits 1 second and sends a second message with the value “0” in the message body.

Since the trigger node is connected to the gpionode, which controls the Input/Output or IO pins on the Raspberry PI, it get’s these two messages, 1 second apart, on its input.

Again, the gpionode is a built-in node in Node-RED that hides the details of setting the IO pins on the PI. When it gets a message with a value of “1” in the body, it takes the IO pin high, and when it receives a message with body of “0”, it takes the pin low. In this example, the gpionode is configured to control pin number 12, and so the node shows that in the node icon.

If you have your PI wired up with an LED connected to Pin 12, the gpionode going high for 1 second and then low will cause the LED to blink on for 1 second.

If you think about what’s happening here, it’s actually an incredibly powerful example of Node-RED and the Internet of Things (IoT). It’s connecting the ‘Twitterverse’ to a PI and an LED, but requires no programming – all the tasks are carried out by pre-built nodes in Node-RED which just need configuring. This really demonstrates the power of Node-RED when running on a simple device such as a Raspberry PI.

So just to recap. Node-RED is a flow-based programming tool with a visual editor that allows you to wire together nodes to create flows. In this case, 3 nodes create our first flow. Real-world events, e.g. a tweet with the #led hashtag, are converted to messages, which ‘flow’ along the wires between the nodes. Nodes process messages on their input and, as a result, send messages on their outputs to the next node in the flow. In this simple example, we look for a tweet with hashtag #led and use it to trigger a message to a Raspberry PI node that cause IO pin 12 to go high for 1 second, which in turns causes a LED to blink on for 1 second.

This example – and the rest in this lecture – are mostly to show you the kinds of things we can do with Node-RED. If you want to play around with the example, you should look at lecture 2 to see how to setup an account with FRED (the cloud based Node-RED service we use) and how to get started. You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson1/1-1_twitter.json

Example 1.2 Using Node-RED to alert you when you’re falling behind on your exercise schedule

Our second example shows a different usage of Node-RED. Rather than controlling a device such as a Raspberry PI, this flow combines weather info and your fitbit usage to send you an email alert when the weather is good and you’re behind on your exercise schedule. The flow is a little more complicated, using 6 nodes (see Fig 1.2), but again, by using built-in nodes you can accomplish complex tasks with little or no programming.

 

 

 

Figure 1.2 A simple flow to alert you when you are not exercising and the weather is good

 

As before, nodes are dragged from the node palette in the Node-RED UI and wired together on the flow canvas. Starting at the leftmost node, let’s begin with an openweather node which you can configure to check the weather for any major city at set intervals. When it checks, it packages up the results in a message which is forwarded to the next node, in this case, to a switch node. The switch node performs a simple test, checking the input message for a value and sending a message with a value of “1” if the test is true. In our case, it’s been configured to test the temperature value (tempc) to see if it’s 15 degrees celsius or higher.

When the switch node tests to true, or ‘switches on’, it sends a message onto the fitbit node which is the next node in the flow. The fitbit node is another powerful built-in node that you can configure to get statistics on your fitbit device from the fitbit.com portal. The fitbit node packages the statistics for your device into a message and forwards it to the next node in the flow.

The next node is another switch node. This one has been configured to check if the number of steps you’ve walked today is less than 1000. It does this by testing to see if the fitbit data field, summary.steps, is less than 1000. Remember, it just got these statistics in a message from the fitbit node, which in turn got them by making a call to the fitbit API on fitbit.com.

If you have walked less than 1000 steps today, then the switch node generates a message that is passed on through the flow to a function node. The function node is a generic all-purpose node that allows you to write your own programming logic in Javascript. This node will be discussed in more detail in the next lecture. For now you can assume that this node just creates a new message with an email subject line and a text body that can be sent by email.

Once this message is created within the function node, it is sent through the flow to the final node which is an email node. This node will take the body of any incoming message and send it to the email account configured when the node is initialized. In this case, you’d set it up to send a message to yourself.

So again, a very simple flow that uses the power of Node-RED’s built-in nodes to check your local weather. And if it’s reasonably warm and you haven’t done much walking today, it sends you an email reminder.

Although the example seems quite simple, just checking the weather and your fitbit activity, you can use similar flows to check the status of home devices, of computers in your server farm, of devices in a factory, etc., and you can then use output nodes to send mail, tweets, make API calls to back-office software, control real world devices – in fact the choices are endless. Node-RED is an extremely powerful tool for wiring together inputs and outputs and offers many nodes, either built in or developed by the Node-RED community, to carry out an amazing range of tasks.

 

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

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson1/1-2_weatheralert.json

Example 1.3 Building a simple web service using Node-RED’s built-in HTTP nodes

Our final example in this high-level introduction is yet another class of flows. It shows how to create a simple web service that responds to a browser sending a HTTP request by querying some real-world data, and then delivers a web page with a graphical representation of that data back to the browser – essentially Node-RED is being used to provide a web server and simple service all with a few nodes.

Sticking with the fitbit node introduced in the previous example, and this example creates a simple web service that allows you to query your fitbit stats for the day and, using a nice donut chart, display how many calories you’ve ‘burned off’ through exercise.

The flow is shown in Fig 1.3 and consists of 4 nodes. The first and final nodes are http input and output nodes that work together to listen for HTTP requests and send HTTP responses. This flow listens for a HTTP request from any source, but let’s assume a regular browser here. When it arrives, it queries your fitbit stats from fitbit.com, then uses a template node to build a HTTP page, and passes that to the http output node which sends back the webpage to the browser.

Figure 1.3 A simple web server example to graph fitbit data

 

Again, this is just to give you a sense of the power and flexibility of Node-RED without going into all the details of how this flow works. You’ll get to know more about that in later lectures. At a high level, the http input node has been configured to listen for HTTP requests on a URL, which is a combination of the hosting service that’s used in these lectures plus your login name {username} and the /fitbit string. This will be explained in more detail in lecture two.

When a HTTP request comes in, the http input node creates a message to trigger the fitbit node, which is the next node in the flow. The fitbit node gets the current statistics for the user, and then passes those statistics, as a message, to a template node. The html template node is another pre-built node in Node-RED, which, like the function node, allows you to build arbitrary code. However, rather than using JavaScript like the function node, the template node works with text such as HTML.

The HTML code in the template node is shown in Listing 1.1, so you can see what’s happening. However, there’s no need to examine it in detail if you don’t want to. Basically, the template node takes the calorie consumption data from fitbit and, using a 3rd party graphing library, creates a simple HTML file that will tell the receiving browser to use the 3rd party graphing library to display a donut chart of calorie consumption.

 

Listing 1.1 A simple HTML template to display a donut chart of calorie usage

 

  1. <!doctype html>
  2. <head>
  3.     <title>A Node RED Example</title>
  4.     <link rel=”stylesheet” href=”//cdnjs.cloudflare.com/ajax/libs/morris.js/0.5.1/morris.css”>
  5.     <script src=”//cdnjs.cloudflare.com/ajax/libs/raphael/2.1.0/raphael-min.js”></script>
  6.     <script src=”//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js”></script>
  7.     <script src=”//cdnjs.cloudflare.com/ajax/libs/morris.js/0.5.1/morris.min.js”></script>
  8. </head>
  9. <html>
  10.     <div id=”chart-example” style=”height: 250px;”></div>
  11.     <script>
  12.         Morris.Donut({
  13.            element: ‘chart-example’,
  14.            data: [
  15.              {label: “Activity Calories”, value: {{payload.summary.activityCalories}} },
  16.              {label: “Calories BMR”, value: {{payload.summary.caloriesBMR}} },
  17.              {label: “Calories Out”, value: {{payload.summary.caloriesOut}} }
  18.           ]
  19.        });
  20.     </script>
  21. </html>

 

Once the template node has generated the HTML file, it passes it as a message to the final node, which is a http response node. This node packages up the HTML as a HTTP response which it send back to the browser.

The user will then see a simple donut chart of their calorie usage for the day (see Fig 1.4)  – all built and served by a simple Node-RED flow!

 

 

Figure 1.4 A donut chart, served up by Node-RED showing calorie counts from fitbit

 

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

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson1/1-3_webservice.json

The History of Node-RED

As the examples in the previous section have shown, Node-RED is a powerful tool for building IoT applications and services. Its genesis was triggered exactly by this need to rapidly prototype IoT applications and Node-RED was created as an open source project by the IBM Emerging Technologies group, in particular by two researchers, Nick O’Leary and Dave Conway-Jones. They created Node-RED initially as a tool for themselves as they were working on IoT projects and were “looking for a way to simplify the process of hooking together systems and sensors when building proof-of-concept technologies for customers.”

An initial version of Node-RED was released as an open source project in late 2013 and built up a small but active user and developer group during 2014. At the time of writing, Node-RED is still an emerging technology, but has already seen significant adoption by makers, experimentalists and a number of large and small companies experimenting with using it for their needs.

Today there is a vibrant user and developer community, with a core group working on the Node-RED code itself and most developers contributing nodes or flows to the flow library. You can check out the mailing list and github repositories using the links provided in Appendix A or just google them.

Since Node-RED is still a rapidly evolving technology, be aware that things can change quickly. These lectures were written against the 0.11.0 release of Node-RED and the examples will be updated as Node-RED evolves. However, it’s always wise, as with any new technology, to check compatibility if things aren’t working the way you expect.

Node-RED and the IoT

When the IBM folks created Node-RED, they were mostly focused on the Internet of Things, i.e connecting devices to processing and processing to devices. As a tool for rapid application development for the IoT, Node-RED is both powerful and flexible. Its power comes from a combination of two factors:

  • Node-RED is an example of a flow-based programming model – messages representing events flow between nodes, triggering processing that results in output. The flow-based programming model maps well to typical IoT applications which are characterised by real-world events that trigger some sort of processing which in turn results in real-world actions. Node-RED packages these events as messages which offer a simple and uniform model for events as they flow between nodes that make up the flows.
  • The set of built-in nodes is the second part of the Node-RED story. By building a set of powerful input and output nodes, each of which hides much of the complexity of interacting with the real world, Node-RED offers developers powerful building blocks to allow them to quickly put together flows that accomplish a lot, without having to worry about the programming details.

 

These two factors make Node-RED a powerful tool for IoT application development. When combined with the flexibility to create and use nodes such as the function node, which allows the developer to quickly write arbitrary JavaScript, plus the Node-RED community, who are constantly creating and sharing new nodes, Node-RED is likely to be one of the main tools in the IoT developers toolbox.

However, Node-RED isn’t always the best tool for IoT application development. While powerful and flexible, it isn’t always the right solution. Some situations where Node-RED may not be the first choice include:

  • Complex multi-function IoT applications. Node-RED excels at rapid application development and at acting as the glue for connecting events to actions, or sensors to actuators, if you like. However, when an application gets above a certain size, it becomes complex to visually program and manage through Node-RED. There are some features to help with this, e.g. sub-flows (see lecture 5), but eventually the UI becomes a bottleneck.
  • Flow-based programming is a programming model that is not always the most suitable for application development. In much the same way that certain programming languages excel at some tasks but not others, flow-based programming has its weaknesses. A good example are loops: Node-RED is cumbersome when handling loops.
  • Specific use cases. Flow-based programming is a general purpose model and not targeted or optimized for specific needs, for example Data Analytics or User Interface development. At the moment Node-RED has no specific support for these type of applications and no easy way to add such support. Obviously, because the underlying technology of Node-RED is JavaScript, you can leverage its capabilities for these needs. If want to use Node-RED to prototype something, one approach is to implement parts or all of your application in another language more suited to your task and use Node-RED for the overall control.

 

Having said that, as has been shown in this lecture and will be demonstrated in the following lectures,  Node-RED is a powerful tool for a large number of IoT applications. As it evolves it will become both more sophisticated and more usable in a wider range of circumstances.

Perhaps just as important, as you explore Node-RED in subsequent lectures, you will realise that although Node-RED’s roots are in the IoT, it is a tool that can be used to build a wide variety of applications, not just IoT applications. In fact, in these lectures you will see example of Node-RED being used for web apps, social media apps, back-office integration, IT task management, i.e. across the range of modern computing tasks.

Our hope is that by the end of this lecture course, you will see Node-RED, as we do, as a flexible and powerful tool that can be used in many situations, both for prototyping but also for production level development.

Summary

In this lecture we’ve taken you through a high-level look at Node-RED. You’ve seen how Node-RED wires together building blocks, using a visual tool to rapidly create simple flows that actually carry out sophisticated real-world tasks. You’ve also learnt a little about the origins of Node-RED as a rapid application development tool for the IoT and how, as it has evolved, it’s now being used for a variety of tasks, not just IoT programming. Finally, we’ve discussed the limitations of Node-RED and indicated some areas where other languages and tools may serve you better. In the next lecture, we’ll start on some real programming and show you how to build your own flows using the basic nodes that Node-RED provides.

 


About Sense Tecnic: Sense Tecnic Systems Inc have been building IoT applications and services since 2010. We provide these lectures, and FRED, cloud hosted Node-RED as a service to the community. We also offer a commercial version to our customers, as well as professional services. Learn more.


© Lea, Blackstock, Calderon

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.