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”

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”

Flexible message routing in Azure IoT Hub using C#

The Azure IoT Platform is a very versatile solution for all your IoT needs. Azure supports multiple resources for storing large amounts of data, querying immense streams of data coming in, having event buses which can hold millions of messages, serverless functions, reporting and Machine Learning; what more do you need?

But it all starts with the IoT Hub:

“Azure IoT Hub is a fully managed service that enables reliable and secure bidirectional communications between millions of IoT devices and a solution back end”

Normally, whenever I start a new IoT Platform solution in Azure, I start with an IoT Hub and connect it to a Stream Analytics job as an input source. Messages arriving at the IoT Hub are then passed directly into the Stream Analytics job to be examined. And the Stream Analytics job can pass some or all messages (or transformed messages) to multiple output sinks eg. Event Hubs, Service Bus Queue or Topic, Blob Storage, etc.

The arriving messages carry telemetry information from the device. But what if the messages are sent in a certain context? What if a message has a high or low priority? Should we pollute the message with this ‘routing’ information? And Act on it inside the Stream Analytics job?

A few week ago, Microsoft introduced a new feature in IoT Hub, called message routing.

This makes it fairly easy to react on difference messages, arriving at the same IoT Hub, but intended to handled differently. Routing is perfect for this matter. We can declare extra endpoints directly in the IoT Hub. And depending on message properties, messages can be sent directly to these endpoints:

routing-on-iothub

There are two important things to keep in mind. First, the message properties are extra annotations (defined by the IoT Hub device client), we are not peaking inside the message itself. And second, messages can still end up in a Stream Analytics input when it is ignored by the active routes.

Let’s take a closer look.

Update 2017-06-01: Microsoft announced that routing is now supporting values from the actual telemetry, great news and now it’s more intuitive!

Continue reading “Flexible message routing in Azure IoT Hub using C#”

BBC micro:bit Impressive introduction into programming

This weekend, I got a BBC micro:bit from a friend. This is a nice gift indeed, I had and still have lot’s of fun with it.

Before I tell a bit more about the device, did you know each 11- and 12- year-old student in the UK got one for free!? That’s more than one million devices. This is a great opportunity for kids: they can learn about programming, computers and most of all, programming and computers can be fun!

The design of the device is very clever!

It has an ARM processor, two buttons, 25 leds (which acts like a screen), a compass, an accelerometer, Bluetooth LE, GPIO pins, a battery connector and a MicroUSB connector (for programming).

microbit

Programming is so easy! Let’s dive into this a bit deeper…

Continue reading “BBC micro:bit Impressive introduction into programming”