Visualizing the Internet of Things: The Design

My first project as an Intern at WSO2 IoT Server

Whatever said and done, at the end of the day one thing is for sure;

an IoT network is complicated.

With so many devices connecting and talking to each other, there comes a point when it can all be quite overwhelming. Especially when it’s not a single device layer network.

What this means is all Edge Devices aren’t directly connected to the server, but rather the network is a combination of direct connections of Edge Devices and connections through IoT Gateways.

Single Device layer vs Multi Device layers

And even that is after taking into account if the Server in question is capable of supporting multi device layers.

As the above diagram might show, sometime all you need is a visual aid to better understand a complicated system.

This article explains a project in which I got an opportunity to have a hands-on experience in giving an IoT network a visual meaning.

On July of this year (2017) I started my 12 month internship at that provides an abstract interface to some type of database or other persistence mechanism”. If you found that a bit confusing it basically means that the DAO is where all the database tables of each and every function/feature of the WSO2 IoT Server resides.

Now for the initial portion of my project I needed a very simple single table structure to maintain my metadata.

Structure of my DB metadata table
  1. device_id: The unique identifier of the device. Also the primary key of the table.
  2. device_name: Whatever user specified name of the device.
  3. parent_id: The unique identifier of the parent the device is connected to.
  4. mins_since_last_ping: No. of minutes that have transpired since last communication with device.
  5. state: The state the device is in currently. This could either be ‘connected’, ‘pending’ or ‘disconnected’. The mins_since_last_ping value of that record is used to determine this.
  6. is_gateway: At the time of enrollment the agent of the device establishes that whether the device is a gateway or not. I’ll explain the main reason of having this field later.

I also wrote a DAO implementation class to include the queries that I would be running for various operations needed for my project.

Layer 2: A little further up with OSGi

After all of the DAO Database level design was done, it was time to move to the OSGi services.

Gateway to access the DAO level

OSGi services are sort of like the gatekeepers allowing REST or other services to access the Database. These OSGi services are no different from your typical Java class. All it contains is the processes needed to take a bit of data sent to it and hand it over to the DAO so that a query can be executed and a DB table can be edited.

Layer 3: Closer to the surface with RESTful services

All the stuff I’ve been working on up-to this point was entirely non-user facing. The user facing, or rather developer facing stuff begins with the RESTful APIs.

How REST endpoints get stuff done

REST (REpresentational State Transfer) is an architectural “style” used in the development of web services. It’s kind of like using traditional web URLs with certain verbs accompanying them. Verbs like; GET,POST,PUT and DELETE are used primarily in REST. This makes writing and accessing endpoints or web services fairly painless and straightforward.

REST APIs can be written for basically any operation needed to be done in a database. In my case I’ve got REST services written for purposes ranging from adding/removing a device to performing updates on device data. If the user of the API has the necessary permission then it’s just a simple matter of sending an HTTP request to get the job done

Layer 4: Reaching the top with the UI

At the topmost level is the UI.

The REST APIs written in the level prior actually complements the UI and helps it work. Most of the time whenever you see something in a web page update or change before, that’s an API working behind the scenes. So if UI components were stage actors, REST APIs would be the stage managers and backstage hands making sure the show was running smoothly.

Web app UI built on a foundation of REST API services

Before creating any UI it’s advised to create a mockup.

Rudimentary mock-up for my visualization

The mockup I created had a visualization of a sort of organic structure as the hero of the page. Making the visualization component the hero made sense, as it showed how the network was arranged at a glance.

Such a visualization would make it extremely easy to understand how big the network is and even understand some more in-depth information like which devices are offline. Without visualization it would be extremely difficult to go through tons of database records and get the stuff you want.
A simple UI just makes it, simpler!

With all of that done the design on my project was complete.
Now it was time to get to the nitty gritty of it and start to put code to IDE. So while I’m off for a commercial break please note I’ll be covering the rest in it’s entirety in the upcoming article. 😉

This post is one in a series I’m writing about the Internet of Things. If you need to catch up to the earlier ones, the index is as follows;

Episode 1: Putting the “Internet” back in the Internet of Things
Episode 2.1: Visualizing the Internet of Things: The Design

Powered by WPeMatico

Please follow and like us: