Combining Azure StreamAnalytics with Azure Function Sink

There are many ways to collect data from an IoTHub and pass it through Azure Functions:

• Trigger an Azure Function directly by the IoTHub events or operations monitoring
• Trigger an Azure Function using an EventHub or message bus as endpoints of IoTHub routing
• Trigger an Azure Function using an EventHub as output sink of a Stream Analytics job

All these solutions serve their own purpose.

But the last one, using an EventHub, can be pretty annoying. Yes, this is a great way if you will use the security policies and/or consumer groups of the Eventhub. But otherwise, there is a lot of administration.

Let’s check out how life is becoming much easier with a new Azure functionality which is still in public preview called Azure Function Sink.

Advertenties

Introduction to the IoT Edge SDK, part 5: Watchdog

In the past weeks, I have shown how to work with the basics of the current Azure Edge SDK.

Today we will look at a more specific need, a watchdog.

Using this watchdog, we have more control over the quality of the service.

I created my watchdog when I discovered I was depending on the time-out of an HTTP request to find out the sensors were not working correctly. These timeouts can take a long time (there is an example of 100 seconds).

Because I expect a message every five seconds, I want to be warned if a message is not generated in nine seconds!

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.

Introduction to the IoT Edge SDK, part 4

We have already made great progress understanding and using the Azure Gateway SDK.

What do we have right now? We can send telemetry data from multiple ‘offline’ devices and accept commands from the IoT Hub.

The data we send is well-formatted JSON so we are good to go.

But I am a bit worried. While reading all documentation regarding the transformation from Azure Gateway SDK towards the IoT Edge SDK, it is clear that multiple types of messages are sent to the IoT Hub. For example, I can imagine that a Stream Analytics module generates other data.

And let’s look at a more ‘close to earth’ example. The gateway itself is a potential device too! But I do not want to mix data coming from the gateway and from sensor devices.

Of course, we recently got the ability to route messages using the message sent. But what about using the properties? This keeps the message content clean.

Will this be working?

Introduction to the IoT Edge SDK, part 3

In the previous blogs of this series, you have been introduced to the Module architecture of the IoT Edge SDK. In my last blog, we have sent data to the IoT Hub.

But the IoTHub has more capabilities for devices. Think of ‘device twins’, ‘direct methods’ and ‘message to device’. Are these supported too?

At this moment, the IoTHub module supports commands, messages to devices, coming from the IoT Hub.

Let’s see what we have to do to get this working.

Introduction to the IoT Edge SDK, part 2

Running logic on the Edge is not that hard, as we have seen in my previous blog. You have been introduced to modules, the gateway configuration and the broker/runtime.

But these were just two modules. Now it’s time to put some data into the Azure IoT Hub.

If we look at the modules provided by Microsoft, we can do the job already. What we need are the following, already available modules:

1. simulated_device.dll, to generate simulated data
2. identity_map.dll, it holds a list of device names and private key combinations so the data of devices can be sent securely to the IoT Hub
3. iothub.dll, to make contact with the IoT Hub and pass data in name of devices

Yes, there are some limitations to these modules but for now, it’s good enough. Let get started.

Introduction to the IoT Edge SDK, part 1

When the Azure IoT Platform is referenced, in most cases the devices connecting to the IoT Hub are capable of communicating directly on the internet using Wifi etc. But there are many cases where devices are not capable of reaching out to an IoT Hub.

For example, these devices lack the ability to communicate using the internet (but use eg. Bluetooth or I2C instead). Or these devices are capable of communicating eg. REST but simply disconnected from the internet. Or they can only reach their own platform (eg. LORA).

In these cases, you need a mediator, a gateway. It sits between the two parties and passes data back and forth.

Microsoft provides for these cases the IoT Edge SDK, formally known as the Azure IoT Gateway SDK.

This SDK makes it possible to run a service which makes it possible to connect devices to the Azure IoT Hub using a series of modules.

But the name change (from ‘gateway‘ to ‘iot edge’) is not without reason. The Edge SDK has extended logic and is currently in preview. The additions to come will make it possible to run logic on-premise (according to the website: Enable real-time decisions, Perform edge analytics, Run artificial intelligence at the edge, etc.). This is promising!

But I have experienced the usage of the Gateway SDK as a challenge. The SDK supports many development platforms and documentation is scattered. So it’s hard to find a good starting point.

We will start with the Gateway SDK. I want to make the usage of this SDK as easy as possible.