How to create your own ‘Deploy to Azure’ button

You probably have seen this button before already:

When you click it, it brings you to a page where you are able to deploy Azure resources in a (new) resource group of your choice.

Once the deployment is started and succeeds, new functionality is running in your Azure subscription.

Can we make use of this functionality our selves? How hard could it be?

Let’s see…

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.

Azure Log Analytics integration for Azure IoT Edge metrics

Recently, I have shown how to interact with Prometheus metrics on the edge, provided by the Azure IoT Edge runtime.

The built-in edge Metrics are great for analyzing what is currently going on in the containers (CPU usage, memory usage, restarts, etc) and on the host (CPU usage, disk usage, etc.).

Since then, this metrics solution is expanded with Azure Monitor workbooks in the Azure portal so we are able to show the metrics in dialogs within Log Analytics workbooks.

Microsoft introduces this extra Metrics collector module. It is already available in the Azure IoT Edge Module marketplace.

Note: this Metrics collector support is still in preview.

Today, I will show how this is done using the preferred way:

Azure IoT Edge Metrics are sent directly to Azure Log Analytics.

The Things Network MQTT integration in Azure

Over the years, I have written multiple articles about working with The Things Network community LoraWan platform.

It all started with this workshop back in 2016 that I built together with my friend Jan Willem Groenenberg where we connected the TTN backend with the Azure Cloud. Over the years, we organized many events based on the workshop.

We needed a ‘bridge’ to bring two worlds together: The Things Network backend applications and the Azure cloud.

I created this TTN azure bridge based on the MQTT protocol supporting a stateful exchange of D2C (uplink) messages from Lora devices to an Azure IoT Hub and supporting C2D (downlink) messages back to the devices.

Since then, the TTN backend migrated twice and now we have this new Version 3 backend with lots of goodies!

I got already some questions about the original bridge and I was informed it is not sufficient anymore so I took some time to revisit the MQTT uplink and downlink support in TTN applications:

We will why this is still a solid solution but we will also look at a possible alternative.

Getting started with Azure IoT Plug and Play

Microsoft is the founder of this concept called Azure IoT Plug and Play:

IoT Plug and Play enables solution builders to integrate smart devices with their solutions without any manual configuration.

The idea is that the device describes itself using some identification key. This key, the Model ID (or DTMI, Device Twin Model Identification), is bound to a complete model written in DTDL (Digital Twins Definition Language).

Using this model, the interface (or capabilities) of this device can be read:

• Properties (Azure IoT Device Twin desired properties and reported properties)
• Telemetry (the D2C messages)
• Command methods (based on Azure IoT Direct methods)

Once a device starts communicating using this deterministic interface, a User Interface can be provided dynamically.

This is the same principle of Plug and Play devices like a mouse or a webcam. If you plug it in, the device is identified as a mouse or webcam and the correct device driver is downloaded from the internet and installed. In the time before Plug&Play, each device came with a CD or floppy disk containing the driver. This was always a hassle, Plug&Play has taken away that pain.

The actual model is stored in a global Device Models Repository. You can create your own repository too.

Look at this Azure IoT Plug&Play architecture/flow:

Here are see the different steps needed to build a solution based on Azure IoT Plug&Play:

1. Devices exposing their Model ID
2. IoT Hub storing the Model ID as a reference in the IoT Hub registry
3. Consuming this Model ID by other Azure resources
4. Looking up the actual Model in a Device Models Repository
5. Building up a tree of device capabilities based on the device model

Once the device capabilities are known, an actual UI can be generated for this device so users can interact with it without any extra effort.

Let’s check out how this works.

OPC-UA node browsing using Traeger SDK

OPC-UA is a modern protocol to unlock M2M communcation.

The OPC Unified Architecture (UA) is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. Building on the success of OPC Classic, OPC UA was designed to enhance and surpass the capabilities of the OPC Classic specifications.

Its popularity is still growing in many markets and for multiple reasons!

Most importantly, from an IoT Developer view, the protocol supports devices to offer a secure communication layers and the exposed tags can be made human readable.

For example, this OPC-UA clients looks at the exposed tags of an OPC-UA server running on an Advantech Wise 710:

In this Prosys OPC-UA client, the tag values are shown:

The nodes are actually mapped Modbus values read from Wise 4012E.

As you can see, it exposes these six values. The potentio meter values shown is made available as a double.

I was asked to provide documentation like this, listing all exposed nodes together with the DataType.

Is it possible to browse nodes?

Getting weather information and predictions from Azure Maps API

If you think about an Azure service named Azure Maps, what is the main purpose that comes into your mind?

That should be map tiles, of course. And that is ok. Azure maps has many features for representing spatial data in all kinds of interactive maps.

Still, Azure Maps has much more to offer. There are also multiple APIs you can use to make calls against like Mobility or Weather.

The information used to create weather maps like these are also available for you using REST API calls:

Let’s check out how we can consume this interface.

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 quotum
• 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.

Supporting Azure Defender for IoT agent on IoT Edge device

More than two years ago, I wrote a blog post about introducing Azure cloud security on the Edge.

This, now labeled ‘classic’ version of Azure IoT Security, was based on AuditD and filled an important need: getting insight into the security of IoT devices.

Though, as with many things, the world moves on.

Microsoft reconsidered the solution and decided to spice it up a little bit.

They now offer a new edition supporting both an agent-based and an agent-less solution.

If you are interested (and you are when you own large networks with many devices!) in the agent-less solution, please check out this great demonstration on the Internet of Things show.

This agent-less solution is especially powerful in large solutions with many devices on the network:

You just install this Azure Defender for IoT ‘sensor’ device within the network and it starts inspecting that network for possible threats based on deep-packet inspection and updated threat-analysis logic coming from Microsoft.

In contrast, Here is shown how the current agent-based solution is rolled out:

As seen in the picture an agent, running as a daemon process on your (Linux) host (Azure RTOS is supported too), checks for possible vulnerabilities and passes it on to the cloud, to an IoT Hub.

There, the situation (and possible threats) is visualized in the Azure Defender for IoT portal panes.

When I checked out the documentation, I also expected support for Azure IoT Edge… but it seems there is no Azure IoT Edge Docker module support.

It only describes running that solution based on a daemon. This daemon is just a process that is secured using Azure IoT Device Module Identity credentials.

The identity is a separate security key apart from the Azure IoT device runtime security keys.

So, do we need to register a second Azure IoT Device, deployed side-by-side to an Azure IoT Device just to have the host secured?

Or, how can we integrate this daemon in a device running Azure IoT Edge?