azure iot edge | Busbyland - Azure IoT Playground

Azure IoT Edge local and offline dashboards

This post will cover a common ask for customers. How to display, report, or dashboard data locally, even when offline, from Azure IoT Edge

One of the main uses for IoT is to be able to have dashboards and reports showing the latest information off of IoT devices. Often that happens with data sent from the devices to the cloud. In many IoT scenarios, especially in manufacturing, those dashboards also serve the needs of local operators or supervisors in the very plants or locations that supply that IoT data. So often that data “round trips” from the device, up to Azure, then the reports back down to screens at the plant.

But what happens if you need lower latency reporting? Or you lose your Internet connection frequently because your plant is in an area with slow or unreliable connectivity?

A common ask from customer is to, in addition to sending the IoT data to Azure for centralized reporting, ML model training, etc to also have the data ‘reported/dashboarded’ locally. That allows for lower latency display, as well as continued operation in the event of an Internet failure.

To address this need, I’m happy to announce that Azure IoT Global Black Belt counterparts have published guidance and a sample implementation on how to do just this. The sample implementation happens to be a common manufacturing KPI called Overall Equipment Effectiveness (OEE), but could be adapted to many other scenarios such as retail stores, warehouses, etc.

Please check it out at our github repo -> https://github.com/AzureIoTGBB/iot-edge-offline-dashboarding

Enjoy! And, as always, hit me up in the comments if you have questions.

raw AMQP to IoT Hub and IoT Edge

It seems like lately my life has consisted mostly of trying to figure out how to connect “brownfield or legacy systems” (that’s MSFT-speak for “doesn’t use our IoT device SDKs” :-)) to Azure IoT Hub or Azure IoT Edge or both. I’ve previously in other posts shown how to do it with raw MQTT, Mosquitto, and Node-Red.

I was recently asked by a customer for a sample of connecting a raw AMQP client to IoT Edge. So with unbridled optimism, I quickly did a web search to hunt down what surely already existed as a sample. Both google and bing quickly dashed my hope for that (as they so often do). Even StackOverflow, the best hope for all development-kind failed me! So I waded in to figure it out myself.

Setting the stage

Just for simplicity, I used the python uamqp library for this. This is the AMQP library (or at least the C version of it) that we use ourselves underlying IoT Hub and IoT Edge (and service bus, event hub, etc), so it seemed like a natural fit. And it also came with a sample that I could start from and adapt. The code further below and information in this post is based on that sample. The primary two issues with the sample out of the box was that it used a ‘hub-level’ key vs. a device-scoped key for authentication to IoT Hub (don’t do that!) and for some reason it was written to show device-bound (cloud to device) connectivity vs. cloud-bound (device to cloud, aka ‘telemetry’) messaging. So I adapted the sample for my needs, and will show the adaptations below.

While it took me a little time to figure things out, the two most complicated parts where

Figuring out the right AMQP connection string format to connect to IoT Hub/Edge. This is normally handled under the covers with our SDKs, but getting it right without the SDKs took a little research and trial/error
Figuring out how to get the client to trust the certificate chain that edgeHub presents to connecting clients for TLS connections (for more details on how Edge uses certs, see this article by my very favorite author!). This second bullet is only needed if you are connecting to IoT Edge. The right root-ca certs (i.e. Baltimore) are embedded in the uamqp library for IoT Hub itself.

The format for the AMQP connection string is actually already documented here by our engineering team (under the “protocol specifics” section), but it’s not called out very obviously like the entire sub-article we have for MQTT, so I actually missed it for a while. If you use a device-scoped key (which you generally should), the correct format for the AMQP connection string is:


amqps://[device_id]@sas.[short-hub-name]:[sas-token]@[target-endpoint]/[operation]

where:

[device_id] is an iot-hub registered device id for an IoT device
[short-hub-name] is the name of your IoT Hub *without* the .azure-devices-net
- NOTE: the combination of device_id and short-hub-name, which collectively is the ‘username’ in the connection string, must be URL encoded before sent
[sas-token] is a SAS token generated for your device
[target-endpoint] is either the name of your IoT Hub *with* the .azure-devices.net in the case of an IoT Hub direction connection OR it’s the FQDN of your IoT Edge box in the case of connecting to IoT Edge (i.e. mygateway.contoso.local)
[operation] is the desired operation. For example, to send telemetry data, operation is /devices/[device id]/messages/events

Just to show an example of what the connection string looks like with a live device and hub, below is an example of one of mine (with a few random characters in the sas-token changed to protect my hub :-))


amqps://amqptest%40sas.sdbiothub1:SharedAccessSignature+sr%3Dsdbiothub1.azure-devices.net%252Fdevices%252Famqptest%26sig%3DyfStnV4tfi3p7xeUg2DCTSauZowQ90Gplq3hKFzTY10%253D%26se%[email protected]/devices/amqptest/messages/events

where:

amqptest is the device id of my device registered in IoT Hub
sdbiothub1 is the name of my IoT Hub
mygateway.contoso.local is the FQDN of my IoT Edge device (not really, but you don’t need to know the real one…)
/devices/amqptest/messages/events is the ‘operation’ I’m invoking, which in the case of IoT Hub/Edge means to send device-to-cloud telemetry data

The code

ok, enough pre-amble, let’s get to the code

NOTE:  Please note - strangely enough, as of this writing (3/7/2019) the code and post below will NOT actually work today.  During my work and investigation, and working with one of the IoT Edge engineers, we discovered a small bug in edgeHub that prevented the raw AMQP connection string from being parsed correctly. The bug has already been fixed, per this pull request, but the fix won't be publicly available until later this month in the next official release.  But, since I'm internal MSFT and "it's good to be the king", I was able to get a private build of edgeHub to test against.  I'll update this post once the fix is publicly available.  (technically, if you really want it, you can do your own private build of edgeHub, since it's open source

The first step in using the sample is to install the uamqp library, the instructions for which can be found here.

Below is my modified version of the sample that i started with. I tried to annotate any change I made with a preceding comment that starts with #steve, so you can just search for them to understand what I changed, or just use the sample directly


#-------------------------------------------------------------------------

# Copyright (c) Microsoft Corporation. All rights reserved.

# Licensed under the MIT License. See License.txt in the project root for

# license information.

#--------------------------------------------------------------------------



import os

import logging

import sys

from base64 import b64encode, b64decode

from hashlib import sha256

from hmac import HMAC

from time import time

from uuid import uuid4

try:

    from urllib import quote, quote_plus, urlencode #Py2

except Exception:

    from urllib.parse import quote, quote_plus, urlencode



import uamqp

from uamqp import utils, errors



#steve - added to share the SAS token and username broadly

sas_token = ''

auth_username = ''



def get_logger(level):

    uamqp_logger = logging.getLogger("uamqp")

    if not uamqp_logger.handlers:

        handler = logging.StreamHandler(stream=sys.stdout)

        handler.setFormatter(logging.Formatter('%(asctime)s %(name)-12s %(levelname)-8s %(message)s'))

        uamqp_logger.addHandler(handler)

    uamqp_logger.setLevel(level)

    return uamqp_logger



log = get_logger(logging.DEBUG)



def _generate_sas_token(uri, policy, key, expiry=None):



    if not expiry:

        expiry = time() + 3600  # Default to 1 hour.

    encoded_uri = quote_plus(uri)

    ttl = int(expiry)

    sign_key = '%s\n%d' % (encoded_uri, ttl)

    signature = b64encode(HMAC(b64decode(key), sign_key.encode('utf-8'), sha256).digest())

    result = {

        'sr': uri,

        'sig': signature,

        'se': str(ttl)}

    #if policy:

    #    result['skn'] = policy

    return 'SharedAccessSignature ' + urlencode(result)





def _build_iothub_amqp_endpoint_from_target(target, deviceendpoint):

#steve - reference global sas_token and auth_username because we will use it outside this function

    global sas_token

    global auth_username



    hub_name = target['hostname'].split('.')[0]



#steve - the format for a *device scoped* key for amqp is

# [deviceid]@sas.[shortiothubhubname]

# this is the same for both IoT Hub and IoT Edge.  This is a change from the original sample

# which used a 'hub scoped' key

    endpoint = "{}@sas.{}".format(target['device'], hub_name)

#steve - grab the username for use later..  before the URL-encoding below

    auth_username = endpoint



    endpoint = quote_plus(endpoint)

    sas_token = _generate_sas_token(target['hostname'] + deviceendpoint, target['key_name'],

                                    target['access_key'], time() + 36000)



#  steve - the first line below is used for talking to IoThub, the second for IoT Edge

#  basically we are just changing the connection endpoint

#    endpoint = endpoint + ":{}@{}".format(quote_plus(sas_token), target['hostname'])

    endpoint = endpoint + ":{}@{}".format(quote_plus(sas_token), target['edgehostname'])

    return endpoint



def test_iot_hub_send(live_iothub_config):

#steve - reference my globals set earlier

    global sas_token

    global auth_username



    msg_content = b"hello world"

    app_properties = {"test_prop_1": "value", "test_prop_2": "X"}

    msg_props = uamqp.message.MessageProperties()

#steve - honestly dunno what this property does :-), but we aren't going devicebound, so nuked it

#    msg_props.to = '/devices/{}/messages/devicebound'.format(live_iothub_config['device'])

    msg_props.message_id = str(uuid4())

    message = uamqp.Message(msg_content, properties=msg_props, application_properties=app_properties)



#steve - the original sample was set up for cloud-to-device communication.  I changed the 'operation'

# to be device-to-cloud by changing the operation to /devices/[device id]/messages/events

    #operation = '/messages/devicebound'

    deviceendpoint='/devices/{}'.format(live_iothub_config['device'])

    operation = deviceendpoint + '/messages/events'

    endpoint = _build_iothub_amqp_endpoint_from_target(live_iothub_config, deviceendpoint)



    target = 'amqps://' + endpoint + operation

    log.info("Target: {}".format(target))



#steve - this is where the magic happens for Edge.  We need a way to specify the 

# path to the root ca cert used for the TLS connection to IoT Edge.  So we need to 

# manually created the SASLPlain authentication object to be able to specify that

# and then pass it to the SendClient method below.  All of that is not necessary

# just to talk directly to IoT Hub as the root Baltimore cert for IoT Hub itself is buried

# somewhere in the uamqp library

# if you are connecting to IoT Hub directly, you can remove/comment this line

    auth_settings = uamqp.authentication.SASLPlain(live_iothub_config['edgehostname'], auth_username, sas_token, verify=live_iothub_config['edgerootcacert'])



#steve - for iot hub  (simple because we don't have to worry about the edge TLS cert

#    send_client = uamqp.SendClient(target, debug=True)

# for iot edge

    send_client = uamqp.SendClient(target, debug=True, auth=auth_settings)

    send_client.queue_message(message)

    results = send_client.send_all_messages()

    assert not [m for m in results if m == uamqp.constants.MessageState.SendFailed]

    log.info("Message sent.")



if __name__ == '__main__':

    config = {}

#steve - changed from environment variables to hardcoded, just for this sample

#    config['hostname'] = os.environ['IOTHUB_HOSTNAME']

#    config['device'] = os.environ['IOTHUB_DEVICE']

#    config['key_name'] = os.environ['IOTHUB_SAS_POLICY']

#    config['access_key'] = os.environ['IOTHUB_SAS_KEY']

    config['hostname'] = 'your long iothub name'  # e.g. 'sdbiothub1.azure-devices.net'

    config['device'] = 'your device id'  # e.g. 'amqptest'

    config['key_name'] = ''  # leave empty string

    config['access_key'] = 'your primary or secondary device key'   # e.g 'P38y2x3vdWNGu7Fd9Tqq9saPgDry/kZTyaKmpy1XYhg='

#steve - the FQDN of your edge box (i.e. mygateway.local)

# it MUST match the 'hostname' parameter in config.yaml on your edge box

# otherwise TLS certificate validation will fail

    config['edgehostname'] = 'your FQDN for your edge box'  # e.g. 'mygateway.contoso.local'

#steve - path to the 'root ca' certificate used for the IoT Edge TLS cert

    config['edgerootcacert'] = 'the path to your root ca cert for edge'  # e.g. '/home/stevebus/edge/certs/azure-iot-test-only.root.ca.cert.pem'



    test_iot_hub_send(config)

The code is a little hard to read in blog format, so feel free to copy/paste into your favorite python editor to view it.

The key changes are to the line that generates the ‘username’ for the connection string, changing it from a ‘hub level’ key to a device-level key


endpoint = "{}@sas.{}".format(target['device'], hub_name)

and the two lines that allow me to customize the SASLPlain authentication information to add in the path to the IoT Edge root CA cert


auth_settings = uamqp.authentication.SASLPlain(live_iothub_config['edgehostname'], auth_username, sas_token, verify=live_iothub_config['edgerootcacert'])



send_client = uamqp.SendClient(target, debug=True, auth=auth_settings)

When you run the sample, you’ll see a ton of debug output. At the top you should see your connection string dumped out, but most importantly, if it works, you should see a line like this somewhere in the middle of the output


2019-03-07 19:00:15,893 uamqp.client DEBUG Message sent: &lt;MessageSendResult.Ok: 0>, []

This indicates a successful sending of a message to IoT Hub/Edge.

Enjoy, and as always, feel free to ping me via my contact page and/or via comments here

Connect Node-Red to Azure IoT Edge

NOTE: updated on 2/14/2019 to add the note about adding the content type and content encoding to the MQTT topic if you want to route messages based on the message body in IoT Edge

Recently on behalf of a customer, I was asked if it was possible to connect Node-Red to Azure IoT Edge. Node-Red, an IBM sponsored graphical process design tool, is increasingly popular in IoT scenarios.

My first thought was “well sure, there is an IoT Hub ‘node’ for Node-Red, surely it can be used for connecting to IoT Edge”. Well, looks like it can’t. For two reasons, 1) it’s not designed to do that (no way to specify the edge box/GatewayHostName) and 2) it’s not very good Smile . There are a couple of other options out there, too, but none of the IoT Hub specific ‘nodes’ will work for this use case.

Secondly, and this is really cool, my Azure IoT Global Black Belt peers in Europe have developed an IoT Edge module that hosts Node-Red inside Edge itself, where you can orchestrate your IoT process, and have it drop messages on edgeHub for further edge processing and/or uploading of messages to IoT Hub. *If* you are interested in hosting and managing Node-Red from inside IoT Edge itself, you should definitely check it out. It’s really nice.

With that said, a lot of customers (including the one that prompted this post) either already have a Node-Red environment outside of IoT Edge, or just for a host of reasons want to keep them separate. If so, this post is for you. Since the IoT Hub ‘node’ won’t seem to work for this use case, we are going to use the MQTT node. One thing to note – this only addressed device-to-cloud telemetry. I haven’t (yet) addressed cloud-to-device management/messages/configuration because my customer’s use case didn’t (yet) need it. Baby steps.

First of all, let’s get some pre-requisites out of the way.

Pre-requisites

For this post, I assume a number of things:

You’ve already got a Node-Red environment up and going. If not, follow the directions to do so from the Node-Red site. I also assume you have some familiarity with Node-Red. If you don’t, they have some nice tutorials on the site. Make sure Node-Red is running (node-red-start from the command prompt)
You already have Azure IoT Edge setup as a transparent gateway and have confirmed that you can connect to it over the 8883 MQTT using the handy openssl command included in the docs (this is necessary because Node-Red will be connecting to IoT Edge as a “leaf” or “downstream” device). NOTE: make sure that whatever name you use in the hostname parameter in your config.yaml file is the same resolvable name that you will use from Node-Red to connect to the IoT Edge box. If you have to change it in config.yaml to match, restart iot edge before proceeding.
From your IoT Edge box, copy/download/ftp/whatever the root CA cert that was used to set up the IoT Edge box. If you used a ‘real’ cert (i.e. from DigiCert, Baltimore, etc), then you’ll need to get the public key cert from them in the form of a pem or crt file. If you used the convenience scripts from the transparent gateway instructions above, it’s the cert labeled azure-iot-test-only.root.ca.cert.pem in the ‘certs’ folder underneath whatever folder you generated your certs in. Just grab that file and get it to your local desktop, we’ll need it later.
Your IoT Edge box is reachable, network-wise, from your Node-Red box. Can you ping it? Can you resolve it’s DNS name? Can you telnet to 8883?

In my case, I ran everything (Node-Red and IoT Edge both) from a single Raspberry Pi that I had laying around. But beyond the requirements for Node-Red and IoT Edge themselves, there is no requirement for specific OS’es or co-location, as long as they can see each other on the network, and IoT Edge can get to IoT Hub.

Setup

Ok, enough caveating and pre-req’ing, let’s do some setup.

One of the things you will need is an IoT Hub device identity in the hub to represent our Node-Red flow. If you haven’t already, create an IoT Device to represent our Node-Red “device” (the flow). Go ahead and capture the “device id”, and URI of the Hub (something.azure-devices.net).

You will also need a Shared Access Signature, a token that authenticates the device to IoT Hub. The easiest way to generate one is to open up a cloud shell instance in the azure portal. To do that, click on the Cloud Shell button in the top nav part of the portal. It looks like this:

You may have to go through some preliminary setup (select a blob storage account, etc) if it’s the first time you’ve done it. You can use either Powershell or Bash. I prefer Bash myself, but both work.

Once the cloud shell is created and you have a command prompt, the first thing we have to to do install the azure iot hub extension for the azure cli interface. You can do this by running this command

az extension add –name azure-cli-iot-ext

You only have to do it the first time, it ‘sticks’ for subsequent times you use the cloud shell. Once this is done, you can generate your SAS token with this command:

az iot hub generate-sas-token –d [device id]-n [hub name] –du [duration]

where [device id] is the device id from the device you created earlier, [hub name] is the short name of your IoT Hub (with the .azure-devices.net) and [duration] is the amount of time, in seconds, you want your toke to be valid. Shorter values are more secure, but longer values are easier to manage (you have to re-create and re-configure the token in Node-Red when it expires). It’s up to you to figure out your best balance between security and convenience Smile . I will remain silent on the topic here.

Once you generate your token, you need to copy it somewhere, as we’ll need it later. The process will look something like this (click on the picture to enlarge):

You need the part that starts with “Shared Access Signature”, without the quotes. Highlighted in yellow in the picture. NOTE in the picture that ‘sdbiothub1’ is the name of my IoT Hub used in this demo. Also note that I used a duration of 60 seconds, so you can’t monkey with my IoT Hub. Not that you would ever do anything like that.

Ok, we have all the information we need to get started.

IoT Edge and IoT Hub debug prep

There’s really nothing else we need to do in order to get IoT Edge and IoT Hub ready, but we’ll do a couple of things to have them ready in the background to both debug our Node-Red setup and see the messages flow through if when we are successful.

On the IoT Edge box, run

iotedge logs –f edgeHub

This brings the edgeHub logs up and ‘follows’ them so we’ll be able to see our Node-Red box connect.

In the cloud shell that you have open in Azure, run this command

az iot hub monitor-events –n [hub name] –timeout 0

where [hub name] is your IoT Hub name as before. This will monitor messages that make it to IoT Hub so we can see our messages flow in from Node-Red.

Just leave those things up and running in the background and we’ll come back to them later (you can CTRL-C to get out of them later when ready)

Let’s set up our Node-Red instance.

Node-Red configuration

On your Node-Red box, bring up the Node-Red configuration page in your browser (typically http://nameofyournoderedbox:1880)

You’ll have a blank canvas. You can do something more sophisticated later, but for now we’ll just do a VERY simple flow to show messages flowing to IoT Edge. We are using a very simple flow for two reasons — to show just the main concept of connecting to IoT Edge and because my Node-Red skills are every bit as awesome as my blog writing skills.

From the node palette on the left hand side, grab the MQTT node from the *output* (not input) section of the palette and drop it on the design canvas. Also grab an Inject node from the input section and drop it on the canvas. Connect the output of the Inject node into the input of the MQTT node, as shown below (your MQTT node won’t say ‘connected’ yet).

Double click on the MQTT node to configure it.

In the ‘name’ field at the bottom, just give it a name you like. Doesn’t matter what it is
For QOS, choose either 0 or 1 . IoT Hub/Edge do not support QOS 2.
For the TOPIC, enter devices/[device id]/messages/events (where [device id] is the device id you registered earlier in IoT Hub)
NOTE: *if* your payload is JSON, and *if* you think you might want to do routing of the messages based on the *body* of the message, you need to send a content type of ‘application/json’ and a content encoding of ‘utf-8’ (or 16, etc). to do that, we need to append that information (url-encoded) to the MQTT topic, which gets passed in as a system property. So, in that case, the ‘topic’ call would look like this (note the ‘/$.ct=application%2Fjson&$.ce=utf-8’ appended to the MQTT topic)
- devices/[device id]/messages/events/$.ct=application%2Fjson&$.ce=utf-8

Below is a screen shot of mine. Ignore the “Server” field in the screenshot, as we haven’t configured that yet. For my ‘device id’, I called my device nodeRedTest for this and subsequent screenshots

I have Retain set to false, but I really have no idea if that makes any difference or not. I’m not a Node-Red or MQTT expert, although I do play one on conference calls with customers Smile .

Ok, next we will configure our ‘server’. Click on the little edit pencil next to the Server box

Give your ‘server’ a name (doesn’t matter what it is – I called mine iothub-mqtt in the screenshots). On the Connection Tab,

for the Server box, enter the hostname of your IoT Edge box (exactly as it’s specified in config.yaml and we verified we could resolve earlier)
Change the port from 1883 to 8883 (the MQTT over TLS port)
CHECK the Enable Secure (SSL/TLS) connection box. We will come back and configure that in a moment.
For the “Client ID” box, enter your IoT device ID from earlier
UNCHECK the “use legacy MQTT 3.1 support” box. IoT Edge does not support legacy MQTT connections

Example values based on my setup are shown below. ‘rpihat1’ is the hostname of my IoT Edge box.

Click on the ‘Security’ Tab

For the username, enter “[hub name].azure-devices.net/[device id]/api-version=2016-11-14” (filling in your values for hub name and device id)
For the password, paste in the SAS token, in it’s entirety that you copied earlier

A sample screenshot of mine is below

You don’t need to set or change anything on the Messages tab

Back on the Connections Tab, next to the “TLS Configuration” box, click on the edit/pencil button

Next to “CA Certificate” (the fourth button down), click “Upload”. Upload the root CA certificate that you downloaded earlier.

For the name at the bottom, just make up a meaningful name for this config and click Save

Click Save or Update on the main node configuration box to save all our values and close it as well

We are now ready to save our flow. Click “Deploy” in the upper right to save and deploy your flow.

Checking progress

At this point your flow is running and you should see your MQTT node status as “Connecting” with a yellow dot next to it. Flip over to your IoT Edge box and look at the edgeHub logs. You should see something like this…. (it may take a minute or more to look like this)

For some unexplained reason, the TLS Handshake between the Node-Red box and my IoT Edge box fails exactly seven times before it successfully connects. I have no idea why and haven’t (and probably won’t) put in the effort to troubleshoot. I suspect it’s related to a a 10-second delay between tries and the 60-second refresh value in the node config.. but who knows?

Eventually you should see the successful connection in the logs as shown the bottom half of the picture above.

If you flip back over to your Node-Red canvas, you should have a green dot next to your MQTT node and it should say “connected”

We just left the Inject node configured with it’s default of “timestamp”… it really doesn’t matter what we send our IoT Hub at this point, we just want to see messages go in, and an updating timestamp every time we send a message is handy. NOTE that the Inject node sends ‘timestamps’ in Unix Epoch time (number of seconds since Jan 1, 1970) so it just looks like a big number.

click on the little button (circled in red below) on the Inject node in the Node-Red canvas

This will cause a message to be created and sent to the MQTT node for sending to IoT Edge. That will, in turn, send the message up to IoT Hub.

Flip over to your Azure Portal browser window and you should see your message having made it to IoT Hub. click on the Inject button a few more times to send a few more messages (because it’s fun)

The output should look something like this

Your Node-Red installation is now connected and sending messages through IoT Edge up to IoT Hub. You can now make your Node-Red flow more sophisticated (reading from sensors, etc) and do any and all the goodness that comes with IoT Edge (stream processing, custom modules, machine learning, etc).

If you have any questions or feedback, please leave them in the ‘comments’ section below.

Enjoy!

Connect Kepware KEPServerEX through Azure IoT Edge to IoT Hub

TLDR: I’ve put together step-by-step instruction on how to leverage Kepware’s IoT Gateway as an MQTT-based “leaf IoT device” for IoT Edge.

I’ve gotten the request a few times from customers who leverage, or want to leverage Kepware for connectivity to their manufacturing equipment and then send that data to IoT Hub through Azure IoT Edge.

Microsoft’s recommended solution is to leverage OPC-UA and our IoT Edge OPC-UA publisher. OPC-UA is both a nice industrial protocol, but more importantly, offers a robust data format that plugs in nicely into other Azure services.

However, in cases where customers either can’t, or don’t want to leverage OPC-UA, Kepware already published a nice technical note showing how to connect Kepware via MQTT directly to Azure IoT Hub via Kepware’s IoT Gateway and MQTT. However, customers are interested in how to have the data flow through Azure IoT Edge to take advantage of the many nice edge-processing capabilities available.

So, based on the same principals as my “Connect MQTT client to Azure IoT Edge” post, I’ve put together step-by-step instruction on how to leverage Kepware’s IoT Gateway as an MQTT-based “leaf IoT device” for IoT Edge.

You can check out the instructions here.

Enjoy