Testing Azure IoTHub Manual failover

The Azure IoTHub is the center of all the IoT efforts of Microsoft. Over the last couple of years (or even months) we see a lot of innovations from that side.

The latest addition is the Manual failover which is now in preview.

This makes it possible to move a complete IoTHub (with eg. all of its devices and routes) to the ‘sister region’. For example, an IoTHub living in West US 2 will move to West Central US. And you can move it back too.

The manual failover is a good starting point for having a more resilient IoTHub. It’s not perfect, there is a chance that unread messages or data is lost. Failover is hard:

But it’s a perfect way to test the ‘automatic’ failover which Microsoft provides when something happens with the region your IoTHub is living in.

I wanted to test this failover. And I wanted to build a client-side solution so I would not lose any messages.

Let’s see how it can be tested.

Doorgaan met het lezen van “Testing Azure IoTHub Manual failover”

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.

Doorgaan met het lezen van “Azure IoTHub routing revisited, Blob Storage Endpoints”

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:


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!

Doorgaan met het lezen van “Flexible message routing in Azure IoT Hub using C#”

Adding the power of BI to your IoT Hub

Once you are using Azure an IoT Hub, you are looking for ways to do something meaningful with the telemetry coming in.

You can try to build your own dashboards in a website eg. but you can also try to show the data using PowerBI.

In this blog, we will look at how to show some nice charts with live data.

Doorgaan met het lezen van “Adding the power of BI to your IoT Hub”

Passing data between Windows 10 IoT Core headed and headless apps

As shown in my last blog, Windows 10 IoT Core supports headed and headless apps. I can run only one headed (UWP) app at a time but running multiple headless apps is possible too.

But how do I deploy these apps? And can I pass information between apps while running?

In this blog, we dive deeper into the unseen world of background application.

Doorgaan met het lezen van “Passing data between Windows 10 IoT Core headed and headless apps”

Building a Windows 10 IoT Core background webserver

The RaspberryPi is running the core of Windows 10. This means that everything, not needed for running one app at a time, is left out of Windows 10. And with one app I mean, one visual app.

Until now I have always build a Windows UWP app to run something on the RaspberryPi.  And the fact it has a form which can represent visual elements in XAML, it gives away that it is a visual app. These kind of apps are running in headed mode.

But running one visual app, taking the whole screen occupied in headed mode, does not prevent the OS from running multiple background processes in headless mode.

Today we will build our first simple web server on the Raspberry Pi running Windows 10 IoT Core.

Doorgaan met het lezen van “Building a Windows 10 IoT Core background webserver”

Reading IBeacons using a UWP app on your Raspberry Pi

As you probably know, Bluetooth low energy (BT LE)  is a wireless personal area network technology which uses a minimum of power to broadcast messages to receivers nearby.

Bluetooth LE is a common standard but it is most popular under the name of IBeacons. IBeacons is a protocol coming from Apple, so it is just a class of Bluetooth low energy (LE) devices that broadcast their identifier to nearby portable electronic devices.

IBeacons can basically exchange two parts of data: that unique identifier and the signal strength. This makes it possible to figure out the (fixed) position of the IBeacon. And if you receive the signals of multiple beacons you can triangulate your own position between them.

In 2015 Google launched a competing, but similar, beacon standard called Eddystone. It has a richer functionality because it can exchange more information.

Far less known is that Windows 10 also supports the beacon technology, it’s not just Apple and Android which are having fun with it. In Windows, there is this Windows.Devices.Bluetooth.Advertisement library:
“It allows apps to send and receive Bluetooth Low Energy (LE) advertisements.”

Doorgaan met het lezen van “Reading IBeacons using a UWP app on your Raspberry Pi”