Using a Weidmueller UC 20 Controller as Azure IoT Edge child device

Azure IoT Edge is a powerful solution for your edge computing needs. It can collect telemetry, make local decisions, and send data to the cloud. This works great if an internet connection is available. If the connection is temporarily broken, everything still works. The telemetry is temporarily persisted so no data is lost.

An edge gateway can also act as a transparent gateway:

Here, child devices are made part of the local routing mechanism of the edge. The child devices are configured to send their telemetry to the edge device. From there, the same telemetry is sent to the cloud as if it’s sent by the child device itself.

The main advantages are:

1. If no internet connection is available, the child telemetry is stored on the edge until the connection is restored. The child devices have no notion of the edge gateway, hence ‘transparent’
2. The logic running on the edge is able to access the telemetry coming from child devices so this can be used and combined with other data to take local decisions

This architecture is also known as downstream devices.

I already wrote a blog on this topic previously. In there, some test apps stole the show.

Now, let’s see this in action with an actual industrial device. We also check out sending telemetry back:

We will be working with a Weidmueller UC20, an automation controller.

Expanding Raspberry PI I/O using I²C on Azure IoT Edge

The GPIO of a Raspberry gives you the opportunity to interact with the physical world using digital pins and various IO busses like SPI and I²C.

In the past, in this blog, I already demonstrated how to access the GPIO of a Raspberry Pi.

In the last few months, I spent my spare time building a beerlift:

The beerlift is capable to serve multiple bottles of beer so each bottle has its bottle holder:

The bottle holder contains a switch to detect a bottle being placed or being removed. It also contains a LED so it can visualize if a bottle is placed or removed or eg. advertised.

I wanted to support up to sixteen bottles (so 32 switches and LEDs) which exceed the GPIO pin limitation of a Raspberry Pi.

Therefore, I bought myself a couple of MCP23017 I/O Expanders. This device offers sixteen digital inputs or outputs over a serial interface. I went for the I2C version:

Let’s see how we can use them in an Azure IoT Edge solution.

Sending IoT Hub telemetry to a Blazor Web App

For those who are interested in software development for the web using the C# programming language, Blazor is a viable alternative for building progressive websites as compared to Asp.Net Core / Angular / JavaScript.

Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries.

In the past, I already implemented Blazor on the Edge, including message routing.

Now, let’s see how we can integrate a Blazor website with telemetry coming from an Azure IoT Hub in the cloud.

For this to happen, we need this architecture:

So, the moving parts are:

• An IoT Hub with message routing enabled
• Azure Function with IoT Hub / EventHub trigger
• Server-side Blazor website with API Controller integration

Let’s see how this is set up.

Running ML.Net models inside an Azure IoT Edge module

Getting started with machine learning is not easy. This is the domain of the Data Scientist and to understand the different models leads you into trying to understand the mathematical part of it.

Still, if you see a machine learning model as a black box, things start to get a little bit easier.

One of the solutions Microsoft offers to developers for getting familiar with machine learning, training models, and deploying them with code, is ML.Net.

Or as Microsoft says:

With ML.NET, you can create custom ML models using C# or F# without having to leave the .NET ecosystem.

In fact, it runs on .Net Core so technically, this should run on multiple operating systems, including Linux; on Intel and Arm processors…

Let’s see how to start with ML.Net and how to integrate it with Azure IoT Edge

Connecting child devices to the Azure IoT transparent Edge gateway

Getting started with Azure IoT Edge is easy. Microsoft offers quite some tutorials for several operating systems for setting up an edge gateway.

Once you have created your first IoT edge solution and played with it, you discover Azure IoT Edge takes a bit more time to master.

In real-life IoT is hard, though…

This is because there are more moving parts like security, provisioning, managing, monitoring, etc.

For example, take a look at the ‘iotedge check’ output on your edge device:

This feature of the iotedge runtime makes it possible to check how well your runtime is hardened against common scenarios where something can fail (eg. running out of disk space due to extensive logging or firewall blockades for certain protocols).

In this case, a message is shown which indicates the runtime is using a development (x509) certificate which will expire within ninety days. Communication between the edge modules will stop after that date. A reboot/restart of the runtime is needed to get the runtime running again for another ninety days.

What is the purpose of this certificate and why do we need this to be fixed?

As seen in the documentation:

IoT Edge certificates are used by the modules and downstream IoT devices to verify the identity and legitimacy of the IoT Edge hub runtime module

So, apart from the secure connection with the cloud (either with a symmetric key, x509 certificate, or a TPM endorsement), this certificate is used to secure the communication between modules and possible edge devices. If the certificate expires, edge communication comes to a hold.

Let’s check out how to ruggedize the communication.

Understanding TimerTriggers in Azure Functions

Azure Functions are Microsoft’s way of offering serverless compute.

In essence, Azure Functions are just source-code functions, running on PaaS servers, which are triggered by some external mechanism. You just deploy functions and do not care about the infrastructure underneath it.

Multiple programming languages are supported e.g. C#, Javascript, Java to write your function in.

Multiple kinds of triggers are available. Most of them are related to some event in another Azure resource. For example, adding a blob in Azure Blob Storage (a BlobTrigger) or receiving a message in an Azure Event Hub can trigger the function (a EventHubTrigger).

A function can also expose an external HTTP endpoint. Then a Rest call on that endpoint triggers the function (HttpTrigger).

All these triggers are scalable. The more triggers are fired on the Azure Function, the more functions are executed. If you choose for a consumption plan this can even result in a scale-out on the number of servers (which you do not have configured).

Azure Functions also offers a TimerTrigger. Functions are just triggered by a … timer.

This seems simple but the Timer trigger behaves a little bit differently when executed.

Let’s try understanding the Timer Trigger.

Turn Node-RED into a first-class citizen Azure IoT connected device

A few months ago, I gave some comments on the node-red-contrib-azure-iot-hub Node-RED module.

The consensus was that the module is OK to be used in the Azure portal but had almost no value within an IoT device.

Just last week, Eric van Uum from the Microsoft IoT Blackbelt team released a brand new Node-RED module which turns your Node-RED into a full Azure IoT device. The feature set is very extensive.

Let’s see what is offered.

Azure IoT DeviceClient SDK demonstration, the basics

The cloud gateway of Azure IoT offers multiple protocols to connect to:

• MQTT
• AMQP
• HTTPS

Programming all D2C and C2D communication yourself is pretty hard. Microsoft has made it easy to communicate by providing SDKs, both for device communication and IoT Hub manipulation.

In this blog, we dive into what is offered by the Device SDKs.

Belgische Rijksregisternummer checksum testen (Dutch)

Note: This text is written in Dutch, one of the three official Belgian languages. The code example is annotated in English.

Iedere Belgsiche inwoner heeft een rijksregister nummer. De Belgische overheid kan hiermee alle persoongegevens achterhalen van die persoon. Dit is dus een uniek nummer.

Bij ‘unieke’ nummers in het algemeen is het verstandig om deze nummers slim te kiezen. Als deze direct opvolgend zouden zijn (1, 2, 3, etc.) dan is een typefout snel gemaakt en niet direct op te merken. Daarom worden unieke nummers (zoals nummers op papiergeld of bankrekeningnummers) versterkt met bijvoorbeeld een 11-proef. Het idee is dat alleen correcte nummers dan deelbaar moeten zijn door een priemgetal, zoals elf in dit geval. Als dan toch een typefout wordt gemaakt, wordt dit direct opgemerkt. Een typefout die nog steeds uitkomt op een getal dat ook door 11 deelbaar is, is dan heel klein.

Het Belgische rijksregisternummer is echter niet zomaar een ‘willekeurig’ uniek. Het is opgebouwd uit oa. de geboortedatum.

Hoe is dan het nummer ‘beveildigd’ tegen typefouten?

Deploy Azure IoT Edge deployment manifest programmatically

Azure IoT Edge is based on the concept of modules. A module is a container holding some logic executed on the edge device. These containers are actual Docker containers.

These can both be generic containers like a NodeJS that you have produced yourself, an open-source container, or a commercial container. In can also be a container supporting Azure IoT Edge module twins and the routing between modules using one of the Azure IoT Edge SDKs.

Anyway, the modules have to be deployed at one point in time.

By default, Azure IoT Edge devices are constructed with two basic modules registered, the edgeAgent (which is responsible for life-and-death of other modules) and the edgeHub (for enabling message routing between modules and the local gateway towards the cloud):

With life-or-death of other modules I mean the EdgeAgent is responsible for keeping the module configuration on the Azure IoT Edge device in sync with the registration and configuration in the IoT Hub device registration.

For this purpose, the Edge Agent is keen on receiving the so-called ‘deployment manifest‘.

Each time the configuration of an edge device registration in the IoT Hub changes, a new version of the deployment manifest is offered to the Edge Agent. It contains both the module descriptions and their configuration and a description of the message routing on the edge.

The Edge Agent then picks up the deployment manifest and checks for changes with the last manifest it received. If there are any configuration changes, or modules added or modules deleted, the edgeAgent will start the process of synchronizing the deployment.

If you check the documentation, three ways of altering the IoT Edge configuration (and thus deploying a new deployment manifest) are documented:

1. Command Line Interface (CLI)
2. The Azure portal
3. Visual Studio Code

Notice these deployments are effectuated by hand.

For those seeking a CI/CD solution two other ways are offered:

1. Azure DevOps
2. Jenkins

These are advised if you want to automate the deployment in a CI/CD pipeline.

If you prefer to do everything by programming source code, you can deploy your manifest using REST calls.

Let’s see how that is done.