I explained how to process the data in the last tutorial, its time to learn how to send the data to NodeRED and how to interact with other devices. These are the nodes that usually start and end your flow. I’m going to talk about connectivity with other IoT devices, Android phones and services like IFTTT. After this tutorial, you will know how to send the data in and out of NodeRED.
NodeRED for beginners: 5. Connectivity
Before we dive into the details I’d strongly recommend that you read the Data Processing part & JSON for beginners. A lot of things I’m going to talk about will be based on assumption, that you possess the relevant knowledge. Sending data in and out of NodeRED will require some sort of data structure and JSON is the default way of processing organised information in NodeRED. Consider the security if you planning on making the NodeRED server available to WAN, I have a guide on how to secure NodeRED server in 5 min.
HTTP requests
HTTP requests are enabled by default. You can send data to NodeRED from anything that supports the protocol. I’m going to simplify how you interact with the server via requests, as this is a tutorial for beginners. The two most popular types of requests are POST and GET.
POST will submit data to the NodeRED server (again there is more to that)
GET will request data from the server.
What’s also super useful is that requests are not sent blindly and each one of them will receive a response. This way you will be aware that the HTTP protocol has been successful.
HTTP in
Whether sending a POST or GET request, NodeRED nodes have to be configured accordingly. The requests will have to match the node type, directory and receive the response. Let’s issue a simple POST request with a current temperature as data.
{"temp": 23};
To send the request, you will need to provide the following details:
Server:port: https://NODERED_IP:1880 Path: /weather Data:{"temp": 23} Content type: application/JSON //or application/x-www-form-urlencoded
or (if your server is SSL and HTTP requires authentication)
Server:port: https://username:password@NODERED_IP:1880 Path: /weather Data:{"temp": 23} Content type: application/JSON //or application/x-www-form-urlencoded
This is the minimum, that you need to provide. The information and formatting may change based on the service/language/system issuing the HTTP POST. In my examples, I will use Tasker and IFTTT Webhook configuration.
Using an HTTP input node and a response node linked to a debug, I can quickly check how data is received by NodeRED.
object_msgid: "7c4a3ea3.cb753" payload: object temp: "23" req: object res: object
The temperature value can be accessed via:
msg.payload.temp = "23" //note this is passed as string not an integer
It is possible to send the information as a string instead of JSON object, but it’s so much easier to work with JSON in NodeRED and process the data that way.
HTTP out
NodeRED can be used to send the HTTP requests as well. The HTTP node has to be configured with all the information needed to pass the correct HTTP request. You can configure the node directly (including SSL and Authentication) or submit the values set by a function or change node.
A function node with a specific header instead of the basic authentication
msg.payload = "data to post"; msg.url = "https://some_url"; msg.method = "POST"; msg.headers = {}; // custom header msg.headers['X-Auth-User'] = 'user'; msg.headers['X-Auth-Key'] = 'key'; return msg;
When using HTTP GET, the response can be then used further on in the flow as the information received by the node will be available as the message object.
MQTT
One of the easiest ways to communicate with other IoT devices is MQTT protocol. This system has been used in the past to communicate with satellites. If it’s good enough for space exploration, it’s good enough for home automation!
MQTT protocol is a client-server configuration. The server runs usually on the same device as NodeRED and it’s called a broker. Clients are connected to the broker, and receive messages in channels (topics) that they are subscribed to. Each client can be subscribed to multiple topics. Both client and broker can send a message to one of the topics (publishing) and each device subscribed to the same topic will receive that message.
The MQTT comes with built-in security (authentication requirements), message levels (how the message is published and received), and last will (what happens when a device goes offline) options which further enhance the communication.
To use MQTT, we have to install the broker service. One of the most popular ones is Mosquitto:
sudo apt-get install mosquitto
This will create the instance of the MQTT running at the default port 1883. MQTT nodes in NodeRED are added by default you will be able to find the input and an output node. Before you can use any of them, a quick config is required.
The config is pretty straightforward, you will be asked to provide the IP of your board, change the port number if you want to and configure the client name. Furthermore, you have security options and message options. It’s all well explained.
MQTT in
The NodeRED is actually one of the clients too. The broker runs independently, and the NodeRED subscribes or publishes to topics. To subscribe and receive a message from a topic (like weather temp from a sensor) you need an input MQTT node with a correct topic subscription (case sensitive).
The QoS (message levels – Quality of Service) defines how the message is processed:
- QoS 0 – at most once (not checking if the message is actually delivered)
- QoS 1 – at least once (message is checked, duplicates possible)
- QoS 2 – just once (message is received only once, confirmed)
The message is delivered as a payload which can be then processed further by the NodeRED. It’s worth noting that MQTT is best suited for a data streams. Rather than sending JSON objects take the advantage of the topic system. It was beneficial to push a JSON file:
{"temp": 23, "humid": 80};
via HTTP POST, but the same message should be posted as data updates to 2 topics instead: the temp and the humid. Always consider the type of data sent to your NodeRED and the best possible data transfer protocol.
MQTT out
Publishing a message to a topic is very easy. NodeRED has already the topic system in place, which means you can specify the publishing topic by setting the msg.topic value instead of hardcoding that information into the MQTT output node. Then all you need to do is to pass the payload which will be pushed to all subscribed clients.
As before, consider the data type when pushing the information over. The message is sent as a string. It may be more beneficial to publish the message on several topics, rather than play with the string formatting later.
Android integration – Join and AutoRemote
One of the most amazing things about NodeRED is how easy it is to connect it to pretty much everything. Android devices can take advantage of Join App (and join node) and the AutoRemote Tasker plugin, extending the home automation to mobile devices.
You can not only send the information about what’s going on with your NodeRED server, but you can send the commands, files and other data both ways. If you want more details specifically about the Join node – please see the Join Node guide I posted before. In this section, I will only do a short overview of what the Join Node and AutoRemote are capable of.
Sending messages to the NodeRED is not problematic, as the server always runs at the same IP address. This is not the case when you are trying to reach a mobile phone connected to the internet via mobile networks. Join uses Google services to deliver the messages regardless of the IP.
Join Node
To use the node follow the guide. In brief, you will be able to send any information obtained by Tasker from your mobile and pass it to the NodeRED as an object. The same goes for the NodeRED to Android – the Join message/command – can issue a ready notification or trigger a task in Tasker on Android or EventGhost running on a PC.
AutoRemote
Currently, the Join app is capable of anything that AutoRemote is. You could think of the AutoRemote as the legacy solution. If you are still interested – see the hookup guide.
IFTTT
The IFTTT is known for integrating big brands and small automating systems. This means that the services that support IFTTT can send the information directly to your NodeRED via Webhooks (HTTP Requests).
You will need an HTTP input node (see HTTP requests) to received the Webhook from IFTT. I’d recommend that you send the data from IFTTT to NodeRED as JSON formatted file.
The Webhooks come with a specific to your account URL (and key at the end of that URL) which can be used with the Node node-red-contrib-ifttt.
sudo npm install node-red-contrib-ifttt
You can actually use that URL to send the web requests – but since the node is here – you might as well make your life easier and use the node instead to trigger other IFTTT recipes.
I’m sending a web request with an event TEST, which will trigger the Webhook IF:
And you are now ready to configure your own IFTTT applets.
Conclusion
As you can see NodeRED can connect to many different services. Search through npm flows in palette manager and on GitHub if you are interested in more specific nodes. So how about a nice working example to follow this up? I will show you how to make a custom RSS reader and send the updates to your phone. In the next part, I’m going to explain the basics of the function node, what cool things you can do with it. Be warned though, I’m going to teach you basics of JavaScript. If you enjoyed the tutorial so far – consider buying me a coffee!