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:
A daemon (process) that secures the runtime and start the local part of an Azure IoT Edge solution
The open-source Moby container runtime where the modules will be hosted in
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.
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:
Devices exposing their Model ID
IoT Hub storing the Model ID as a reference in the IoT Hub registry
Consuming this Model ID by other Azure resources
Looking up the actual Model in a Device Models Repository
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.
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.
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
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.
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…):
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.
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.