Create Your Own IIoT Tech Stack Project | Part 2: Testing The Data Payload

Configuration File

We left off our previous tutorial article (part 1) with the definition of a publisher script for the Raspberry Pi acting as our edge device in the IoT project. Here, we will pick up with defining the config.json file using an SSH connection to the Pi, similar to before.

In the parent directory of your project, create another file called “config.json” using the touch command. It should look something similar to the below environment:

 

Figure 1. Terminal output for the architecture of the project directory. Image provided by the author

 

This may not be clear purely from a command line tool, so I’ve provided a complimenting visual architecture diagram below.

 

Figure 2. Visual of the architecture for the project directory. Image provided by the author

 

We’ll use the nano editor to access the config.json file and create our key-value pairs.

nano config.json

 

Within the file, we will add a topic and broker key-value pair below. The hierarchical topic can be anything you would like to use.

The broker we will use for our project is a free public MQTT broker offered by HiveMQ. It lacks a few of the security and other advanced features available from some alternative broker services, however, it is a good option for quickly checking development work for hobby project data that does not require security.

{
"topic": "building1/apt1/livingroom",
"broker": "broker.hivemq.com"
}

 

The broker address was obtained from HiveMQ. Please note the security disclosure regarding the broker: do not use this broker for sensitive enterprise data:

 

Figure 3. HiveMQ sandbox broker with the security warning. Image used courtesy of HiveMQ

 

Running the Pi as a Publisher MQTT Client

Now that we’ve provided the necessary values to connect the sandbox broker, we can run the publish script (publisher.py) to test. Enter python3 followed by the python script filename we built in part 1. You should see the messages from reading the config file and connecting to the broker correctly:

 

Figure 4. Transmitting a payload message to the MQTT broker. Image provided by the author

 

The sense HAT will also flash green 3 times, similar to this static image below:

 

Figure 5. Successful connection to the MQTT broker. Image provided by the author

 

Viewing Payload from MQTT Broker

The successful connection to the broker and green lights are great, but how can we verify that the payload is arriving at the broker end? After all, we utilized a qos of 0, which is the equivalent of a fire-and-forget message from an MQTT client defined by the protocol. One method would be to create a complimentary subscriber.py script on a local laptop utilizing the same paho-mqtt library. Since this script is more or less disposable, a copy/paste example can be found below.

import paho.mqtt.client as mqtt
import json

with open("config.json", "r") as jsonfile:
    data = json.load(jsonfile)
    print("Configuration read successful")
broker = data["broker"]
topic = data["topic"]

# Define callback functions
def on_connect(client, userdata, flags, rc):
    print("Connected with result code "+str(rc))
    client.subscribe(topic)

def on_message(client, userdata, msg):
    print(f"Received message '{msg.payload.decode()}' on topic '{msg.topic}'")

client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message

client.connect(broker, 1883, 60)
client.loop_forever()

 

It will use the same config.json file earlier placed in the same project directory as the subscriber.py script. It’s the same architecture of the solution on the Pi, just mirrored on a local subscriber machine. A view of what the folder structure looks like locally in an editor such as VS Code can be found below.

 

Figure 6. Folder structure for the local project. Image provided by the author

 

Thus, we’ve created a subscriber out of our laptop and a publisher out of the Pi, utilizing a cloud broker to facilitate communication. A visual representation of the sandbox test environment is below.

 

Figure 7. Block diagram representation of this system. The Pi is publishing the payload data to the broker, the laptop is subscribing (reading) the payload from the broker. Image provided by the author

 

Running the subscriber.py script from a terminal on your local PC resembles below (understanding that the message values would be unique for my own machine).

(venv) mlevanduski@Michaels-Air mqtt % python3 subscriber.py
Configuration read successful
Connected with result code 0
Received message '{"hostname": "raspberrypi", "temperature": "31.196216583251953", "pressure": "926.226806640625", "humidity": "36.17510223388672"}' on topic 'building1/apt1/livingroom'

 

Great news! Our payload is arriving at the subscriber, clearly indicating that data is flowing from the sense HAT sensors to the HiveMQ broker and ultimately to our local machine.

 

Big Picture Goal

Seeing the forest from the trees, our ultimate goal is to create a personal Mosquitto broker that is not public; one to which we can apply authentication and enhanced security.

As mentioned at the end of the part 1 article, there is a greater technical load of standing up our own broker. We took a detour and journeyed into the weeds a bit in this article to quickly prove that the Raspberry Pi publisher script functioned as expected. In the next article in this series (Part 3), we’ll dive deeper into the setup of a Mosquitto broker.