One Azure IoT accelerator to rule them all

The family of Azure IoT resources is very diverse. If you know what you are doing and have developers available you can have a great time with the many PaaS cloud resources.

If you have devices which need internet connectivity but you have no developers, you can check out IoT Central, the SaaS IoT solution.

Recently, Microsoft announced a very powerful integration with other leading IoT Platforms like SAP Leonardo and PTC Thingworx. Both can connect directly with the Azure IoT Hub, the cloud gateway. This opens a broad range of integration opportunities.

And last but not least, you can start with prebuild verticals, Azure IoT accelerators, formerly known as Azure IoT suites. If you have developers available but you do not want to start from scratch, check them out. You can deploy a typical accelerator in 15 minutes to see how they behave. And the smart thing is, all the code behind the logic is available for free on Github.

The most known accelerators are:

• Remote Monitoring (version two is based on microservices)
• Connected Factory (support OPC-UA protocol)
• Predictive Maintenance

But there are also third-party accelerators.

If you are a developer or architect, it’s time well spend checking them out!

Remote monitoring

The remote monitoring is a good starting point, it has a lot of out-of-the-box features:

In one of our current projects, we were looking for a rule engine. And while playing with the demo of the Remote Monitoring Accelerator, we stumbled on one.

The picture shown above is not really helping to explain how this rule engine works and you can try to read about it or check out the code on GitHub.

The features of this rules engine are both simple and powerful:

• Define rules for alarms or even actions as JSON files in blob storage
• Bind rules to groups of devices (defined as CSV file in blob storage)
• Rules can react to ‘instant’ messages using Javascript comparisons
• Rules can react to time windows aggregations using Javascript comparisons

And the best feature is that the rules engine is based on Azure Stream Analytics. Therefore it’s modular and it can be separated and reused completely in your own solution.

In this blog, we will see how it’s done.

Event Hub alerts, great for detecting drops in connectivity

If we look at the Azure IoT Reference Architecture we see how streaming data is the heart of the IoT platform:

Data arrives at the IoT Hub and can be routed to any Azure resource using eg. the IoT Hub routing, Stream Analytics jobs and Event Hubs.

This gives us the maximum flexibility to divide the data into three major data streams or storage:

1. Hot path – Event, Alert, Conditions
2. Warm path – aggregated data, data for reporting
3. Cold path – the raw data, mainly untouched and available in large quantities; great for data scientists

But there is an often unseen, even ignored forth stream. And that is the stream of data for monitoring.

In my earlier blogs, I wrote several times hoe heartbeats en watchdogs can tell the story about the quality of the data. And I have shown how eg. Azure Functions and notification services can improve the insights about the quality of the communication.

Today I want to add a little gem to that list.

Let’s check out Monitoring Alerts in Event Hubs. It’s part of the overall Monitoring service in Azure.

A new batch of OPCPublisher direct methods

Recently, Microsoft put some real effort into updating the OPCPublisher project. This application/IoT Edge Module ingests telemetry from an OPC-UA Server.

I already wrote two blogs about it: Getting started with OPC-UA on Azure IoT Edge and Managing nodes from the cloud in the OPC-UA Publisher Edge. The seconds one showed how to connect to the OPCPublisher as an IoT Edge module using DirectMethods.

New methods have arrived, this time we get information about the module itself.

Let’s check them out.

Compare previous and current message in Stream Analytics

Last week I was testing the temporary storage in IoT Edge. I was interested in the stability so I wanted to know if messages were missing or maybe even coming in twice.

I have this heartbeat module which produces a counter. So I am able to generate messages which can be measured as a sequence.

One way is to check this using your eyes 🙂

But this can be seen as a more generic issue, comparing two messages after each other. So I was thinking about Azure Stream Analytics. This should be the perfect tool for this job.

Let’s check out how we can compare subsequent messages using Stream Analytics.

Add rolling logging to your Moby containers

Recently we were testing Azure IoT Edge on VMs which were limited in size. All went well, everything worked as expected until the whole solution stopped working.

After some research, we found out the VM disk was full of data.
This came to us as a surprise. What was eating up the hard disk?

After some more research, we checked out the Azure IoT Edge modules logging location: /var/lib/docker/containers/

Here you find folders, one for each container on your system. These are named after a unique GUID which is related to a specific container.

Note: you might need elevated rights to actually access these folders.

You can compare the folder GUID with the container ID in:

docker ps

If you open one of these folders you will find the logging of the related container.

We can, of course, remove the old logging by removing the files and everything seems to be working again. But that only delays the inevitable.

Let’s see if there is a more permanent solution.

Adding offline capabilities to your IoT Edge device

Azure IoT Edge makes it possible to send messages to your IoT Hub using the extremely flexible IoT Edge runtime and modules.

The runtime also supports temporary offline capabilities in case the IoT Hub is unreachable.

Currently, runtime 1.0.5 is available which makes it possible to set a custom location (folder) in which messages are stored before they are sent to the IoTHub.

Let’s see how this turns out.

Visualize Azure IoT Edge device routes as a flowchart in Asp.Net MVC

If you look at the routes page in Azure IoT Edge configuration wizard, what do you prefer?

The current notation:

Or do you prefer a flow chart like this:

The routes in Azure IoT edge are a clever solution to describe how messages from one module are sent to another. But the JSON notation can become less readable once you add more (up to twenty) modules. That could end up eg. nineteen routes or more!

Just as an experiment I was thinking about how the ease the experience using a graphical interface.

I prefer the second solution, probably just like you.

So let’s look at how you can create the same experience with your routes of your IoT Edge device.