Add local storage to Azure IoT Edge modules using Docker Bind

Azure IoT Edge makes use of the Moby container runtime so IoT Edge modules (being Docker containers) can work together and offer logic on the edge.

Docker containers are ‘sandboxed’. This means that the logic within the containers has limited access to the environment they ‘live’ in.

By default, containers have no SUDO rights, no access to the host filesystem, and just limited network capabilities.

Though, containers can be granted elevated rights. One of these is the right to access the filesystem.

In this blog, we will see how to configure a container with access to the filesystem. To demonstrate this, a custom IoT Edge module is introduced, an IoT Edge filewatcher for CSV files:

Doorgaan met het lezen van “Add local storage to Azure IoT Edge modules using Docker Bind”

Handling Advantech Wise 710 OPC-UA telemetry using OPCPublisher

Microsoft has an extensive IoT platform based on Azure.

It provides so many features, this can be overwhelming for customers. Therefore, Microsoft provides Azure IoT solution accelerators, based on the Azure IoT reference architecture.

Some of the original accelerators (it started with Azure IoT suites) like Remote Monitoring are now outdated or even archived. These are replaced by excellent Azure IoT Central apps which demonstrate the capabilities of the IoT platform for numerous markets and verticals:

There is still one original accelerator alive-and-kicking: the Connected Factory. This one demonstrates the use of OPC-UA protocols on the edge and in the cloud.

More than two years ago, I already wrote about this accelerator and the OPC publisher module, the backbone of this accelerator. Since then, a lot has changed. Some functionality is (temporarily) deprecated so I got a lot of questions based on the old blogs.

So it’s time to update it a little and see how the OPC Publisher is doing these days.

The OPC-UA solution is open source and covers a lot:


I limit this blog to the scope of my very first blog, extracting OPC-UA messages and send them to the cloud using a ‘published nodes’ file.

We just need an OPC-UA server to get some sample data from. For this, I used an Advantech Wise 710 as an industrial protocol gateway.

Doorgaan met het lezen van “Handling Advantech Wise 710 OPC-UA telemetry using OPCPublisher”

Azure IoT Edge module metrics in action

We are familiar with the Azure IoT Hub metrics which are offered. The Azure cloud tells us eg. how many messages are received or the number of devices that are connected.

If we look at Azure IoT Edge, you had to collect your own made metrics in the past.

Because IoT Edge modules are Docker containers and therefore sandboxed, you had to rely on the (third-party) logic to capture Host metrics. Regarding metrics about the edge agent and hub, these were not available.

Until now.

With the most recent IoT Edge runtimes, agent, and hub, we have access to Edge metrics.

Both the Agent and Hub module expose the metrics over HTTP endpoints:

Within the Moby runtime, port 9600 is exposed on both individual modules. Outside the runtime, we have to assign individual host ports to prevent using the same host port.

Let’s see how this looks like and how we can harvest metrics in a custom container.

Doorgaan met het lezen van “Azure IoT Edge module metrics in action”

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.

Doorgaan met het lezen van “Using a Weidmueller UC 20 Controller as Azure IoT Edge child device”

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.

Doorgaan met het lezen van “Expanding Raspberry PI I/O using I²C on Azure IoT Edge”

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

Doorgaan met het lezen van “Running ML.Net models inside an Azure IoT Edge module”

Access COM ports with Docker containers on Windows

Microsoft supports a Modbus module for Azure IoT Edge. This module handles both Modbus TCP (over the local network) and Modbus RTU (over serial ports).

In the past, I have already blogged about using serial ports on Linux with this module. But I did not check out Windows support until recently. Why? The documentation stated, “RTU is currently not available in Windows environment, please use Linux host + Linux container to play with RTU mode”.

And if something is documented in the readme, it’s true, isn’t it?

This is not entirely correct, though. It is possible to use this module on devices running Windows 10!

Let’s see how.

Doorgaan met het lezen van “Access COM ports with Docker containers on Windows”

Adding local persisted state to IoT Edge modules using Module twin

Each Azure IoT Edge module, deployed to a device, has its own Module twin.

A Module twin is the same concept as a Device twin for an Azure IoT Device, it stores state information including metadata, configurations, and conditions.

A Module twin is essentially a JSON document which lives both in the cloud (in the IoT Hub) and on the device and is kept in sync when communication between device and cloud is possible:

In the IoT Hub, the tags are writable and readable. These can be used to identify a specific device with an alternative key and/or to filter subsets of devices.

Also in the cloud, the desired properties can be written with updated values. These (updated) values (eg. properties or settings) are picked up by the device when it is connected. So it could take days or weeks for the updated desired property to be picked up because the device is offline in the meanwhile.

But the desired properties are patient…

Once the updated values of changed desired properties are arriving at a device, a notification method on the device is triggered to handle them.

As a good citizen, an IoT Edge module should report back to the cloud how it is updated by the desired properties. This is done using the reported properties in the Module twin.

This closes the loop for the administrator. I can publish a desired property change for one or more devices. And after a while, the reported properties can be checked to see which devices have picked them up and which devices need some attention.

Do you notice that it’s also possible to read reported properties, on the module side?

Write data, read data… that is enough to persist data on the edge, isn’t it?

Let’s see how we can use this for persisting local state.

Doorgaan met het lezen van “Adding local persisted state to IoT Edge modules using Module twin”

Shine a light on IoT Edge, connect Ikea Tradfri lights

Being a developer gives you some privileges.

For example, if you are a carpenter, you basically can make everything out of wood. If you are a welder, the world of iron construction is all yours.

As a software developer, you can program a solution for any problem which can be solved by software.

And being an IoT Developer, you can connect the whole world!

This is a story about my journey in connecting my Ikea lights to the cloud. It’s based on my presentation for the Global Azure Bootcamp, Canada edition in Toronto.

Doorgaan met het lezen van “Shine a light on IoT Edge, connect Ikea Tradfri lights”

Towards zero-touch IoT Edge with edgeAgent direct methods

The holy grail of IoT Edge compute is zero-touch configuration and monitoring.

If we look at the life cycle of an edge device, these are the phases where the device is rolled out to production:

The only time when we want to have a person near that edge device is during the initial deployment (Plan, Register), during decommission (Retire) and during physical changes or while repairing the device.

To make zero-touch possible we first need to have a secure cloud connection that supports both sending telemetry to the cloud and retrieving commands from the cloud. And that is supported by Azure IoT Edge by default.

But still, we also need a second communication channel to log-in remotely in a secure way. This is typically done by hand to look at local settings, to check logging, to check connections, or to make repairs to eg. the operating system or the Azure IoT Edge runtime. This could be done using SSH and/or a Remore Desktop connection (RDP). Because this is typically an outbound connection, this is usually provided using a ‘jump box’ or a VPN connection so the connection is set up in a more secure way.

As said, this is done by hand… so far for zero-touch.

Now, if we look at what tasks are performed on the IoT Edge device using an SSH connection:

  • Checking the log of running modules
  • Restarting modules if their performance is not thusted or to force picking up settings
  • Checking the cloud connectivity

What if exactly these three tasks could be performed from the cloud? What if these task could automated?

Let’s check this out.

Doorgaan met het lezen van “Towards zero-touch IoT Edge with edgeAgent direct methods”