The Raspberry Side: MQTT Bridging
Installing Mosquitto and the related CLI utilities on a Pi is straightforward, by issuing the command sudo apt install mosquitto and sudo apt install mosquitto-clients. Once started, you can check the status by issuing the command systemctl status mosquitto, which should be followed by
Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor
Active: active (running) since Tue 2021-03-30 17:22:35 CEST; 19h ago
Main PID: 635 (mosquitto)
Tasks: 1 (limit: 4915)
└─635 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
and proceed to modify the /etc/mosquitto/conf.d/mosquitto.conf file configuring the bridging mechanism. Most of the default parameters are just fine (unless you want to setup an encrypted connection between microcontrollers and the edge instance). In our case we'll just configure the bridge, so using our favorite editor of choice, even if your favorite search engine suggests otherwise(!):nd proceed to modify the /etc/mosquitto/conf.d/mosquitto.conf file configuring the bridging mechanism. Most of the default parameters are just fine (unless you want to setup an encrypted connection between microcontrollers and the edge instance). In our case we'll just configure the bridge, so using our
favorite editor of choice, even if your favorite search engine suggests otherwise(!):
and reaching the Bridges section:
# A bridge is a way of connecting multiple MQTT brokers together.
# Create a new bridge using the "connection" option as described below. Set
# options for the bridges using the remaining parameters. You must specify the
# address and at least one topic to subscribe to.
we can add the following parameters:
topic # out 0 "" edge/
topic alarm in 0 cloud/ edge/
Where the host and port parameters are the public IP address and the of the OCI instance we configured
in the first episode, and the other parameters indicate that:
- in the first line, we're going to relay all messages to the Cloud instance (prefixed by the edge/
parameter), so all the messages issued on the the edge in the topic device/machine/x will be
processed by the Cloud Mosquitto as edge/device/machine/x.
- in the second line, we'll receive any message from the Cloud in the topic alarm, specifying the
cloud/ prefix and locally processed in topic cloud/alarm.
Sure enough, we also need to setup the certificate based SSL/TLS support, so reach for the section
regarding security and complete it with:
# Certificate based SSL/TLS support
# Either bridge_cafile or bridge_capath must be defined to enable TLS support
# for this bridge.
# bridge_cafile defines the path to a file containing the
# Certificate Authority certificates that have signed the remote broker
# bridge_capath defines a directory that will be searched for files containing
# the CA certificates. For bridge_capath to work correctly, the certificate
# files must have ".crt" as the file ending and you must run "openssl rehash
# [path to capath]" each time you add/remove a certificate.
# Path to the PEM encoded client certificate, if required by the remote broker.
# Path to the PEM encoded client private key, if required by the remote broker.
# When using certificate based encryption, bridge_insecure disables
# verification of the server hostname in the server certificate. This can be
# useful when testing initial server configurations, but makes it possible for
# a malicious third party to impersonate your server through DNS spoofing, for
# example. Use this option in testing only. If you need to resort to using this
# option in a production environment, your setup is at fault and there is no
# point using encryption.
thus creating a certs directory under /etc/mosquitto and copying the ca.cert, server.crt and
server.key files we generated during the first episode in section Secure the MQTT Server running on
That is easy to test. Issuing a listening command to the Cloud instance in a shell, as shown in the first
mosquitto_sub -d -t '#' -h [your host] -u [username] -P [password] -p [port] --insecure --cafile certs/ca.crt --cert certs/server.crt --key certs/server.key
and sending a message to the local Raspberry Pi
mosquitto_pub -h [your RPi IP address] -t test -m 'Sympathetic resonance'
we should receive on the Cloud Mosquitto shell the message:
Client (null) received PUBLISH (d0, q0, r0, m0, 'edge/testtopic', ... (21
showing that the two thingies are effectively talking themselves - albeit in a single direction, for now.
The pipelines we'll design in Stream Analytics will provide the logic to test the bidirectional dialogue. And,
now, let's have some healthy fun with sensors!