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.

How to start programming a Siemens Logo PLC

If you visit my blog on a regular basis, you see me blogging a lot about Azure IoT Edge. This means that logic is deployed from the cloud onto Industrial PCs (or a more moderate, non-industrial, Raspberry Pi).

But this is just the ‘third’ generation of automatically controlling machines.

The first generation are magnetic contactors or relay like this one:

The logic is ‘hardcoded’. If some inputs are set, some outputs are set; or not. With each kind of relay comes some internal schematics:

It’s easy to see the limitations of these kind of relays. Wouldn’t it be great to program a similar relay a bit more dynamicaly using a little bit of software?

Enters the second generation: PLCs or Programmable Logic Controllers:

I got my hands on a Siemens LOGO! 230R. Although this model is not sold anymore, its programming model is still valid. Newer models have more capabilities but still rely on the same basic functionality.

Let’s check out on how to program this PLC.

IoT sessions at Microsoft Ignite 2019

Microsoft Ignite on November 4-8, 2019, in Orlando, Florida will be brought to you with all the sessions you want to see and exclusive interviews with leaders you want to hear from. Stream select sessions live and deep dive in the future of technology.

Watch the Microsoft Ignite live show on the event website: https://www.microsoft.com/ignite. Catch announcements on the latest technologies, view the most popular talks, get behind-the-scenes interviews with product engineers and see how to access to the 1,000+ technical sessions being streamed live during Microsoft Ignite.

Check out all (IoT) sessions and keynotes.

Note: Most of the videos are now made available (I marked it in the link). Some videos are even available for download.

Add some cognitive abilities to your IoT Edge

The heart of Azure IoT Edge logic is the availability to add Docker containers with the functionality of your choice.

You can create your own module using the VS Code or Visual Studio extension for IoT Edge in various languages (eg. C#, NodeJS, Python, Java, C).

But you can also use existing modules. IoT Edge is capable to ship whatever container you have as long as it is available in a container registry. The only limitation it has is to get them running using the zero-touch approach of Azure IoT Edge.

Microsoft has created a special marketplace where modules are advertised and ready for deployment to the IoT Edge device of your choice. Here is a selection of what is offered:

Note: the filter has no usage at this moment.

On this marketplace, Microsoft also advertises its four cognitive services. These analyze text on the edge and in the cloud using container support:

These modules are:

• Language Detection Container – For up to 120 languages, detects and reports in which language the input text is written.
• Sentiment Analysis Container – Analyzes raw text for clues about positive or negative sentiment for a limited amount of languages.
• Key Phrase Extraction Container – Extracts key phrases to identify the main points for a limited amount of languages.
• Language Understanding Container – Loads a trained or published Language Understanding model, also known as a LUIS app, into a docker container and provides access to the query predictions from the container’s API endpoints.

Let’s check out how we can deploy and use them on the edge.

Azure IoT Community avond – 30 oktober bij Atos Nederland [Dutch]

Meld je nu aan op https://www.eventbrite.nl/e/tickets-azure-iot-community-avond-2019-bij-atos-73325246787

Welkom bij de zevende Azure IoT Community avond op 30 oktober 2019.

Dit maal hebben we twee sessies over zeer uiteenlopende oplossingen binnen Azure IoT.

Accessing virtual serial ports in Linux using Serial Device Server

Contrary to popular belief, serial port technology from the IT Stone-ages is still alive and kicking.

In the industrial IoT area, serial communication has been proven to be reliable, simple and trustworthy. So if you enter a regular plant, sooner or later you will find some thirty year old device which is still talking serial.

The protocol on serial ports can be a very simple, human readable output. You see this a lot with devices which are/were connected to a (matrix) printer. Each measurement (like the weight from a scale) was printed on one line. You still read these simple lines deviced by carriage return/line feed.

But output can also be more elaborate like NMEA, Telegram or even more exotic formats.

If we are looking at the RS-232 protocol, there is an important physical limitation: the cable length. The communication becomes less reliable when the length of the cable is increased. It’s possible to compensate with eg. a lower baudrate or better quality of cable. The rule of thumb is a maximum of 50 feet/15 meters but I recommend up to 13/feet/3 meters.

Is it possible to bypass this limitation? Yes, this enters the virtual serial port.

With this solution, the physical cable is plugged in into a so-called Device Server or Device Gateway. This gateway is then connected to the same IP network as your target device is (eg. an industrial PC). On this industrial PC, virtual port drivers are loaded which mimic the physical ports on the gateway. The network and gateway becomes transparent for the RS-232 protocol.

So the maximum length of a serial cable can be extended dramatically with the reach of the local IP network.

Let’s check out how this works with a Moxa NPort 5210A Serial Device Server.