In the last couple of months, I have fallen in love with Blazor. I can almost shout out: “imma firin mahBlazor!”
Blazor is a web framework based on Asp.Net core:
Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS
In the past, I have already shown how to deploy a Blazor app as a container using the Azure IoT Edge deployment mechanism. This makes it possible to deploy and run a Blazor app on the Edge. There is no interaction with the Azure IoT Edge routing mechanism, though.
Wouldn’t it be nice if a Blazor app could actually receive IoT Edge messages or even could send IoT Edge messages to the cloud using that same routing mechanism?
The C# .Net Core framwork is pretty versatile. Next to all the operating system features and Windows features, it also supports GPIO for a variety of devices: Raspberry PI, Hummingboard, Windows 10 (core), etc.
I was interested in to access the GPIO in an Azure IoT Edge solution.
I am aware of the elevated rights needed. It’s the same with serial ports access I encountered in the past.
So I did a test, quite simular to the seup of this GPIO introduction:
Let’s check out how we can get this runnning in an IoT Edge module.
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.
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 makes it possible to move a complete IoTHub (with eg. all of its devices and routes) to the ‘sister region’. For example, an IoTHub living in West US 2 will move to West Central US. And you can move it back too.
The manual failover is a good starting point for having a more resilient IoTHub. It’s not perfect, there is a chance that unread messages or data is lost. Failover is hard:
But it’s a perfect way to test the ‘automatic’ failover which Microsoft provides when something happens with the region your IoTHub is living in.
I wanted to test this failover. And I wanted to build a client-side solution so I would not lose any messages.
In my previous blog, I showed you how to host NodeJS in a Docker Image.
Today we will learn how we show telemetry in NodeJS. The message will arrive as a string on an HTML page using SocketIO and we will put it on a chart from HighCharts.
This is a great example of how we can represent raw data in something useful, something end user will understand.
We will extend our previous example. In that example, we were leaning on NodeJS and we have the Express web framework running to show an HTML page. We added SocketIO so users of the index.html can exchange messages.
The current Azure IoT Edge public preview uses Docker to deploy logic from the cloud into local gateways. It’s currently featuring:
C# modules written in .Net standard
Azure Function built on your machine
Azure Stream Analytics jobs built and deployed in the cloud
Azure Machine Learning
We can expect Microsoft will support other types of modules soon as they have proven with other recent projects. An Azure Cognitive Services module is a good example, it’s put in every IoT Edge presentation.
The IoT Edge portal makes it possible to deploy modules which are available in private or public image repositories.
Could it be possible to build and deploy images to the gateway which are not specifically designed for IoT Edge?
It turns out, it is possible.
Let’s deploy a NodeJS server which serves SocketIO.
This blog is all about adding Basic Authentication to Asp.Net Core.
Warning: Although implementing Basic Authentication seems easy, it brings a vulnerability to your site! names and passwords provided are sent over the internet unencrypted. This means: the authentication method does not hide the name and password for hackers. You have to encrypt the communication yourself! Therefore, always combine Basic Authentication with SSL, also known as HTTPS.