Handling Advantech Wise 710 OPC-UA telemetry using OPCPublisher

Microsoft has an extensive IoT platform based on Azure.

It provides so many features, this can be overwhelming for customers. Therefore, Microsoft provides Azure IoT solution accelerators, based on the Azure IoT reference architecture.

Some of the original accelerators (it started with Azure IoT suites) like Remote Monitoring are now outdated or even archived. These are replaced by excellent Azure IoT Central apps which demonstrate the capabilities of the IoT platform for numerous markets and verticals:

There is still one original accelerator alive-and-kicking: the Connected Factory. This one demonstrates the use of OPC-UA protocols on the edge and in the cloud.

More than two years ago, I already wrote about this accelerator and the OPC publisher module, the backbone of this accelerator. Since then, a lot has changed. Some functionality is (temporarily) deprecated so I got a lot of questions based on the old blogs.

So it’s time to update it a little and see how the OPC Publisher is doing these days.

The OPC-UA solution is open source and covers a lot:

diagram

I limit this blog to the scope of my very first blog, extracting OPC-UA messages and send them to the cloud using a ‘published nodes’ file.

We just need an OPC-UA server to get some sample data from. For this, I used an Advantech Wise 710 as an industrial protocol gateway.

Doorgaan met het lezen van “Handling Advantech Wise 710 OPC-UA telemetry using OPCPublisher”

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.

Doorgaan met het lezen van “Getting started with the Azure IoT Central Rest API”

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”

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”

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.

Doorgaan met het lezen van “Introducing The Things Network version 3 stack and portal”

“node-red-contrib-azure-iot-hub” considered harmful?

Node-Red is a flow-based development tool for visual programming.

It is intensely popular as a programming environment for controlling events. It’s even built in into hardware for flow-base programming and control and has a large community of proud users.

A library is available also with many nodes for al kinds of use cases. If you search for ‘azure’, three pages of nodes and flows are available.

One of them is this node-red-contrib-azure-iot-hub which is one of the most popular nodes:

This project is open-source and available on GitHub. It comes with sufficient documentation.

I used this for a small project and checked out all features. It works as documented but still, I have some doubt using it in production.

The main issue is that it mixes both the Azure IoT Device SDK and the Azure IoT server-side SDK. This makes it a “Jack of all trades, master of none”.

Let me show what I mean with some examples.

Doorgaan met het lezen van ““node-red-contrib-azure-iot-hub” considered harmful?”

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…

Doorgaan met het lezen van “Azure IoT Central bridge for The Things Network”

Connecting your SenseCAP sensor to The Things Network

If you are interested in measuring IoT telemetry using an ultra low power wide area sensor network solution, the Seeed SenseCAP is an viable choice.

Seeed offers a number of sensors for agriculture and industrial environments, connected to a LoRa network.

I got my hand on this TH sensor, able to read air temperature and air humidity, sending it to the nearest LoRa gateway:

Image result for sensecap TH sensor

Seeed provides a portal for thier sensors called SenseCAP Software. But other LoRa platforms are supported too.

In this blog, I show you how to connect this sensor to The Things Network LoRa backend.

Doorgaan met het lezen van “Connecting your SenseCAP sensor to The Things Network”

Using OPC-Twin for OPC-UA discovery and sending back commands

In the past, I have written multiple blogs about implementing OPC-UA on IoT Edge.

Until now I have written about collecting OPC-UA values and sending them to the cloud using the OPC Publisher.

But this OPC Publisher is actually just a small part of what Microsoft is actually offering regarding OPC-UA.

Microsoft has a team in both Redmond (USA) and Munich (Germany) working on Industrial IoT. Everything they produce is open source. You can find thier work on github.

With the OPC Twin, they also make it possible to discover, register and manage your Industrial Assets with Azure IoT and most of it can be done zero-touch.

Look at this diagram covering OPC-AU on Azure:

architecture.png

To the left, we see a OPC-UA server and an IoT Edge gateway. It is ‘living’ on the factory network. In the middle we see the Azure IoT Hub acting as cloud gateway and to the right, we see the OPC-UA backend which is provided by the IIoT team.

Of course, all of this is open source. And out of the box, a lot is already working.

OPC-UA, the full round trip

In this blog, I want to show how we can discover OPC-UA servers, update the OPC Publisher to read new nodes (exposed by the discovered servers) and I want to send commands back to the OPC-UA servers.

Doorgaan met het lezen van “Using OPC-Twin for OPC-UA discovery and sending back commands”