Connecting Advantech ICR to Azure IoT using NodeRed

In the past, I have written about that perfect NodeRed node for Azure IoT. Using this node, you can connect to eg. Azure IoT and Azure IoT Central from any NodeRed solution.

I came across the Advantech ICR devices which offer cellular (4G) router connectivity in a ruggedized format and you can add your own custom logic:

You can either put C or Python apps on them and you also can use NodeRed on the V3 and V4 platforms.

Let’s dive into this NodeRed support and have an ICR connected to Azure:

Set up an Azure IoT Edge runtime in a minute

Azure IoT Edge runs on both Windows 10 and Linux, let’s talk about how to set up that Azure IoT Edge runtime.

The current LTS 1.1.* version of Azure IoT Edge still supports Windows containers on Windows devices.

The newest version of Azure IoT Edge, the 1.2.* version supports running only Linux containers on Windows. This is called EFLOW (Edge for Linux on Windows).

So, Microsoft supports both Linux containers on Linux and Windows too. Technically, you have to write only one solution running on both operating systems.

Still, you have to build and push separate container versions of the same logic based on the processor architecture.

Azure IoT Edge runs on most flavors of (Linux) operating systems that can run containers; however, not all of these systems are equally supported. There is documentation available with an up-to-date list of supported operating systems. Check out if your operating system gets either Tier 1 or Tier 2 support.

As an example, Ubuntu 20.04LTS is currently not officially supported in Tier 1.

Update 21-10-2021: During the recent Azure IoT Edge Summit – Technical Track it is announced Ubuntu 20.04 is on the product team near term roadmap and coming soon.

Still, the Azure IoT Edge runtime can be installed and is considered compatible.

That runtime is built up in a few parts:

1. A daemon (process) that secures the runtime and start the local part of an Azure IoT Edge solution
2. The open-source Moby container runtime where the modules will be hosted in
3. A local directory structure for configuration

Regarding the installation of the runtime, you can follow the original documentation.

This guide does not point you to a simple installation. You need to have technical skills to roll out the runtime. And the rollout is done by hand.

Now, a script is provided and maintained by the Microsoft product team that can be used to automate the roll out of the runtime, including support for DPS.

Let’s check this out.

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.

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

https://docs.microsoft.com/en-us/azure/iot-pnp/overview-iot-plug-and-play

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.

Getting started with the Azure IoT Central Rest API

Azure IoT Central is a SaaS platform for IoT projects.

If you are looking for a way to manage and monitor your IoT devices outside the Azure Portal or are not able to build your own IoT platform, IoT Central is the place to be. And you can extend this portal with custom Azure resources using the export functionality.

All you need is to have browser access to Azure IoT Central. You can even run it for free for seven days to test it out. Also, the first two devices registered are free too.

Once you have worked with Azure IoT central, you have mastered it using the portal. If you want to scale up eg. the number of devices or users, automation of your tasks becomes necessary.

For this, Azure IoT Central offers a Rest API.

Let’s check this API out.

Azure IoT Central bridge for The Things Network

During the last The Thing Conference back in January in Amsterdam, The Netherlands, I spoke with the team of Tektelic. I got this smart room sensor from them to experiment with:

This sensor works with Lora and has some neat features. The sensor reads eg. temperature and humidity of the room it is placed in, but it also has a few other sensors. One of these is a magnetic switch.

It’s this sensor I am interested in. I want to see if a door is left open (and maybe putting a big, loud horn next to it…):

Today, I decided to connect this module to Azure IoT Central. For this, we use the Azure IoT Central Bridge.

I already blogged about this bridge where I connected to the Partical cloud. This time, I show how to connect to The Things Network cloud:

These are the steps we have to execute when connecting:

1. Connect the Tektelic Room sensor to The Things Network
2. Convert the byte array with data into a JSON message
3. Setup an IoT Central App
4. Setup the IoT Central Bridge
5. Modify the bridge so it can handle TTN messages
6. Setup a TTN webhook integration to the bridge
7. Create a Device capability model for our room sensor
8. See the influx of telemetry in IoT Central

Yes, there are a lot of small steps to perform. But I did the heavy lifting for you so it should be easy to follow.

Let’s see how to detect if a kitchen door is left open…

Sending telemetry from IoT Edge to IoT Central

After writing my last post, I kept thinking about sending messages to the Azure IoT Central Bridge from Azure IoT Edge.

Eventually, I started building this IoT Edge module which passes incoming route messages to the IoT Central Bridge of your choice.

This module is now available in Docker Hub.

Use it in your IoT device with tag:

svelde/iot-edge-ic-bridge:1.1.0-amd64

Let’s check this module out.

Bridging the gap from third party cloud to IoT Central

A few years ago I blogged about my open source project which makes it possible to connect The Things Network LoraWan cloud to Azure. It runs as a Webjob and provides a stateful bi-directional communication channel so devices from the third party (TTN) cloud are automatically registered in your IoTHub, can communicate their messages to the Azure cloud and they can receive commands back.

Recently Microsoft announced their generic bridge between third party IoT clouds for IoT Central. It is called: IoT Central Device Bridge.

Basically, it supports all cloud services which are able to send device telemetry to a REST endpoint.

Let’s check out how it works.

Tracking the location of your IoT Central devices

Recently IoT Central added location tracking.

In the past, it was already possible to add a location to your IoT Central devices. And these locations were shown on a map. But these locations were fixed, part of the device template properties. So it was only present in the metadata.

But now we can pass a location in the telemetry which is produced by your device.

Let’s see how it’s done and how the location is integrated into the various IoT Central dashboards.

Connection a cheap ESP8266 to Azure IoT Central

IoT Central supports multiple devices at this moment if you start a new IoT Central application:

• Raspberry Pi
• MXChip Developer kit
• Windows 10 IoT Core device

But what if you have other types of devices you want to connect?

Luckily, Microsoft offers help in the form of a GitHub repository. These you find the source code for the devices shown above and several other devices.

This repository is a great way if you want to start connecting with IoT Central with:

• ESP32
• ESP8266
• MBED OS 5.X+ basic example
• HTTP Only

If your device is not shown at the top of this list, you can fall back on HTTP only as long as your device is capable of executing REST calls.

In this blog, we check how well the cheapest device is supported. This is the ESP8266. You can get an ESP8266 for less than three dollars so this is a fun and easy way to start using IoT Central.