In Part 1, we were able to learn a bit about what Microsoft’s Azure IoT Edge does, ran a sample app, and modified it. This time around we’re going to dive deeper into how implementing the gateway process works, and then we’re going to create some fake devices and connect them to the cloud.
I am continuing to follow the IoT Edge docs for exploring Azure IoT Edge and will be getting into the documentation for simulating devices and sending messages to Azure IoT Hub. I’ll be offering my own insights and experiences, so let’s go!
Implementing the Gateway Process
I already showed how you can pass an argument indicating where the configuration JSON file is, but what’s happening under the hood?
Azure IoT Edge itself is written in C. If you want to modify how the underlying technology works, you need to know C, there’s no going around it. However, when you compile that C program the compiler can output either a Windows or Linux-specific executable file. In fact, if you want to run a Node.js version of Azure IoT Edge, it actually just goes out and gets the binaries for the right operating system depending on your environment.
Although C is written to create the executables, once you have an executable, you can call it using any of the supported languages (C, Node.js, Java, or .NET).
Microsoft refers to Node.js as a language in their documentation, but it’s technically a JavaScript runtime. JavaScript is the language, Node.js is one of the runtimes on which that language can run. I’ve wavered on whether to say JavasCript or Node.js when listing the supported languages. I’ll stick with Node.js so you know you aren’t running anything in the browser. I digress.
After you compile that C program into whatever executable your operating system will understand, you need to tell your operating system to start it up. You also need to tell that IoT Edge executable what modules you want to load, where they are, and how they relate to each other.
Microsoft calls these steps implementing the gateway process.
You can write modules in any supported language and even mix-and-match between languages for modules. You can implement the gateway process in several different ways depending on what language you want to use.
For example, if you were using C to implement the gateway process it might look like this inside of the main.c file:
Using Node.js (and simplifying things a bit), you might include something like this in your app.js file:
Using either .NET or .NET Core, you don’t really have to worry about creating an entry point to do, as it’s included in the default IoT Edge gateway executable and you pass the configuration file to it as an argument in the command line, no matter if you are using Windows or Linux.
I say default because the code is open source; you could change it if you wanted to! For example, if you wanted to handle some additional arguments for a specific Applications, you could do that.
In a .NET or .NET Core project, while you are developing a module using Visual Studio, you can edit the project properties to execute the compiled gateway executable (gw.exe) and tell it to take the configuration file as an argument whenever you are debugging.
When you want to run the process for real (i.e. on an actual device you plan to use as a gateway) you can start the gw.exe process and pass in the configuration file as an argument through the command line.
Although there are a few different ways to initialize the gateway process, the end result is the same. You’ve started up Azure IoT Edge and created a configuration file to tell it what modules to use and how the data will flow among them. What now?
Connecting to the Cloud
What’s the Internet of Things without the Internet? Let’s use a module to connect to the cloud. To be clear, you could create a module to connect to anything anywhere, whether that’s AWS or Azure or your on-premises server. If you can build it in Java, Node.js, C#, or C, you can send data wherever you want.
Naturally, Microsoft provides samples to connect to their Azure IoT Hub, and that’s what we’ll be doing here as well. You can follow the instructions to create your own Azure subscription and IoT Hub with two fake devices.
A full tutorial is laid out on Microsoft’s documentation site, so I won’t be covering everything here. My role is to just give you an overview of the process so you feel more comfortable when you take it on!
So, to recap what we’re doing, we need to create two fake devices, which are just some IoT Edge modules creating fake data, and push that data to the broker in IoT Edge.
Think of the broker as a mailman. It’s taking messages and distributing them. It will take any message from anyone and distribute it to anyone else in IoT Edge. Except, instead of mail it’s messages that literally are just pointers to a block of memory, and instead of people, the broker is delivering these messages to modules.
Once the broker gets the message from the faked device, it delivers it to the mapping module. The mapping module takes that message and device information and maps it to a message format with device information that the cloud will understand. In the example given by Microsoft, you might have a MAC address on your little low-power device that connects to IoT Edge using bluetooth. Well, a MAC address doesn’t mean anything to IoT Hub, all IoT Hub uses are the device ids to differentiate between devices. Or x509 certificates, but that’s a different story for another time.
You can imagine it would be difficult trying to manage many devices with different unique identifiers, some with MAC addresses, some with serial numbers, some with who knows what. IoT Hub simplifies that by offering a unified device id format for all your connected things, and Azure IoT Edge helps the cause by allowing you to map all of those unique identifiers to those device ids.
The concept of mapping is exactly the initial purpose of the IoT Gateway SDK in the first place, the idea was that you have all these old or weak devices out there that can’t easily connect directly to the cloud, so you send their information through this hub that will map their disparate unique identifiers to the unique ID provided by the cloud. The other main advantage is that you can map outdated transfer protocols or message formats to the cloud in a modern and unified way.
Of course, since Microsoft has put a bit more capability into the IoT Gateway SDK and renamed it IoT Edge, there’s a hint there that they are adding a lot more capability than simply being a dumb gateway. Dumb gateways just map messages from the edge to the cloud and vice versa; IoT Edge allows for your modules to have a bit more intelligence, but more on that later.
Following the tutorial from Microsoft, you can edit the configuration file with the information for your specific IoT Hub that you create.
You can include the device ids and unique keys provided when you add devices to IoT Hub, and map them in your configuration file to the MAC address from your simulated devices.
Then, when you implement the IoT Edge process, you take in that configuration file and IoT edge now knows it needs to include the simulated device module, the mapper module, and the IoT Hub module, and it allows for messages to be passed down the chain until they end up in the cloud! Tah dah!
To Be Continued…
I meant to show you how to put this on hardware other than your local machine this week, but I’ve enjoyed diving a little deeper in the parts I’ve covered. Tune in to Part 3 to see how you can get IoT Edge up and running on a device!
New Episode
Latest IoT News
