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.

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!

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.

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