The Microsoft Azure* IoT Gateway SDK gives you a myriad of tools that allow you to enable gateway devices in multiple ways. It can also enable almost any device with an internet connection to become a gateway. It works for both Windows* and Linux* development environments that have the ability to compile C and C++ code. It’s also extremely modular, having a lightweight core to drive the modules you can include within it. This core handles how the modules communicate with each other, apathetic of the environment it’s in. This broker is the key to having effective modules, and an overall effective gateway. It also simplifies communicating with the Microsoft Azure* cloud service.
The SDK includes several modules by default, which can help you understand their structure, application, and communication. They can also provide a good testbed for a gateway, or your custom modules. To begin we will take a look at some of the modules created by Microsoft, and how they play in to the SDK as a whole. Each module is “wrapped” differently depending on whether it’s being used in a Windows or Linux development environment, but is otherwise the same.
The hello_world module is designed to output a simple “hello world” message to the systems log. The majority of the code is error checking, to ensure the environment is properly setup by the core features of the SDK before executing. This module is a publisher, this means its goal is to publish messages to the broker, which can then send the message to whoever needs it. In this case it simply sends “helloWorld", “from Azure IoT Gateway SDK simple sample!” to the broker, but other modules could send sensor information, or instructions.
The Logger module is another simple module, which listens to the broker for any messages, before saving them to a JSON file. The logger does not output any data to the broker, but instead retains all data that has been through the broker. It appends several things to them, like the time of the event the content and the origin of the message, before appending it to the specified JSON log file. This simple module is good to use for error checking, as it can show you in real time, the series of events that lead to an unexpected output.
Building Your “Gateway”
The SDK has a built in function to build your gateway. Of course it doesn’t assemble the hardware through magic blue smoke. Instead it builds the object that acts as a configuration for the SDK to properly interact with modules and hardware. This function takes input in the form of a JSON file, which needs to instruct the program which modules to include, and how the broker needs to act towards them.
The module portion of the JSON file must include three things. Firstly, the modules name, which must be unique in your SDK. The next field that must be filled out is the path of the module. This path must end in .so or .dll, depending on the operating system your using for your gateway. Finally you must enter the arguments your module is expecting. Modules like the logger expects an argument for the file it’s meant to output to. The hello_world module expects no arguments, and therefore you pass it “null”.
This section of the JSON is used to instruct the broker on how to handle messages that are sent to it. Source modules are designated to send messages to the broker. Modules designated as sinks accept messages from the broker. In the case of the “Hello World” sample, the hello_world module is designated a source, and the logger module a sink. Below is an example of a JSON to build the gateway environment on a Linux host machine, taken from the Azure IoT Gateway SDK github.
A developer wishing to design their own module must look through the current modules provided by Microsoft. This article should have given you a good idea of the relationship between modules and the core of the SDK. Upon building your own modules, you need to take into consideration how they are going to react, and be applied in the world of the SDK, and the broker. The true power of a module lies in how it communicates to other modules to do what they need to. So go out there and design your own modules, test them out, and make your gateways act the exact way you want them to!
For more such intel IoT resources and tools from Intel, please visit the Intel® Developer Zone
Other Popular Deals
- The 10 best job hunting apps on AndroidTop 10 Android launchers (June 2017)
- The 10 scariest horror games on AndroidAndroid app stores: 5 best alternatives to Google Play Store
- Best Android apps for rooted devices18 apps for a memorable Valentine's Day
- Top 15 Android games that you should playThe 20 best looking games for mobile phones
- 8 Android apps to tickle your funny bone17 must have apps for any Android device (plus alternatives)
- 5 apps to get the Android Lollipop look on your smartphoneTake control of your Android device with these apps
- 7 weird and strange apps for your Smartphone10 neat Google apps you may not know of
- 10 essential Indian apps for Android devicesPerfect Viewer