In this chapter, we will create a server application to visualize data that has been sent from an edge device in the IoT, using Node-RED. For a server-side application, I would like to use the IBM Cloud here. By following the tutorials in this chapter, you will master how to visualize sensor data on a server application.
Let's get started with the following topics:
By the end of this chapter, you will have mastered how to visualize sensor data on cloud platforms.
To progress in this chapter, you will require the following:
Recall the previous chapter, Chapter 10, Handling Sensor Data on the Raspberry Pi. We sent the data of the temperature/humidity sensor, which was connected to the edge device (Raspberry Pi), to the cloud and confirmed that the data could be observed on the cloud side.
In the previous chapter, we checked how to operate an MQTT broker using a service called Mosquitto. This was in order to focus on sending data from edge devices to an MQTT broker.
However, this was a mechanism where everything was done locally on the Raspberry Pi. Essentially, when trying to implement an IoT mechanism, MQTT brokers should be in a public location and accessible from anywhere via the internet.
It is possible to host your own Mosquitto MQTT broker in the public cloud, but that adds some extra complexity in terms of setting up and maintaining it. There are a number of public MQTT services available that can make it easier to get started.
In this chapter, we will use a service called CloudMQTT for the MQTT broker, but you can replace the MQTT broker part with your favorite service. You can also publish your own MQTT broker, such as Mosquitto, on IaaS instead of using SaaS:
Important note
An MQTT broker is a server that receives messages from the publisher and sends them to subscribers.
The server that delivers messages in PubSub is called the MQTT broker.
PubSub is an amalgamation of the words Publisher and Subscriber:
a) A publisher is a person who delivers a message.
b) A subscriber is a person who subscribes to a message.
You can think of it as a server that receives messages from clients and distributes them to clients.
MQTT differs from ordinary socket communication in that it communicates on a one-to-many basis. In other words, it has a mechanism to distribute the message of one client to many people. This system allows us to deliver messages to many people simultaneously in real time.
We will now learn how to prepare for CloudMQTT. As mentioned previously, CloudMQTT is an MQTT broker published as SaaS. If you don't use CloudMQTT and want to use another SaaS MQTT broker or publish an MQTT broker on IaaS, you can skip this step. However, the basic configuration information for using an MQTT broker remains the same, so I believe this step will help you configure any MQTT broker.
Perform the following steps to create an MQTT broker service on CloudMQTT:
When you access the website, click the Log in button at the top right of the window:
If you already have your CloudMQTT account, log in to your account by entering your email address and password:
If you don't yet have your account, please create a new account via the Sign up button at the bottom of the window:
After logging in, click the Create New Instance button in the top-right corner of the window:
This name is for your MQTT broker service. You can give it any name you want. I have used Packt MQTT Broker.
Unfortunately, the free plan, Cute Cat, is no longer available. So, we will select the cheapest plan, Humble Hedgehog, here. This plan costs $5/month.
It's up to you to use this paid service. If you want to avoid billing, you need to look for a free MQTT broker service.
After selecting the name and payment plan, click the Select Region button:
This service is running on AWS. So, you can select a region where the data center is placed. You can select any region. Here, we are using US-East-1.
Please check the payment plan, service name, service provider, and data center region. After that, click the Create instance button to finalize creation of this instance:
In this section, we will configure our Raspberry Pi. To get started, launch the Raspberry Pi and open the Node-RED flow editor. This Node-RED flow editor should still have a flow to send the sensor data implemented in Chapter 10, Handling Sensor Data on the Raspberry Pi, to the server. If you have deleted this flow, or if you have not created it, please re-execute it by referring to Chapter 10, Handling Sensor Data on the Raspberry Pi. Double-click the mqtt out node that makes up the flow to open the settings window. We used Mosquitto last time, but this time we will connect to CloudMQTT.
Perform the following steps to configure Node-RED on the Raspberry Pi to connect to CloudMQTT:
In this chapter, we only use a flow with the mqtt out node because this scenario is just for sending data to a Raspberry Pi:
We now need to edit the connecting configuration. Open the settings window of the mqtt out node by double-clicking on it:
Set the configuration to connect to CloudMQTT.
Set the Topic, Qos, and Retain values as follows:
The other properties in the Connection tab are not supposed to be changed and must be kept at their default values.
You can refer to the following screenshot for the Connection tab settings:
You can refer to the following screenshot for the Security tab settings:
You can check these properties at the CloudMQTT admin menu. This menu can be accessed via the Instances list of the CloudMQTT dashboard: https://customer.cloudmqtt.com/instance
This completes the settings on the Raspberry Pi side. Next, let's set up the Node-RED flow editor so that data can be acquired (subscribed) with Node-RED on the cloud side.
In this section, we will see how to visualize the received data with Node-RED on the cloud side. This uses one of the dashboard nodes as we learned in Chapter 6, Implementing Node-RED in the Cloud, but this time, we'll choose Gauge's UI to make it look a little better.
The cloud-side Node-RED used this time runs on the IBM Cloud (PaaS), but CloudMQTT, which created the service as an MQTT broker earlier, is a cloud service that differs from the IBM Cloud.
In this chapter, we will learn that an MQTT broker exists so that it can be accessed from various places, and that both publishers (data distributors) and subscribers (data receivers) can use it without being aware of where it is.
Now, let's create a Node-RED flow connected to CloudMQTT by performing the following steps. Here, we will use Node-RED on the IBM Cloud. Please note that it is not Node-RED on the Raspberry Pi:
If you have not created a Node-RED service on your IBM Cloud, please refer to Chapter 6, Implementing Node-RED in the Cloud, to create one before moving ahead.
When you accessed your Node-RED flow editor on your IBM Cloud, create a flow as follows. Place the mqtt in node, json node, two change nodes, and gauge node after each change node. If you want to get the debug log for this flow, please add the debug node after any node. In this example, two debug nodes are placed after the mqtt in node and the first change node.
You already have the dashboard nodes, including the gauge node. If you don't have them, please go back to the Make a flow for use case 2 – visualizing data tutorial in Chapter 6, Implementing Node-RED in the Cloud, to get the dashboard nodes:
You can refer to the following screenshot for the Security tab settings:
As you may have already noticed, these properties have the same values that you set for the mqtt out node on the Raspberry Pi Node-RED. Please refer to the CloudMQTT dashboard if necessary.
Other properties are not supposed to be changed from their default values. You can refer to the following screenshot for the settings:
Other properties are not supposed to be changed from their default values. You can refer to the following screenshot for the settings:
Please make sure to deploy the flow on your Node-RED.
This completes the Node-RED configuration on the IBM Cloud. This means that this flow is already subscribing (awaiting the data) with the topic packt for the CloudMQTT service. Next, it's time to publish and subscribe to the data.
On the edge device side, on the Raspberry Pi, we are ready to publish the sensor data to CloudMQTT with the topic packt. On the cloud side, the flow is already with the packt topic for the CloudMQTT service.
For a Raspberry Pi, perform the following steps to publish your data:
Access your Node-RED flow editor on your Raspberry Pi. Click the button of the inject node to run this flow for publishing grove temperature and humidity sensor data:
You will be able to receive (subscribe) the data via CloudMQTT. You can check it on the debug tab on your Node-RED flow editor on the IBM Cloud:
You will see the web page gauge chart with the data displayed:
Congratulations! Now you know how to observe the data sent from the Raspberry Pi on the server and visualize it as a chart.
If you want the flow configuration file to make this flow on your Node-RED, you can get it here: https://github.com/PacktPublishing/-Practical-Node-RED-Programming/blob/master/Chapter11/getting-sensordata-with-iotplatform.json.
In this chapter, we experienced how to receive the sensor data sent from an edge device and visualize it on the server side.
In this chapter, we used CloudMQTT and Node-RED on the IBM Cloud. Node-RED can run on any cloud platform and on-premises, and you can try to make this kind of application in any environment. That's why remembering this pattern will definitely be useful for your future development with other cloud IoT platforms.
In the next chapter, we will look at a hands-on scenario of making a chatbot application with Node-RED. This will introduce you to a new way of using Node-RED.
44.222.231.51