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.

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.

Let’s see what is offered.

Azure IoT DeviceClient SDK demonstration, the basics

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

• MQTT
• AMQP
• HTTPS

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.

Belgische Rijksregisternummer checksum testen (Dutch)

Note: This text is written in Dutch, one of the three official Belgian languages. The code example is annotated in English.

Iedere Belgsiche inwoner heeft een rijksregister nummer. De Belgische overheid kan hiermee alle persoongegevens achterhalen van die persoon. Dit is dus een uniek nummer.

Bij ‘unieke’ nummers in het algemeen is het verstandig om deze nummers slim te kiezen. Als deze direct opvolgend zouden zijn (1, 2, 3, etc.) dan is een typefout snel gemaakt en niet direct op te merken. Daarom worden unieke nummers (zoals nummers op papiergeld of bankrekeningnummers) versterkt met bijvoorbeeld een 11-proef. Het idee is dat alleen correcte nummers dan deelbaar moeten zijn door een priemgetal, zoals elf in dit geval. Als dan toch een typefout wordt gemaakt, wordt dit direct opgemerkt. Een typefout die nog steeds uitkomt op een getal dat ook door 11 deelbaar is, is dan heel klein.

Het Belgische rijksregisternummer is echter niet zomaar een ‘willekeurig’ uniek. Het is opgebouwd uit oa. de geboortedatum.

Hoe is dan het nummer ‘beveildigd’ tegen typefouten?

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.

Turn your M5CAM into a webcam exposing RTSP stream

The ESP32 is a huge hit amongst makers. It’s both powerful and versatile and therefore a good starting point for many IoT projects and POCs.

Several spinoffs are offered where the ESP32 is combined with eg. extra connectivity (LoRa) or cameras.

These ESP32 boards with a camera are known as ESP32CAM but there are many types.

One of them is the M5CAM where an OV2640 Camera Module is mounted on the ESP32 development board:

In this blog, we look at how to turn this M5CAM device into a webcam supporting the RTSP protocol.

Using CrateDB on Azure IoT Edge

During the SPS IPC Drives of 2018, I was introduced to the team of CrateDB.

They offer this blazing fast database:

CrateDB is a distributed SQL database built on a NoSQL foundation. It is familiar to use, simple to scale, and versatile for handling any type of structured or unstructured data with real-time query performance.

It’s always nice being able to choose from several services like databases. So I checked out how to develop a simple application and Azure IoT Edge module against Crate if running in a container.

In this blog, we see how we can use the CrateDB in Azure IoT Edge.

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.

Access Azure API with a bearer token for impersonation

In the past, I wrote an article on how to get Azure service tags. Back then, I was not able to access the Rest API provided.

A service tag represents a group of IP address prefixes from a given Azure service.

This week I revisited the API and dived a little deeper into this call.

In this blog, I show you how to read service tags using the Azure Rest API and we learn how to cope with the bearer token if we want to access the Access API. I show it both in Postman and using C# code.

Microsoft Build 2020 IoT sessions and more

During the recent Build event, a lot of news about Azure IoT announced.

Here is a summary of all online available IoT sessions and workshops, plus some personal favorites from which I think this is interested for IoT Developers.