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”

GABC – Atos Amstelveen zaterdag 21 april 2018

“Intelligent Cloud, Intelligent Edge”

logo-2018-500x444

Voor het derde jaar op rij organiseert Atos de gratis Global Azure Bootcamp op haar hoofdkantoor te Amstelveen.

Aanmelden doe je hier!

Traditioneel ligt bij ons de focus op IoT en dus passeren alle mogelijkheden die Microsoft Azure op dit vlak biedt. Er worden naast presentaties ook verschillende workshops gegeven. En natuurlijk is er voldoende tijd om ook met onze Azure IoT platform experts van gedachten te wisselen. Of je nu vragen hebt over Domotica, Lora, Windows 10 IoT Core of industriële IoT, we gaan samen op zoek naar het antwoord.

De agenda voor de dag ziet er als volgt uit:

9.30 Inloop + ontvangst

10.00 Opening

12.00 Lunch

15.30 Tombola + Afsluiting met een hapje en drankje

Tussendoor zijn er meerdere labs, workshops en natuurlijk presentaties over IoT.

Nieuw is de door ons ontwikkelde workshop waarbij jouw laptop in een Edge gateway verandert. Hierbij krijgt je de opdracht om op eenvoudige wijze data uit een industrieel Modbus protocol naar de Cloud te brengen.

En we hebben wederom de workshop rond Lora en Azure op het programma staan.

Neem je laptop dus zeker mee. Voor de labs en workshops is een installatie van Visual Studio 2017 of Visual Code nodig en een Azure Account. Wie nog geen Azure account heeft krijgt zonder verdere verplichtingen de beschikking over een trial licentie.

Ons adres is:

Atos Nederland

Burgemeester Rijnderslaan 30

1185 MC Amstelveen

https://atos.net/nl/nederland

Route

(Gasten dienen zich op ons hoofdkantoor te kunnen legitimeren. Neem dus een geldig legitimatiebewijs mee.)

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

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”

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”