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.

The biggest tip is: DO NOT MIX VERSION ONE AND VERSION TWO DOCUMENTATION.

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”

Advertenties

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”

Forget about messages, just care about IoTHub chunks

Ok, this blog is all about taking the blue pill or the red pill:

I use the Azure IoTHub for every project I am involved in. It’s my main focus on getting IoT things done and using this tool is how I manage.

And consequently, I always look at the number of daily messages we have to ingest because the price of an Azure IoTHub depends on the number of messages it passes on.

It starts with 400.000 messages a day and from there, you can scale up. The biggest version can scale up to a tenfold of 300 million messages a day:

But this is not the whole truth, you can send more… Continue reading “Forget about messages, just care about IoTHub chunks”

Introduction to the IoT Edge SDK V1, part 6: Modbus for Wise modules

Update: Recently, Microsoft introduced the new V2 version of their IoT Edge. This blog is referencing the former but still supported V1.

I do a lot of IoT research using the Advantech Wise 4012E IO module. It’s biggest advantages are that it runs on 5 Volts, using a MicroUSB connection (instead of a bulky 12V or 24V adapter) and it comes with knobs, switches and LEDs to simulate real sensors. So it’s a very compact but yet complete IoT device.

Until a few days ago I made use of the Rest protocol to contact that module but this has some disadvantages.

First, Rest is a great protocol in the IT world but it is not used that much in the OT world. Luckily, the IO module also supports the Modbus protocol. So I tried to switch to that protocol.

Second, Rest is very slow compared to other protocols like Modbus. Using Rest, I’m lucky when I can pull 2 or 3 requests a second out of the module.

In the previous blogs, we have seen multiple modules, both provided by Microsoft or created on the fly. And Microsoft provides a genuine Modbus module for the IoT Edge SDK. There is only one drawback, it’s on Github but it’s not available as NuGet package. You have to make/build it yourself!

And for some unknown reason, I did not get it working the way I liked it. I encountered too many exceptions.

Update: There is also a Version 2 of this module. In this blog, I refer to V1.

So, in the end, I just ignored the module and build my own Modbus module.

Continue reading “Introduction to the IoT Edge SDK V1, part 6: Modbus for Wise modules”

Direct methods support in the IoT Hub Connected Service

The Visual Studio 2017 Connected Service for Azure IoT Hub has received an update a couple of months ago.

This update had some visual updates and now supports a Singleton pattern for the Device client too.

But it also included support for both Device twins and  Direct Methods. The latter feature looks a lot like the Commands method but there are some fundamental changes.

Yes, both solutions (Command and Direct Method) can execute code on a remote IoT Hub client. But the remote method just passes a message to the client. The Direct method can pass a message in a certain context. It calls a specific method (a client can have multiple methods registered) and passes the JSON parameter.

If you execute a Command, it feels like fire-and-forget. There is no descriptive response. But the caller of a Direct Method can wait until a response is accepted and a JSON value is returned.

Let’s check out Direct Methods.

Continue reading “Direct methods support in the IoT Hub Connected Service”

Azure IoTHub routing revisited, Blob Storage Endpoints

Recently, Microsoft added some extra features to the IoTHub routing abilities:

  1. Support for routing using the message body
  2. Support for Blob Storage as endpoint

In this blog, we will look at both features using the Visual Studio 2017 extension called the IoT Hub Connected Service, which is updated also.

But first, let’s look at the new Blob Storage endpoint.

Sending telemetry to a Blob Storage container is a simple and efficient way for cold path analytics:

Until recently, there were a few ways to do this:

  • Sending IoTHub output to a Stream Analytics job, which filled some blob
  • Sending IoTHub output to an Azure Function, which filled some blob
  • Making use of the IoT Hub ability to receive blobs

The first two ways can be done using extra Azure resources so additional costs are involved. The third one is only used in very specific circumstances.

The new Blob Storage endpoint is a simple but very powerful way of making Cold path analytics available, right from the IoTHub.

Continue reading “Azure IoTHub routing revisited, Blob Storage Endpoints”