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:
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.
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.
Azure IoT Central is a SaaS platform for IoT projects.
If you are looking for a way to manage and monitor your IoT devices outside the Azure Portal or are not able to build your own IoT platform, IoT Central is the place to be. And you can extend this portal with custom Azure resources using the export functionality.
All you need is to have browser access to Azure IoT Central. You can even run it for free for seven days to test it out. Also, the first two devices registered are free too.
Once you have worked with Azure IoT central, you have mastered it using the portal. If you want to scale up eg. the number of devices or users, automation of your tasks becomes necessary.
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.
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:
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’
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.
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.
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.
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
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?
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.
