IoT Plug and Play, modeling IoT Central devices

If you have built an IoT Device yourself and are finally able to send telemetry to the cloud, you should be familiar with the scenario where you have to repeat the hard work of describing the messages all again on ingestion.

IoT Devices expose D2C telemetry and it can also support C2D communication. This interface is most of the time unique for that device. To be able to get insights from a device you have to be able to react to its interface.

Wouldn’t it be nice if a device was able to provide metadata about its interface once it connects to the cloud? This way, the incoming D2C telemetry could automatically result in e.g. a full user interface. And all C2D output could be represented by pre-configured input controls.

With IoT Plug and Play this is all possible:

IoT Plug and Play enables solution builders to integrate smart devices with their solutions without any manual configuration. At the core of IoT Plug and Play, is a device model that a device uses to advertise its capabilities to an IoT Plug and Play-enabled application

Microsoft provides a way to describe the interface of a device and annotate every feature.

To experience how this works, we will look at the best example: Azure IoT Central.

This SaaS IoT Dashboard makes perfect use of the ability how devices can expose their meta-model.

Let’s see how.

Doorgaan met het lezen van “IoT Plug and Play, modeling IoT Central devices”

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.

Doorgaan met het lezen van “Sending IoT Hub telemetry to a Blazor Web App”

Connecting child devices to the Azure IoT transparent Edge gateway

Getting started with Azure IoT Edge is easy. Microsoft offers quite some tutorials for several operating systems for setting up an edge gateway.

Once you have created your first IoT edge solution and played with it, you discover Azure IoT Edge takes a bit more time to master.

In real-life IoT is hard, though…

This is because there are more moving parts like security, provisioning, managing, monitoring, etc.

For example, take a look at the ‘iotedge check’ output on your edge device:

This feature of the iotedge runtime makes it possible to check how well your runtime is hardened against common scenarios where something can fail (eg. running out of disk space due to extensive logging or firewall blockades for certain protocols).

In this case, a message is shown which indicates the runtime is using a development (x509) certificate which will expire within ninety days. Communication between the edge modules will stop after that date. A reboot/restart of the runtime is needed to get the runtime running again for another ninety days.

What is the purpose of this certificate and why do we need this to be fixed?

As seen in the documentation:

IoT Edge certificates are used by the modules and downstream IoT devices to verify the identity and legitimacy of the IoT Edge hub runtime module

So, apart from the secure connection with the cloud (either with a symmetric key, x509 certificate, or a TPM endorsement), this certificate is used to secure the communication between modules and possible edge devices. If the certificate expires, edge communication comes to a hold.

Let’s check out how to ruggedize the communication.

Doorgaan met het lezen van “Connecting child devices to the Azure IoT transparent Edge gateway”

Turn Node-RED into a first-class citizen Azure IoT connected device

A few months ago, I gave some comments on the node-red-contrib-azure-iot-hub Node-RED module.

The consensus was that the module is OK to be used in the Azure portal but had almost no value within an IoT device.

Just last week, Eric van Uum from the Microsoft IoT Blackbelt team released a brand new Node-RED module which turns your Node-RED into a full Azure IoT device. The feature set is very extensive.

Azure IoT Device node

Let’s see what is offered.

Doorgaan met het lezen van “Turn Node-RED into a first-class citizen Azure IoT connected device”

Azure IoT DeviceClient SDK demonstration, the basics

The cloud gateway of Azure IoT offers multiple protocols to connect to:

Programming all D2C and C2D communication yourself is pretty hard. Microsoft has made it easy to communicate by providing SDKs, both for device communication and IoT Hub manipulation.

In this blog, we dive into what is offered by the Device SDKs.

Doorgaan met het lezen van “Azure IoT DeviceClient SDK demonstration, the basics”

Deploy Azure IoT Edge deployment manifest programmatically

Azure IoT Edge is based on the concept of modules. A module is a container holding some logic executed on the edge device. These containers are actual Docker containers.

These can both be generic containers like a NodeJS that you have produced yourself, an open-source container, or a commercial container. In can also be a container supporting Azure IoT Edge module twins and the routing between modules using one of the Azure IoT Edge SDKs.

Anyway, the modules have to be deployed at one point in time.

By default, Azure IoT Edge devices are constructed with two basic modules registered, the edgeAgent (which is responsible for life-and-death of other modules) and the edgeHub (for enabling message routing between modules and the local gateway towards the cloud):

With life-or-death of other modules I mean the EdgeAgent is responsible for keeping the module configuration on the Azure IoT Edge device in sync with the registration and configuration in the IoT Hub device registration.

For this purpose, the Edge Agent is keen on receiving the so-called ‘deployment manifest‘.

Each time the configuration of an edge device registration in the IoT Hub changes, a new version of the deployment manifest is offered to the Edge Agent. It contains both the module descriptions and their configuration and a description of the message routing on the edge.

The Edge Agent then picks up the deployment manifest and checks for changes with the last manifest it received. If there are any configuration changes, or modules added or modules deleted, the edgeAgent will start the process of synchronizing the deployment.

If you check the documentation, three ways of altering the IoT Edge configuration (and thus deploying a new deployment manifest) are documented:

  1. Command Line Interface (CLI)
  2. The Azure portal
  3. Visual Studio Code

Notice these deployments are effectuated by hand.

For those seeking a CI/CD solution two other ways are offered:

  1. Azure DevOps
  2. Jenkins

These are advised if you want to automate the deployment in a CI/CD pipeline.

If you prefer to do everything by programming source code, you can deploy your manifest using REST calls.

Let’s see how that is done.

Doorgaan met het lezen van “Deploy Azure IoT Edge deployment manifest programmatically”

Securing inbound and outbound ports for Azure IoT

The Azure IoT Hub is able to support a high number of IoT devices, all communicating with their own personal secure connection.

The Azure IoT Hub supports both MQTTs, AMQPs and HTTPs as transport protocols. It’s even possible to communication MQTTs and AMQPs over websockets for Azure IoT Edge.

No, it’s not possible to transfer IoT telemetry and commands without TLS supported communication.

But what if a hacker tries to spoof a device, or our IoT Hub?

How can we be sure that received telemetry is coming from genuine devices? And can we limit the device communication to our own Azure resources?

Do you know who you are talking against?

Let’s see how we can make Azure IoT yet a little bit more secure.

Doorgaan met het lezen van “Securing inbound and outbound ports for Azure IoT”

Subscribe your IoTHub to EventGrid as event source

Azure has all sorts of Publisher/Subscriber resources available to allow sending and receiving messages (events) within Azure. Think of the Service Bus, EventHub, Storage Queue, Stream Analytics, Azure Functions, etc.

At some point, Microsoft realized that a more formal way of the eventing abilities of these resources was needed.

This let to the introduction of the EventGrid, one overall solution to send and receive messages. Azure Event Grid relatively new.

The Azure Event Grid allows you to easily build applications with event-based architectures

The Azure resources are divided into two groups:

  • Event sources. Resources which produce events (or pass-through events)
  • Event handlers. Resources which are able to pick up events and do something with them

These resources all come together in the Event Grid.

Event Grid model of sources and handlers

The Azure IoT Hub can act like an Event Source too. The events exposed are:

Let’s see how we can put this to use.

Doorgaan met het lezen van “Subscribe your IoTHub to EventGrid as event source”

IoT Edge group enrollments using symmetric keys

In my previous blog about using a VM as IoT Edge device, it became clear that this could be used for testing IoT Edge at scale.

Testing IoT Edge at scale means testing device enrollments using the Device Provisioning Service (DPS) and IoT Hub deployments at scale.

We will look at both situations. But before we check out a group enrollment, first we look at an individual enrollment, just for comparison.

We will use the recently announced IoT Edge support for symmetric keys in DPS.

Doorgaan met het lezen van “IoT Edge group enrollments using symmetric keys”