A new batch of OPCPublisher direct methods

Recently, Microsoft put some real effort into updating the OPCPublisher project. This application/IoT Edge Module ingests telemetry from an OPC-UA Server.

I already wrote two blogs about it: Getting started with OPC-UA on Azure IoT Edge and Managing nodes from the cloud in the OPC-UA Publisher Edge. The seconds one showed how to connect to the OPCPublisher as an IoT Edge module using DirectMethods.

New methods have arrived, this time we get information about the module itself.

Let’s check them out.

Compare previous and current message in Stream Analytics

Last week I was testing the temporary storage in IoT Edge. I was interested in the stability so I wanted to know if messages were missing or maybe even coming in twice.

I have this heartbeat module which produces a counter. So I am able to generate messages which can be measured as a sequence.

One way is to check this using your eyes 🙂

But this can be seen as a more generic issue, comparing two messages after each other. So I was thinking about Azure Stream Analytics. This should be the perfect tool for this job.

Let’s check out how we can compare subsequent messages using Stream Analytics.

Add rolling logging to your Moby containers

Recently we were testing Azure IoT Edge on VMs which were limited in size. All went well, everything worked as expected until the whole solution stopped working.

After some research, we found out the VM disk was full of data.
This came to us as a surprise. What was eating up the hard disk?

After some more research, we checked out the Azure IoT Edge modules logging location: /var/lib/docker/containers/

Here you find folders, one for each container on your system. These are named after a unique GUID which is related to a specific container.

Note: you might need elevated rights to actually access these folders.

You can compare the folder GUID with the container ID in:

docker ps

If you open one of these folders you will find the logging of the related container.

We can, of course, remove the old logging by removing the files and everything seems to be working again. But that only delays the inevitable.

Let’s see if there is a more permanent solution.

Adding offline capabilities to your IoT Edge device

Azure IoT Edge makes it possible to send messages to your IoT Hub using the extremely flexible IoT Edge runtime and modules.

The runtime also supports temporary offline capabilities in case the IoT Hub is unreachable.

Currently, runtime 1.0.5 is available which makes it possible to set a custom location (folder) in which messages are stored before they are sent to the IoTHub.

Let’s see how this turns out.

Visualize Azure IoT Edge device routes as a flowchart in Asp.Net MVC

If you look at the routes page in Azure IoT Edge configuration wizard, what do you prefer?

The current notation:

Or do you prefer a flow chart like this:

The routes in Azure IoT edge are a clever solution to describe how messages from one module are sent to another. But the JSON notation can become less readable once you add more (up to twenty) modules. That could end up eg. nineteen routes or more!

Just as an experiment I was thinking about how the ease the experience using a graphical interface.

I prefer the second solution, probably just like you.

So let’s look at how you can create the same experience with your routes of your IoT Edge device.

Integrating SQLite in Azure IoT Edge for local storage

Microsoft has opened the Azure Marketplace for IoT Edge modules. This makes it easy to find and install IoT Edge modules into your own IoT Edge devices.

At this moment a dozen or more modules are available:

We see a few well-known modules from Microsoft which support SQL Server, Modbus, OPC-UA or the Temperature sensor simulation.

One of these modules is supporting SQLite.

What is SQLite?

According to the homepage, SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is the most widely deployed database in the world with more applications than we can count, including several high-profile projects.

What does the module do?

This IoT Edge module is capable of accessing SQLite databases locally.

Microsoft says:

“Using this module, developers can build Azure IoT Edge solutions with the capability to access SQLite databases. The SQLite module is an Azure IoT Edge module, capable of executing SQL queries sent from other modules, and return the result to the senders or to the Azure IoT Hub via the Edge framework. Developers can modify the module tailoring to any scenario.”

The module is open source and both documentation and source code are put on GitHub.

Why should we use this module?

In the past, I checked out the SQL Server IoT module to persist IoT messages locally.

This SQLite module has a few advantages which you will like:

• It’s lightweight
• It’s based on a public domain framework
• It’s integrated with the routing of IoT Edge

For me, that last item, we can integrate the module directly in the routing is interested.

So let’s check out how we can use it.

Custom IoT Hub assignment in Device Provisioning Service

In my previous blog, I have shown how to provision a device using a real TPM using the Device Provisioning Service (DPS).

Once you are able to provision your IoT devices to the Azure IoT Platform using a DPS, a whole new world of possibilities opens up for you.

Before, you registered your device to one IoTHub. To change it, you had to go to the device and fix it. But now you are able to make a choice between multiple IoT Hubs within the cloud, dynamically!

But what strategy are you going to use?

Microsoft provides three standard strategies out of the box:

1. Lowest latency (select the nearest IoT Hub)
2. Evenly weighted distribution (select the IoT Hub with the least amount of devices)
3. Static configuration (just select one yourself. This is the situation as before)

But there is a new strategy which is very flexible:

This fourth strategy makes use of a custom Azure Function which you can write yourself.

You could, for instance, access a database and read some data before you make the decision to which IoTHub you assign this device.

Let’s see how we can build a custom function ourselves and get the most out of it.