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.

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.

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!

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.

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.

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.

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.”

Control your Arduino Rover using Firmata and Xbox One Controller

A few month ago I bought a little rover (controlled by an Arduino Uno) for a very good price. The kit was very complete: Car chassis, 2 Car Wheels, 2 DC Gear Motors, a UNO R3, an L298N Dual H-Bridge Motor Controller and several other components.

This rover is meant to be programmed for autonomous operation. Hence an ultrasonic sensor and a servo is also added in the kit. Also a nice Arduino sensor shield 5 is in the kit. Yes, it was a real bargain 😉

But my idea was to use both an Xbox One Controller and the Firmata protocol to drive this one by myself or one of my sons. And it works very well!

Here is a video of the final solution:

In this blog, I will show you how it’s done.

Using your Xbox One controller in a UWP app

One of my original Xbox One controllers became useless a few weeks ago. It started to ‘walk away’ with my left stick. Whenever I released my thumb, it still generated a forward motion, not very handy if you are in the middle of a battlefield…

So I ordered a new one from the Microsoft Store but being a geek, I bought one with the Wireless Adapter for Windows.

This adapter makes it possible to use it on a Windows 10 device, like my laptop.

Using the Visual Studio 2015/2017 IoT Hub Extension and IoT Hub Device explorer

In my previous blog, I presented a simple way to connect a device (actually it was a UWP app) to an Azure IoT Hub. After that, I persisted the messages, sent to the IoT Hub,  into SqlAzure using StreamAnalytics.

This easy example can still be simplified using the recently presented IoT Hub Extension and IoT Hub Device Explorer. In this blog, I will show you how to make use of these tools.

Update: this extension is also available for Visual Studio 2017 (version 1.6 and higher) now. At this moment, it contains basically the same functionality. In the future, I hope, this extension will provide more interesting logic like ‘device twin’ support.