Writing commands to IoT Edge Modbus Modules

Microsoft provides several out-of-the-box modules for their Azure IoT Edge platform. If we do a quick search at the Public Docker repository, we see modules like

  • microsoft/iot-edge-opc-publisher
  • microsoft/iot-edge-opc-proxy
  • microsoft/azureiotedge-modbus-tcp
  • etc,

I already have described in a previous blog, how to consume and read data from that Modbus module. After checking out the documentation and some testing, I found out how to write commands back to the device too.

Let’s check out how we can use this in a Custom C# module. After that, we use it in an Azure Functions Module. So let’s do a deeper dive into Azure Functions on the IoT Edge as well.

Continue reading “Writing commands to IoT Edge Modbus Modules”


How to build a simple IoT Edge Version 2 Heartbeat Module

Recently, the Microsoft Azure IoT Edge platform was updated with more features, better documentation and lots of goodies. Version two is brand new and still in Public Preview. The new features and fixes are both very welcome and promising.

Yes, the learning curve of this new version is steep, especially if you are new (like me) to Docker. But once you have started building your own Edge solution, things seem to fall into place quite well.

A logical flow, on learning this new platform, seems to be described in the Microsoft documentation:

  1. Simulate an IoT Edge device in Windows
  2. Simulate an IoT Edge device in Linux
  3. Develop and deploy a C# module
  4. Deploy Azure Stream Analytics as a module
  5. Deploy Azure Machine Learning as a module
  6. Deploy Azure Functions as a module

Looks easy, doesn’t it?

But by reading the comments on the different pages, it seems people are still confused.


Version one is/was based on one executable (gw.exe) which injects classes from DLL’s (a configuration file has to be supplied). Modules are just classes in the DLL’s.

Version two is based on Docker Containers, each module is a separate container and therefore each module is a separate executable. These modules share the same logic on how to connect to a shared message bus which provides the routing of messages between the modules. This ‘runtime’ has to be installed on the Edge machine, next to/outside the Docker containers.

Note: the good thing is that the architecture still stands, multiple modules on top of a message bus and messages are routed. The best thing is that the new routing solution is far more intelligent, different messages are separated from each other. And Microsoft has provided some guidance for migration for your ‘old’ modules.

So work your way through the documentation provided above. After that, check out my recent blogs:

OK, I know, the learning curve is still steep.

How about if I add an example of a simple but functional module?

Continue reading “How to build a simple IoT Edge Version 2 Heartbeat Module”

Deploy an Azure StreamAnalytics Job on the IoTEdge

[Update 16-01-2018]: There is a workaround available. Log into the Azure Portal using:  https://portal.azure.com/?Microsoft_Azure_StreamAnalytics_onedge=true

[Update 15-01-2018]: The issue is being fixed asap. I have been notified the dialogs of Azure Stream Analytics will be changed in a couple of days. This blog will remain valid, though.

[Update 13-01-2018]: It seems the IoTEdge-ASA integration is suddenly not available in the Azure Portal. Eg. the Environment Host question shown below is dropped and no Edge Hub input or output is selectable anymore. No idea why… When more information is available, a new update will be posted here.

The second version of the Microsoft IoTEdge solution is now available as Public Preview. In this version, you can run predefined modules like Modbusbuild your own modules, deploy Azure Machine Learning modules, deploy Azure Functions and you can deploy Azure StreamAnalytics jobs.

The concept is pretty simple, as always you have to create an ASA job, define inputs, outputs and a query. But this time the ASA will run on a local device:

Microsoft provides documentation here and here explaining how to deploy your ASA modules. Let’s dig a bit deeper into it. Continue reading “Deploy an Azure StreamAnalytics Job on the IoTEdge”

Introduction to the microsoft/azureiotedge-modbus-tcp IoTEdge Module

The newest version of the Azure IoTEdge solution is a very promising platform. The combination of remote provisioning the modules, the power of twin configuration and the new routing is interesting. But the learning curve is pretty steep.

The first version was based on programming an application. The new version is based on docker images, each being a separate application, which has to be stored in the container registry of your choice (like Docker Hub or your own container registry in Azure.

So once you have learned how to build and deploy your own modules, you can check out the modules Microsoft already supplies.

One of these modules is a Modbus module. It’s available at the Docker Hub of Microsoft. Modbus is a great protocol for highspeed communication over TCP and I have already blogged about it, using the previous IoTEdge SDK version.

Let’s check out how we get some telemetry from it.

Continue reading “Introduction to the microsoft/azureiotedge-modbus-tcp IoTEdge Module”

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.

Continue reading “Better property roundtrip for Azure IoTEdge Module Twins”