In this article, you will discover how Proximus makes it easier to automate the integration of LoRaWAN sensors connected to our national public LoRa network with the Microsoft Azure IoT Hub. We will indicate that this integration can go far beyond just forwarding messages to an event hub.
The Azure IoT Hub
The Azure IoT Hub has become a very popular service to ingest IoT data over the last years. At least, for companies or developers who want to leverage Microsoft’s cloud capabilities in building their IoT solution. The IoT Hub is basically the standard cloud entry point in Microsoft’s own IoT Reference Architecture. It comes with several key additional features over the Azure Event Hub, such as:
- Concept of device and device twins, with associated device capabilities, reported and desired properties
- Support of both device-to-cloud and cloud-to-device messaging
- Access right management at device level
As Microsoft states in this comparison article of IoT Hub and Event Hubs :
“the IoT Hub includes features that enrich the relationship between your devices and your backend systems. Bi-directional communication capabilities mean that while you receive data from devices you can also send commands and policies back to devices”
LoRaWAN devices and Azure IoT Hub
Some questions will arise when including LoRaWAN devices and sensors in an IoT project leveraging Microsoft’s IoT Reference Architecture:
- How do I prevent to double my device management activities?
- How do I get my LoRaWAN device data into the right IoT Hub device?
- Is there any way to make use of the IoT Hub’s device twin feature?
This means, when considering a tighter integration of Proximus LoRaWAN and the Azure IoT Hub, we want to solve these challenges:
- Integrate device management end-to-end: when a device is created or deleted on the LoRa network, the same action should be taken on the IoT Hub. Depending on the device’s provisioning status on the network, we will want the corresponding IoT Hub device’s status set as active or inactive.
- Sensor data must flow to the right IoT Hub device: when new sensor data is generated and sent over the LoRaWAN network, it should be forwarded to the corresponding IoT Hub device. This instead of being just sent to “the hub”, like it would be with the Azure Event Hub.
- Leverage “desired” and “reported” properties: it is perfectly possible to leverage an IoT Hub device twin’s “desired and reported”. For instance, setting a desired property like “report interval” to 60 (minutes) may trigger a LoRa downlink message to configure the device accordingly.
Proximus MyThings and CloudEngine to the rescue
MyThings is the device management platform from Proximus to connect, configure Things. But, also to connect the data from LoRaWAN devices to our national network. This web-driven management platform also exposes all its device management functionalities via REST API and can forward device data to an HTTP endpoint (your application). These are not the features we will leverage to implement the scenarios above. We will leverage the Proximus CloudEngine which comes with 2 dedicated modules to deal with Azure IoT Hub integrations:
- The Azure IoT Manage Device module: to manage the lifecycle of IoT Hub devices by creating, updating and deleting devices, reading or setting device keys and setting a device status.
- The Azure IoT Device module: for device to cloud messaging and dealing with device twin properties.
These modules support various transport protocols to address the IoT Hub: HTTPS, MQTT and AMQPS.
Integration CloudEngine and the MyThings platform
The CloudEngine comes with a standard integration with the MyThings platform, implemented as 2 input endpoints:
- MyThings – Things: MyThings sends events to CloudEngine for every add, delete, update, provision or deprovision on a device. These events can either come from the MyThings UI or the MyThings REST API.
- MyThings – Data: all incoming data from the connected LoRaWAN devices. This inflow can be further filtered based on tags, device address or other such attributes.
Putting all these components together, our implementation will look as the schema below.
In this implementation, using the standard components listed above and the scripting capability of the Proximus CloudEngine:
- Every time CloudEngine receives an event from MyThings about a new device being created, deleted, provisioned or deprovisioned on the network, a CloudEngine script is triggered to reflect the very same operation on the IoT Hub
- Every time sensor data is forwarded by MyThings to CloudEngine, a script identifies which IoT Hub device should be matched with that physical LoRaWAN device, and sends the sensor data to it as a device-to-cloud message (D2C)
- Changes to the device conditions (like its battery level or radio signal quality) are reported as “reported properties” on the matching device twin.
Now it’s your turn!
In our Github, you will find two sample scripts reflecting this implementation scenario. One script is dealing IoT Hub device CRUD (create, update, delete) operations. The second script handles device-to-cloud messaging. Once you are all set up with your scripts and IoT Hub, you’re ready for the next steps. You can start to leverage storage, analytics and machine learning capabilities of Azure.
With the CloudEngine, Proximus makes it easier than ever to address more complex IoT integration scenarios. This goes far beyond capabilities offered by other network operators. Next to the Azure IoT Hub, we also provide integration modules for Azure Event Hub, SAP IoT Leonardo, HTTP(S), sFTP, MQTT client and MQTT broker.