IoT Blog: Connecting Things

I believe one of the most practical ways to learn how to harness the Internet of Things (IoT) in a business or industry is to demonstrate a basic use case and show exactly how to connect your smart devices so they can start providing useful data. Once you learn the technologies that make IoT work and how to make connections, you'll suddenly begin to see the endless possibilities IoT offers.

A simple use case in the Industrial Internet of Things (IIoT), is collecting data from a sensor, transmitting it over the internet, and displaying that data to whoever or whatever needs it. The challenge here is how do you connect your sensor or smart device to the application or dashboard where people need to make decisions based on that sensor data. A project I completed recently was the perfect opportunity to showcase in detail how to make these connections. This article is meant to connect the dots and show the specific technologies, strategies, and tasks required to make use of IoT devices.

To give you a concrete idea of how IoT sensors can be used, let's say I have a finishing department where I'm applying a coating that is sensitive to temperature and humidity. All my operators as part of their procedures need to be aware of the environmental conditions before using the coating. Wouldn't it be great if we made that information available to them on a screen right where we need it? If you follow along you'll learn everything you need to make a system like that.

Recently I was asked to make use of a Monnit Alta IoT temperature sensor to monitor shop temperature and display the temperature data on many client PCs. You can checkout the Monnit Alta temperature sensor here. Monnit's iMonnit Cloud Platform provides a portal to manage your sensors and display their data.

It so happens that each of the work cells the operators are in, have a PC running an HMI application. So the question is, "How do I get the data from iMonnit's cloud platform to my 20 or so PCs running my HMI?"

Let's start at the source of the data. The Monnit Alta temperature sensor takes a measurement and transmits the temperature value to the Monnit Gateway over a local radio network. Meanwhile the Monnit Gateway is plugged into ethernet, and is able to forward the temperature data to the iMonnit Cloud platform. So far this is what the stack looks like:

Now once we've gone through the iMonnit setup process, we are able to log into our iMonnit dashboard and see the current shop temperature.

Great! So how do we get that data out to the client PC's? Luckily iMonnit gives you two methods to retrieve sensor data. A REST API or a webhook. If you're not familiar with REST APIs, I recommend this article. In short though, a REST API interacts with a service like iMonnit and retrieves the data you are looking for. It makes an HTTP request to a URL just like your browser does, but instead of returning a webpage, you get a string of data. A webhook is the same concept but instead of you asking for data, a webhook sends data to a URL of your choosing as new data becomes available.

While I could have chosen to use either the REST API or webhook, I chose the webhook. When it comes to moving data around I prefer pushing data rather than polling for data. My reasoning here is that its wasteful to constantly ask for updated data when there is none to give. I'd rather receive new data when it becomes available. It's the equivalent being on a road trip and your 4 year old keeps asking "Are we there yet? Are we there yet?"

Now that we've decided to use the webhook, there are still some things we need to figure out. First, our webhook needs somewhere to go (an "endpoint"). This normally would be a server application running somewhere waiting for the webhook to come in. I'll explain how to handle that a bit later on.

We also need some middleware to distribute the data out to the client HMI PCs. Ultimately, we are trying to achieve this architecture:

For the middleware, I chose to add an MQTT broker to the architecture. The MQTT protocol allows IoT devices and applications to send messages to each other through a system of publishing and subscribing. A device can publish data to the broker under a “topic”. In this case our topic is “Shop/Temperature”. Another device can then subscribe to a topic. When a new message is published under a subscribed topic, the broker is responsible for delivering the message to any device that is subscribed to that topic. For this job I chose HiveMQ's fully managed Cloud Broker

When we add the MQTT broker in, this is what our architecture looks like:?

Next we need to create an "endpoint" for the webhook to send it's data to. While there are some MQTT brokers out there that have built in interfaces for webhooks and REST APIs, our version of HiveMQ only handles MQTT messages. So our endpoint will also translate our webhook data into an MQTT message.

The solution I came up with here was to spin up an Azure Function App to parse the incoming the temperature data, then publish the data to the HiveMQ broker under the "Shop/Temperature" topic. I chose Azure Functions because it essentially gives you a platform to run your code without having to worry about managing a whole server or virtual machine. You also save money on CPU usage since the Azure function only runs when a request is made to it. AWS can do the same with Lambda functions. This technology is commonly referred to as "serverless". You can checkout my GitHub repo for the function here: https://github.com/greenbean209/webhook-mqtt-bridge

Here is the gist of how the webhook-mqtt-bridge function works. (1) The iMonnit Webhook is configure to target the URL our our Azure Function. (2) The Azure Function listens for an incoming HTTP POST request from iMonnit Webhook to trigger the function to execute. (3) The function connects to the HiveMQ Broker. (4) The function reads the data from the JSON in the body of the webhook's POST request. (5) The function publishes the temperature data. (6) The function disconnects from the broker, then ends.

In short, iMonnit data comes in as a JSON string looking like this:

{
? ? "sensorMessages": [
? ? ? ? {
? ? ? ? ? ? "sensorID": "123456",
? ? ? ? ? ? "sensorName": "Shop\/Temperature",
? ? ? ? ? ? "applicationID": "2",
? ? ? ? ? ? "networkID": "12345",
? ? ? ? ? ? "dataMessageGUID": "918c1d16-3bee-4fcd-bb57-de7f6ea513f1",
? ? ? ? ? ? "state": "18",
? ? ? ? ? ? "messageDate": "2022-03-23 14:45:20",
? ? ? ? ? ? "rawData": "21.5",
? ? ? ? ? ? "dataType": "TemperatureData",
? ? ? ? ? ? "dataValue": "21.5",
? ? ? ? ? ? "plotValues": "70.7",
? ? ? ? ? ? "plotLabels": "Fahrenheit",
? ? ? ? ? ? "batteryLevel": "100",
? ? ? ? ? ? "signalStrength": "100",
? ? ? ? ? ? "pendingChange": "True",
? ? ? ? ? ? "voltage": "3.08"
? ? ? ? }
? ? ]
}        

And get's published to the MQTT broker looking like this:

Topic: "Shop/Temperature/sensorID" ? ? ? ? ?Value: "123456"
Topic: "Shop/Temperature/sensorName" ? ? ? ?Value: "Shop\/Temperature"
Topic: "Shop/Temperature/applicationID" ? ? Value: "2"
Topic: "Shop/Temperature/networkID" ? ? ? ? Value: "12345"
Topic: "Shop/Temperature/dataMessageGUID" ? Value: "abc-123-456"
Topic: "Shop/Temperature/state" ? ? ? ? ? ? Value: "18"
Topic: "Shop/Temperature/messageDate" ? ? ? Value: "2022-03-23 14:45:20"
Topic: "Shop/Temperature/rawData" ? ? ? ? ? Value: "21.5"
Topic: "Shop/Temperature/dataType" ? ? ? ? ?Value: "TemperatureData"
Topic: "Shop/Temperature/dataValue" ? ? ? ? Value: "21.5"
Topic: "Shop/Temperature/plotLabels" ? ? ? ?Value: "70.7"
Topic: "Shop/Temperature/plotLabels" ? ? ? ?Value: "Fahrenheit"
Topic: "Shop/Temperature/batteryLevel" ? ? ?Value: "100"
Topic: "Shop/Temperature/signalStrength" ? ?Value: "100"
Topic: "Shop/Temperature/pendingChange" ? ? Value: "True"
Topic: "Shop/Temperature/voltage" ? ? ? ? ? Value: "3.08"        

The readme in the GitHub repo has the details on how to deploy the webhook-mqtt-bridge function for yourself.

With the Azure function in place, this is what our architecture looks like now:

Now that we have our bridge function setup, we just need to point our iMonnit to the function as the endpoint. Under the "API" section on your iMonnit portal, select "Configure Webhook". You see the below page. Fill in the URL of your function. You may also need to fill in credentials, and a custom header with your API key, depending on your Azure setup. Normally when you create an Azure function, the URL it gives you includes the default API in the URL.

Now that we established a connection between iMonnit and our broker via the bridge function, we can connect to our MQTT Broker with an MQTT client and subscribe to the "Shop/Temperature" topic, and our client PCs will get the new temperature reading as soon as the Monnit temperature sensor reads a new value.

I can't show the HMI application I used, but instead I'll show how you can quickly create a dashboard using Node-RED. Node-RED is a node.js library that allows you to create data "flows". A node-red flow consists of "nodes" and "wires." Nodes perform functions like subscribing or publishing to an MQTT broker. Wires represent data connections between nodes. There are also libraries for all sorts of other functions. In this case we will use an addon library for making dashboards.

Lets make a node-red dashboard.

First you'll need the node.js runtime. Node.js is too big of a subject to cover here, but in short node.js lets you run javascript code locally on your PC (or server or any computer). Node-RED happens to be written in javascript so we need the node.js runtime to run it.

Once we've installed node.js we can install node-red. Open a command line and run these commands:

npm install -g --unsafe-perm node-red        

You should see an output like:

+ [email protected].
added 332 packages from 341 contributors in 18.494s
found 0 vulnerabilities0        

Next we'll install the node-red dashboard library:

npm install node-red-dashboard        

For the next part to work you may need to restart your terminal. Run this to start node-red:

node-red        

Once node-red starts you can use your browser to navigate to "https://localhost:1880"

This is the Node-RED editor. You'll start with a blank screen. This empty screen is called a flow, we just need to fill it with nodes and wires to program it to do what we need.

Lets pull in a few nodes. We'll need an "mqtt in" node, "json" node, and a "gauge" node. The "mqtt in" node lets use subscribe to a topic on a broker. The "json" helps format our data. And the "gauge" node creates a gauge object on our UI we will make. Our flow will look like this so far:

Next we'll wire our nodes together like this:

Now we need to setup our mqtt node. Double click on the node and you get a setup screen. The first thing we have to do is add a broker connection.

Click on the edit icon next to the server field. You'll get another screen where you can input the MQTT broker address, login credentials, and security settings.

Click add and you'll return to the mqtt in node setup screen. I'll fill in the subscription topic with my desired topic "Shop/Temperature/dataValue"

Hit done and you'll be taken back to your flow. Now double click the gauge node and let's set that up. Hit the edit button next to the group setting. Then on the group settings page well hit the edit button next to the Tab setting. On the Tab page the default settings are fine, go ahead and hit add. You'll be taken back to the Group page. Hit Add again. Finally we are back on the gauge node setup page. You can add stuff here to format you gauge. We won't bother for now. Hit done to finish setting up the gauge node.

Now that we've finished all our setup we try out our dashboard. First hit the deploy button on the upper right to save all the changes we've made to the flow. Then navigate to "https://localhost:1880/ui". If you've done everything right, your node-red flow will have connected to the MQTT broker, subscribed to the "Shop/Temperature/dataValue" topic, and if new data has been published to the broker from our webhook-bridge azure function, you should see the temperature from our Monnit Alta temperature sensor displayed on our gauge object. It should look something like this:

And there we go, we have our temperature displayed on a screen right where we need it!

While what we've made here still needs some polish and refinement, with a little more effort this can be used in production.

Here's some food for thought before ending this post. The great thing about this architecture is that with MQTT as the hub of data exchange, it reduces our engineering effort to add more connections. Let's talk about how to expand this.

So what if we wanted add some other things in here? Let's say we have a pressure sensor attached to a PLC (newer PLCs are shipping with MQTT instructions now) and we want display pressure on our client PC. And let's say we have another cloud platform we are getting sensor data from. Finally lets say we wrote another app that displays this data on a supervisory dashboard. What would that look like?

Basically, with any future integrations, we ask one question, "How do we get the data to the MQTT Broker?" We don't need to worry how Cloud Platform A talks to Client B. We just need to make sure every node can connect to the broker, and if there is a topic with the data we want, we can subscribe and get that data.

You can even make a whole enterprise SCADA system with MQTT as the backbone of data exchange.

I hope this blog/tutorial has helped you get a better understanding of how to move data from your IIoT sensors and?present it to the people and applications that need it.