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.

Advertentie

Better property roundtrip for Azure IoTEdge Module Twins

The newest version of the Azure IoT Edge is still in public preview but this one makes the Edge truly intelligent!

We are now able to both distribute and manage logic on-premise.

Version one of the IoT Edge was and still is based on running an executable. And each module (ingest, transform, distribute) is a class in a dynamic library. And all modules are connected using a broker serving the role as MessageBus. Messages between modules are exchanged using configurable routes.

This first version is still available for download. But the new version is fundamentally different.

Modules hosted as a container

In the new version, we still see modules connected by and exchanging messages using a local MessageBus. But Microsoft has redefined the modules into separate executables, each running is a different container. The containers are hosted in Docker and can run on Linux or Windows.

Microsoft already provided a lot of modules in the Docker Hub, for OPC UA support, for Modbus support, etc. And you can deploy your own modules too!

There are multiple examples available on the Microsoft website which explain how to get started.

In this blog, I show how tweaking some example code leads to even better management and a better understanding of what’s happening on the Edge using the Module Twins properties.