Take back control over IoTHub messages in Azure Functions

Azure Functions are a blessing for IoT solutions. To be so flexible executing code whenever messages are arriving, every IoT project is fully depending on it.

But one of the biggest frustrations is the casting of (EventHub) messages towards a string! Only the message body is left! Once a message is passed on to an Azure Function, I only have access to the body of the message. I can not access the (routing) properties anymore.

And before we got Azure Functions, we had to work with Stream Analytics. And I still do! And it’s so nice to have access to the IoT Hub values like the device name of the message. Because I am working with Azure Functions, I have to put it in the Message body first???

It would be great to have access to both the properties and the IoTHub values!

Well, it’s possible now with some clever casting…

Continue reading “Take back control over IoTHub messages in Azure Functions”


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”

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”

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”

Not for the restless, HTTP access to the Azure IoT Hub

The Azure IoT Hub is accessible using multiple protocols. You can use MQTT, AMQP and HTTP. It’s even possible to run MQTT and AMQP over HTTP using web sockets (in case your firewall is closed).

This week, I had to connect a device to the IoT Hub running its own propriety runtime environment. The only way to communicate was HTTP.

Luckily, still HTTP is supported but communication works a bit different compared to using the IoT Hub SDK’s which Microsoft is offering.

Yes, at first it seems easy to just make a POST or GET to a REST endpoint. But looking at the security, just providing the Device connection string is not enough. You have to extract an SAS (Shared Access Signature) token first.

Let’s see how you can use REST.

Continue reading “Not for the restless, HTTP access to the Azure IoT Hub”

Turn your Raspberry Pi into a Personal Assistant using Cortana

Microsoft is constantly updating its latest version of Windows, version 10. For me, as a developer, it’s a wonderful operating system to program for. The UWP apps I build, run on both PC’s, laptops, Windows Surface Hub (up to 84 inches), The Xbox One and even on a Raspberry Pi. Yes, Windows 10 is running on a 35 dollar device.

But before you run to the store to replace your PC, I have to tell you it’s running the core of Windows 10, actually. There is no shell (no menu, no start bar etc.).

So this means you can run one visual (headed) UWP application and multiple background applications. And yes, you will love it!

This is a great interface for kiosk-like devices. And with the latest update (build 15063), it’s easy to add Cortana support.

Cortana is the speech service, available in Windows 10. If you know Siri or Alexa, then you know Cortana. Just ask her a question and she will try to answer it. The answer will be provided by speech or supported by browsers or other visual help.

Let’s take a look on how to enable Cortana on a Raspberry Pi.

Continue reading “Turn your Raspberry Pi into a Personal Assistant using Cortana”