DEV Community

Cover image for Developing IoTEdge Modules

Posted on • Updated on • Originally published at

Developing IoTEdge Modules

Azure IoT Hub includes support for IoT Edge, a runtime to run custom workloads as Modules.

There has been different tools to help with this task, extensions for Visual Studio, Visual Studio Code and even a CLI can help with the most common developer tasks.

However, most of these tools are in maintenance mode, with no major investments.

An alternative approach to develop IoTEdge modules

A module is just an application, running as a docker container, that communicates with the a system module called $edgeHub via HTTP, AMQP or MQTT protocols. To develop a module we need a local instance of $edgeHub that we can target from the machine we use to develop.

In this post, I'm exploring a different approach to configure your workstation so you can develop and debug modules with your favourite IDE.

Note, this sample is using dotnet, but the same concepts should be applicable in other languages.

How to run $edgeHub locally

$edge hub is available as a docker image in, and we need to perform some pre-liminary tasks before running locally:

  • Initialize the $edgeHub identity in Azure IoT Hub
  • Configure $edgeHub module twin
  • Provide certificates to configure the TLS connection

Provisioning $edgeHub

When you create an IoT Edge device identity in Azuere IoT Hub, it will include the module identities for $edgeAgent and $edgeHub system modules. However, the modules are not initialized and do not include the connection string we will need to configure our local instance of $edgeHub.

In a real environment, this iotedge runtime takes care of initializing the system modules, however it implies to connect, at least one time, the iotedge runtime.

Instead, I'm using the dotnet tool aziotedge-modinit to initialize the $edgeHub module, so we can get the connection string.

.env configuration files

The following az scripts require

  • The $HUB_ID variable, with the name of the Azure IoT Hub
  • The $EDGE_ID variable, with the name of the IoTEdge device identity
  • The az extension is configured to use the subscription with access to the Azure IoT Hub
az account set -s $SUB_ID
Enter fullscreen mode Exit fullscreen mode

Initialize the $edgeHub module identity:

source .env
edgeConnStr=$(az iot hub device-identity connection-string show -n $HUB_ID -d $EDGE_ID  -o tsv)
dotnet tool install -g aziotedge-modinit
aziotedge-modinit --moduleId='$edgeHub' --ConnectionStrings:IoTEdge="$edgeConnStr"
Enter fullscreen mode Exit fullscreen mode

Configuring $edgeHub

At startup, $edgeHub requires two properties to be configured in the module twin, however as this is a system module, we cannot update the twin, neither using the portal, or the CLI.

 "$edgeHub": {
    "properties.desired": {
        "schemaVersion": "1.1",
        "storeAndForwardConfiguration": {
            "timeToLiveSecs": 7200
        "routes": {}
Enter fullscreen mode Exit fullscreen mode

The only workaround I've found, is to invoke the SetModules operation, using a default deployment manifest, which includes the expected Twin Properties.

source .env
curl -o deployBase.json
az iot edge set-modules -n $HUB_ID -d $EDGE_ID -k deployBase.json
Enter fullscreen mode Exit fullscreen mode

Or you can use the portal and follow the SetModules screens with all default values.

Certificates for local development with dotnet dev-certs

The system modules expose endpoints protected by a TLS connection, to configure the TLS we need to provide an X509 certificate. This certificate can be the same certificate aspnet uses to provide a local TLS connection.

The next script creates a certificate for localhost and exports the public and private keys as .PEM and .KEY files, then we can use those files to configure the docker instance.

dotnet dev-certs https -ep _certs/localhost.pem --format PEM --no-password
chmod +r _certs/*
cp _certs/localhost.pem _certs/ca.pem
Enter fullscreen mode Exit fullscreen mode

Running $edgeHub locally with docker

Now that we have the certs, and the $edgeHub connection string, we can run the docker container with:

source .env
connStr=$(az iot hub module-identity connection-string show -n $HUB_ID -d $EDGE_ID -m '$edgeHub' --query connectionString -o tsv)

docker run -it --rm \
    -e IotHubConnectionString="$connStr" \
    -e EdgeModuleHubServerCertificateFile=/certs/localhost.pem \
    -e EdgeModuleHubServerCAChainCertificateFile=/certs/ca.pem \
    -e EdgeHubDevServerCertificateFile=/certs/localhost.pem \
    -e EdgeHubDevTrustBundleFile=/certs/ca.pem \
    -e EdgeHubDevServerPrivateKeyFile=/certs/localhost.key \
    -v ${pwd}/_certs:/certs \
    -p 8883:8883 \
Enter fullscreen mode Exit fullscreen mode

If everything goes as expected, you should see this output.


Create a dotnet Module

Now you can create a dotnet module using the dotnet template, to install the template:

dotnet new install Microsoft.Azure.IoT.Edge.Module
Enter fullscreen mode Exit fullscreen mode

To create a new project based on this template.

dotnet new aziotedgemodule -o $MODULE_ID
Enter fullscreen mode Exit fullscreen mode

Provision the Module Identity

The SetModules operation will create the module identity, along with the container information to deploy in docker. For local development we just need the module identity:

source ../.env
az iot hub module-identity create -n $HUB_ID -d $EDGE_ID -m $MODULE_ID
modcs=$(az iot hub module-identity connection-string show -n $HUB_ID -d $EDGE_ID -m ModuleA -o tsv)
Enter fullscreen mode Exit fullscreen mode

Run/Debug the custom module

Finally, you can run or debug the module by tweaking the configuration so it will connect to the local $edgeHub instance by appending the ;GatewayHostName=localhost to the module connection string, and using the certificate configured for TLS with the EdgeModuleCACertificateFile variable:

export IotHubConnectionString="$modcs;GatewayHostName=localhost"
export EdgeModuleCACertificateFile="../_certs/ca.pem"
dotnet run
Enter fullscreen mode Exit fullscreen mode

Or you can configure your IDE to set these two environment variables (launch.json for VSCode, or launchSettings.json for VS) before starting a debugging session.

The complete sample is available in (CodeSpaces ready)

Top comments (0)