How to tag your IoT Hub Devices

Until now, device twin tags were a bit lame.

Yes, desired and reported properties were much more fun to play with.

But those of you who administer thousands of Azure IoT devices, you really appreciate tags. It’s the only way to control that large amount of devices without losing your head.

Why? Because you first query your devices and then execute jobs on these subsets.

And Microsoft is making use of this feature a lot. You will have to use tags if you want to execute IoT Edge deployments (still in preview) or if you want to use the recently added Automatic Device Management (even newer):

But how do you actually add or alter tags of devices? What tooling is Microsoft providing?

Let’s check out a number of ways to tag and start querying your devices.

Continue reading “How to tag your IoT Hub Devices”

Advertenties

Administer your SQL Server in Docker

As with many things, you have to do it, to believe it.

The same goes for the Azure IoT Edge solution.

With the new IoT Edge solution, Microsoft provides a platform, both powerful and scalable. It’s based on Docker and logic is put in Docker containers.

And in many presentations, this (correct) picture is used to show the capabilities:

I am already working with the IoT Edge preview quite some time and there is a ‘weak’ spot in the image.

I already marked it in red so it’s not that hard to find.

On several occasions, non-technical people explained the local storage as being a database to persist data from internal logic.

I understand the confusion, but this is just a ‘database’ used by the IoT Edge internals (I assume mostly the Edge Hub module) and it is not accessible by users. I know for sure it’s used for the store-and-forward pattern used to send ‘upstream’ messages to the cloud.

Once a message is routed to be sent to the cloud, it’s first stored by the EdgeHub. If the connection to the Azure IoT Hub cannot be established, the message is stored with a certain retention time ( see its configuration “storeAndForwardConfiguration”: { “timeToLiveSecs”: 7200} ).

So, how can we add local storage to our IoT Edge if we want to do something with custom code and databases, etc.

Well, Microsoft already has written a great piece of documentation here.

There, you can see how you create an SQL Server database both on Linux and Windows containers and you learn how to create a database and a table inside it. Finally, you access it using some Azure function.

Let’s dig a bit deeper into this.

We will look on other  (simpler) ways to work with the database.

Continue reading “Administer your SQL Server in Docker”

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

Update March 28, 2018: a new solution structure is introduced. Follow this migration path if needed.

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”

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”

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”