Exploring Azure Digital Twins Graph history

As seen in previous posts, Azure Digital Twins shows the current state of any twin in the Azure Digital Twins graph.

This current state is a combination of multiple items:

• twin name and model
• twin properties updates based on telemetry and/or business rules related to that telemetry
• twin properties updates based on predictions towards the future
• twin properties updates based on historical data

Azure Digital Twins also offers to store historical Twin property data. That historical data is made available using Azure Data Explorer, part of the data history connection, as explained in my previous post.

There, twin data can also be compared with twin graph knowledge using the ADX Kusto plugin for querying the ADT graph.

Still, that accompanying plugin is missing something. We have no historical knowledge of the graph itself including models and how these changed over time!

If we want this information, we need to be creative.

Can we add the missing pieces?

Let’s check out how we can explore the ADT graph history…

Advertentie

Azure IoT Device lifecycle events (part 1)

The Azure IoT Hub is the main gateway for Azure IoT-related device connectivity.

It features several useful features to make your IoT developer life easy.

It offers a registry for devices so each device has its own credentials. Each device is capable to ingest device-to-cloud telemetry data into Azure and the IoT Hub also offers several ways for cloud-to-device communication (e.g. desired properties and direct methods).

The IoT Hub is also capable to report any device change event during the lifecycle of that device:

It can generate messages when a device is created or deleted. It also generated messages when the device twin is changed. It even generates a message when the ‘digital twin’ is updated.

Note: The digital twin update is related to Azure IoT Plug and Play. This is out of scope for this post. Though, an example of the digital twin change event is seen here.

In this post, we will look at the format of these messages.

First look: The Things Network new Azure IoT Hub integration

Right from the start back in 2015, The Things Network supported connecting their LoraWan backend platform to other (cloud) platforms.

Connecting to the Azure cloud was no exception to this.

There was no default integration but the support for the MQTT protocol opened this door. Back then, I already blogged about using MQTT to connect. Based on that logic, bridges appeared for both uplink and downlink messages.

Later on, Microsoft also introduced the secure and flexible IoT Central bridge to connect to The Things Network, based on uplink support for webhooks.

Still, even with the new V3 portal of The Things Network, this integration was still based on either the Webhook integration or the original V3 MQTT interface.

All these techniques require an extra layer of logic between the two clouds.

But…

Finally, a native Azure IoT Hub integration has been made available:

The main features of the Azure IoT Hub Integration are:

• Devices only need to be registered in the Azure IoT Hub. The related TTN application device registrations are kept in sync by TTN. Just use IoT Hub Device Twin tags to control your TTN device registration
• Uplink messages appear both as telemetry and as Device Twin reported property updates
• Downlink messages are sent using the Device Twin desired properties

The current documentation is pretty straight forward (although the DPS service logo is shown, it’s not part of the standard solution).

Let’s check out how this integration works and let’s dive deeper into this solution architecture.

Positioning GPS devices on a map using Azure Functions, Azure SignalR Service and Azure Maps

Last year, I bought this RAK7200 Lora Tracker with the idea to track my bicycle in the neighborhood.

This month, I finally found some time to have this device connected to the cloud and map its position.

This tracker from RAK Wireless, running on a rechargeable battery for multiple days, has several sensors aboard and is connected to a Lora network:

Here you see the payload as presented in The Things Network console:

Potentially, I could even do some alerting based on the movement of the device, even if there is no GPS fix (acceleration, magnetometer).

An uplink payload formatter can be found here. I changed it a bit so the latitude, longitude, etc. are decimals, not strings:

The same goes for the battery power.

Showing a generic location in Azure Maps is not that hard, there are many samples available. But I wanted to have the map updated IN REAL-TIME!

The TTN portal now supports the Azure IoT Hub natively so I was looking for a way to represent the ingested location in Azure Maps.

Azure Maps tiles live inside the browser. I also needed something like Websockets to update the page representing the map. For this, I wanted to use Azure SignalR Service.

Last but not least, I was looking for a lightweight website because I need to host the pages somewhere.

This is the solution I came up with:

Let’s check out how this is done.

Decompressing Azure IoT messages using Azure Stream Analytics

Azure IoT Edge messages are bound to a maximum size limitation of 256KB. Each message sent is divided into chunks of 4KB. The metering of an IoT Hub is based on these chunks.

So, if a message size of 10KB, it is counted as three separate messages.

Note: the chunk size of the IoT Hub free tier is smaller, just 0.5KB.

In a recent project, we were sending messages of more than 70KB. That means almost twenty chunks or even more in additional cases.

This is technically just fine but we were not feeling comfortable about this:

• This means going rapidly through the IoTHub quota of daily messages
• Messages were sent over a metered network

So this could become quite some investment in traffic and chunks.

I checked out if this is possible to limit this message size, there are several solutions.

But first, let’s see how to start compressing messages.

Sending IoT Hub telemetry to a Blazor Web App

For those who are interested in software development for the web using the C# programming language, Blazor is a viable alternative for building progressive websites as compared to Asp.Net Core / Angular / JavaScript.

Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries.

In the past, I already implemented Blazor on the Edge, including message routing.

Now, let’s see how we can integrate a Blazor website with telemetry coming from an Azure IoT Hub in the cloud.

For this to happen, we need this architecture:

So, the moving parts are:

• An IoT Hub with message routing enabled
• Azure Function with IoT Hub / EventHub trigger
• Server-side Blazor website with API Controller integration

Let’s see how this is set up.

Understanding TimerTriggers in Azure Functions

Azure Functions are Microsoft’s way of offering serverless compute.

In essence, Azure Functions are just source-code functions, running on PaaS servers, which are triggered by some external mechanism. You just deploy functions and do not care about the infrastructure underneath it.

Multiple programming languages are supported e.g. C#, Javascript, Java to write your function in.

Multiple kinds of triggers are available. Most of them are related to some event in another Azure resource. For example, adding a blob in Azure Blob Storage (a BlobTrigger) or receiving a message in an Azure Event Hub can trigger the function (a EventHubTrigger).

A function can also expose an external HTTP endpoint. Then a Rest call on that endpoint triggers the function (HttpTrigger).

All these triggers are scalable. The more triggers are fired on the Azure Function, the more functions are executed. If you choose for a consumption plan this can even result in a scale-out on the number of servers (which you do not have configured).

Azure Functions also offers a TimerTrigger. Functions are just triggered by a … timer.

This seems simple but the Timer trigger behaves a little bit differently when executed.

Let’s try understanding the Timer Trigger.

Introducing The Things Network version 3 stack and portal

Since 2016, I have been involved in the world of LoraWan.

The combination of low powered devices together with long-range communication makes this protocol ideal for sending short messages from remote locations. It even supports two-way communication.

One of the most famous players in this knowledge area is The Things Network. They provide a set of open tools and a global, open network to build your next IoT application at low cost, featuring maximum security and ready to scale with LoraWan.

Its community is thriving on both enthusiastic makers, starters, and companies which are building their IoT solution on that backend.

The team behind The Things Network platform, The Things Industries, are now ramping up the third version of the backend stack.

This is not just an update. This is a completely new stack, built from the ground up and the team invests into a clean, portable, open-sourced backend. This new stack is standards-compliant by default and it will support the Lora 1.1 specification too. The V3 backend is designed for scale, for ‘N’ as they say (N customers, N regions, N devices, N versions):

We see the devices and gateways on the left, the V3 stack in the middle, and the third-party cloud integrations (eg. AWS, Azure) on the right.

In this blog, we look at registering a gateway and a device in the new TTN V3 Stack portal. And we integrate cloud connectivity.

It only takes five simple steps to secure your secrets in Azure Functions

As seen in my last blog, we occasionally need to address secrets in Azure Function code. It’s too easy to just copy and paste for example connection strings or passwords in the source code but then you risk exposing your secrets to anyone who can access the code.

It takes only five steps to secure these secrets using an access policy. Let’s fix a common example using the Azure Key vault.

Manipulate IoT Edge Module twin using an Azure Function

We use IoT Central a lot for demonstration purposes. It provides an IoT Dashboard for your IoT devices on a SaaS level. It brings speed into the projects and we can have good discussions about usability with customers.

Recently, I had to add some buttons in IoT Central to manipulate an IoT Edge device. At this moment, IoT Central is not supporting IoT Edge devices but it can be done with a simple trick. So displaying information is not that hard. But sending module twin changes back to the IoT edge is not simply done.

In this blog, I show how to program IoT Edge module twin updates using c#. I use Azure Functions to make this code reachable from other sources like IoT Central.