Create your own local Azure IoT Edge dashboard

Earlier this year, when Azure IoT Edge was still in Public Preview, I wrote a couple of blogs about Visualizing Azure IoT Edge using local dashboard.

Back then, I had to do some magic with both a C# IoT Edge module, a custom NodeJS docker container, and a Docker network to get it running.

Since then, a lot has changed. Microsoft already released a ton of new features. a And there is still more to come regarding the Azure IoT platform.

But that awkward local dashboard solution was nagging me. A few months ago, Microsoft introduced a NodeJS module as a first-class citizen for IoT Edge modules.

So it was time to pick up the gauntlet and use NodeJS for this awesome local IoT Edge dashboard:

#tldr;  If you like to dig into the code, zip it, clone it, extend it or even make a pull request, I made this project open source. If you only want to use it the easy-going way, pull it from docker eg. ‘svelde/localdashboard:1.0.1-amd64′.

At this moment, only Linux containers are supported. It is tested both on Windows and Ubuntu as host OS.

Interested in this module? Let’s see how you can use it.

This Azure IoT Edge module ingests routed messages, displays the values from the telemetry on a dashboard and it is running locally.

To show that dashboard, we need an HTML file loaded from disk. And you can provide your own HTML file. Start by extending the example HTML page available in this module as an example.

port 4242

The local dashboard can be reached at port 4242. Try http://localhost:4242 in your favorite browser.

tempSensor

By default, the tempSensor example module from Microsoft is supported. You can reference it while setting modules in your IoT Device: ‘mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0.4’.

Note: this temperature sensor simulation only sends 500 messages in a row by default. See the documentation to extend this number.

Routing

Messages must be routed to input route ‘input1‘. The same messages are passed through using output route ‘output1‘.

Use the following routes as an example:

{
  "routes": {
    "sensorToWebNode": "FROM /messages/modules/tempSensor/outputs/temperatureOutput INTO BrokeredEndpoint(\"/modules/ld/inputs/input1\")",
    "route": "FROM /messages/modules/ld/outputs/output1 INTO $upstream"
  }
}

Container Create Options

Use the following Container Create Options when adding this module:

{
  "ExposedPorts": {
    "4242/tcp": {}
  },
  "HostConfig": {
    "Binds": [
      "c:/iiotedge:/appdata"
    ],
    "PortBindings": {
      "4242/tcp": [
        {
          "HostPort": "4242"
        }
      ]
    }
  }
}

This makes port 4242 accessible from outside the container.

Note: The port number is ‘hardcoded’.

You can change the binding a little bit. E.g. In this case, the binding name ‘appdata‘ is pointing to the local directory ‘c:\iiothedge’ (check out that forward slash). You can use another directory if needed.

In Linux, you can write something as ‘/ld:/appdata’. The folder ‘ld’ will be created automatically directly in the root folder.

Note: The binding name ‘appdata’ is obligated.

Note: if the HTML file can not be found in the folder provided, the default dashboard (normally used for the Microsoft temperature simulation) is shown.

Module Twin, desired properties, reported properties

By default, the module will load the HTML file named ‘index.html’ which is available either in the within the module or in the binding folder.

You can override the filename with this Module Twin desired property:

{
  "properties.desired": {
    "fileName": "indexlocal.html"     
  }
}

When accepted, the HTML filename used is reported back in the reported twin properties.

Note: if no file with this filename can be found in the binding folder, the default dashboard for the tempSensor is shown.

Extend the Module Twin

The desired properties are passed through to the HTML file. So you can use this mechanism to control behavior within the local dashboard from the cloud.

Custom dashboard

Provide your own HTML file using both the binding folder and the module twin. Start by using the ‘index.html‘ in this module as an example.

Once you have changed the HTML file in the binding folder, a refresh of the browser page should be sufficient to see the changes. Or perform an ‘iotedge restart ld‘ where ‘ld‘ is the alias of your local dashboard module.

I added several extra templates in a Templates folder. You can see the messages which are ingested as comments within the HTML.

Keep in mind the browser takes a lot of local compute power away from the PC. I ran into trouble when CPU exceeded 90% (using a very lightweight industrial PC). In Linux, the best results are gotten using the Midori web browser. In Windows, the dashboard runs very well in Firefox.

Work in progress

This module is a work in progress. There are still a few things that could be done better. The port number is hardcoded at the moment. And the HTML file is not deployable from the cloud. Feel free making this module even more useful by submitting pull requests on Github.

Conclusion

This dashboard is great for making raw telemetry coming from sensors meaningful in reports. I hope to hear from you how it helped you to get better insights locally.

Advertenties