IoT Plug and Play support for Azure IoT Edge devices in IoT Central

In a previous blog, I already gave an introduction about the benefits of IoT Plug and Play (IPnP).

IoT Plug and Play enables solution builders to integrate IoT devices with their solutions without any manual configuration.

It introduces a model as a public description of a device. This device model advertises the capabilities of the logic on your IoT device like telemetry, properties, and commands. These elements are bundled as an interface. These interfaces are described using the Digital Twins Definition Language (DTDL).

Implementing IPnP in your solution is not that hard. The Azure IoT Device SDKs have you covered. Just interact with the cloud as usual. Only, when setting up the connection, the device exposes a ModelId. This id is compared with public models available in a repository so the actual model can be restored.

Azure IoT Central supports the capability models using the concept of device templates.

Next to direct-internet-connected devices, Azure IoT also support this concept of edge compute:

The way Azure IoT Edge devices are connected to the cloud differs quite a lot.

Azure IoT Edge devices lack the support for a ModelId. So there is no direct reference to any model is a model repository. But each type of edge device comes with a Deployment Manifest, describing the logic to be rolled out on the edge device and related settings.

These differences have an impact on how to implement IoT Plug and Play device templates.

Let’s see how to get started with IPnP for edge devices in IoT Central.

Doorgaan met het lezen van “IoT Plug and Play support for Azure IoT Edge devices in IoT Central”
Advertentie

Get a bundle of support files from your Azure IoT Edge for remote diagnostics

Azure IoT Edge makes it possible to run extensive logic within your factory, building, vehicle, etc. while it’s connected to the cloud.

This way, we can monitor the underlying sensors and protocols and measure what’s happening on the Edge. We are even capable of making predictions, both on the Edge and in the Cloud, of what is going to happen based on the current measurements and the data received over the last second, minute, hour, etc.

On a meta-level, Azure IoT Edge also comes with features for monitoring the edge device itself. Think about monitoring metrics and logging.

These features are mostly centralized around the edge modules and runtime. Due to the edge logic being sand-boxed, this is fine.

Still, we want to be able to go beyond the logic we deployed.

It would be nice if we would be able to break out of that sandbox and get some information about the Docker/Moby environment, IoT Edge runtime daemon, network, etc.:

This is actually offered!

Azure IoT Edge offers a so-called ‘support bundle’.

It is just a bundle of files with eg. logs, taken from various sources on the edge device and it is made available so you can support your edge device.

It contains:

  • Module logs
  • IoT Edge security manager logs
  • Container engine logs
  • iotedge check‘ JSON output
  • Other useful debug information

It’s even possible to retrieve these files ‘over-the-air’. This makes remote diagnostics possible for all your Azure IoT Edge devices!

Let’s take a closer look at this.

Doorgaan met het lezen van “Get a bundle of support files from your Azure IoT Edge for remote diagnostics”

Deploy Prometheus container with Azure IoT Edge

Once you have set up your Azure IoT edge device and runtime, you want to make sure it keeps running as expected. So you need to start measuring how your device, your modules, and runtime are doing.

Microsoft provides built-in metrics for Azure IoT using endpoints on the EdgeHub and EdgeAgent exposing messages in the Prometheus format.

In a previous blog post, I showed how to access these endpoints and not to send messages containing this information to the cloud using a custom Azure IoT Edge metrics module.

Azure IoT Edge can deploy whatever Docker container you have. So, we can also use the original Prometheus service as a Docker container:

This way you can build a local dashboard using well-known tooling on the edge.

Let’s check out how this works.

Doorgaan met het lezen van “Deploy Prometheus container with Azure IoT Edge”

Azure IoT Edge UDP Client module

Over the past couple of years, I’ve written several blog posts about supporting protocols on Azure IoT Edge.

We have seen examples like Serial communication, Modbus TCP and RTU, OPC-UA, and WebSockets.

This time, a new protocol is added to this impressive list: User Datagram Protocol (UDP).

Communication using UDP is fast and supports broadcasting to several IP addresses at once.

There are some disadvantages (it has no handshaking dialogues, and thus exposes the user’s program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection) but if you can cope with that at a higher level, UDP is a handy tool in your protocol toolbox.

In this blog post we will see how UDP messages can be received on the Edge with this demonstration IoT Edge module:

Because each UDP message is different (here we send text messages but this could also be binary values, depending on your challenges), this module is just a reference which explains how it works.

Doorgaan met het lezen van “Azure IoT Edge UDP Client module”

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:

diagram

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”