So, it is time to dive into this protocol by running an MQTT broker on the edge and consuming it:
Yes, we are going to deploy a regular MQTT broker as a docker container within Azure IoT Edge (which uses Moby under the covers). Then, we bridge messages sent to MQTT topics to the cloud using Azure IoT Hub.
For this exercise, I have chosen HiveMQ as a broker.
Most of you Azure IoT developers are connecting devices to the Azure cloud using the Azure IoT Device SDKs.
Using these SDKs, you can connect a device to the cloud in an easy and secure way with your favorite programming language like C#, C, Java, Python, or Node.js.
This is the recommended way because it offers a convenient and optimized way to support all Azure IoT Hub features like Device Twin, Direct methods, and Cloud messages. It takes away a lot of the code wiring and you can focus on functionality.
Still, in a few instances, like working with very constrained devices, there could be a need for bare MQTT support:
MQTT is the de-facto standard for stateful communication in the IoT World (btw. Bare AMQP is offered too).
Let’s see how the Azure IoT Hub supports bare MQTT.
Do you have cloud-connected IoT devices to the Azure IoT Hub and have you specified the specific public ‘Baltimore’ TLS certificate currently in use by the IoT Hub? Do you know customers having (low-powered) devices connected to Azure IoT and possibly pinned that certificate?
Azure Digital Twins is advertised as a “platform as a service (PaaS) offering that enables the creation of twin graphs based on digital models of entire environments, which could be buildings, factories, farms, energy networks, railways, stadiums, and more—even entire cities”.
This sounds promising but it does not really ring a bell, does it?
Fortunately, besides the excellent documentation, Microsoft provides a great learning path in MS Learn as part of the AZ-220 Azure IoT developer exam preparations.
There, you will learn how Azure Digital Twins offers new opportunities for representing an Internet of Things solution via twin models, twin relations, and a runtime environment.
You finish the learning path with a hands-on lab where you build a model around a cheese factory and ingest sensor telemetry:
In the demo, the telemetry flows through the runtime and ends up in Time Series Insights.
Yes, the learning path is a good start and will prepare you for the exam or the assessment (you need to pass this assessment for a free one-year certification renewal).
On the other hand, many extra features could be added to turn this good start into a great start!
Think about propagating Azure Digital Twins events and twin property changes through the graph and visualizing live updates of twins in a 3D model, complete with alerts.
Let’s check out some of these additional features and see what you need to do to extend the ADT example.