Sencha Ext JS 7.7 is Here – Discover What’s New and Exciting – LEARN MORE

A Reference Architecture for an Ext JS based IoT Dashboard

June 9, 2016 3 Views

Guest Blog Post

Overview

IoT is becoming pervasive and is driving an exponential growth in the number of connected devices that are generating data, which must be monitored and analyzed. Dashboards are becoming increasingly critical in helping organizations analyze the complex data and make more informed decisions. To be effective, a dashboard must allow anyone to add IoT devices with easy-to-configure steps and choose the type of visual presentation that the user feels is most appropriate for each device.

Some of the challenges that an IoT dashboard must deal with are:

  • Different types of devices (fan, light, motor, etc.)
  • Different types of protocols the devices support (MQTT, PubNub, dweet.io, etc.)
  • Different types of visual presentations (sparkline, bar chart, on/off switch, etc.)

Besides the challenges above, the dashboard must also allow the user to configure/re-configure a device after it has been added, reposition the device widgets on the dashboard for logical grouping and sequencing, and offer other usability features.

While everyone needs a dashboard, it might be tricky to build one, which meets the above challenges.

In this article, we’ll describe a reference architecture that you can follow to build a generic IoT Dashboard using Ext JS. We’ll also describe the specific Ext JS features that make it easier to build a dashboard, while still taking care of the above stated challenges. This solution has a high level of abstraction that will help you in scaling your dashboard offerings.

At the end, we will talk about Arbela, which is a rich, extensible, customizable, and configurable dashboard that we created based on the reference architecture.

If you are already familiar with the development challenges that IoT presents, you can skip to the Reference Architecture.

Challenges

IoT has the following challenges that a dashboard developer must solve when building an app:

Support for Different Devices

Supporting different devices means two things – communicating with the device in the language (protocol) that it can speak and understanding the vocabulary (data) that it offers. There are different protocols that different players are coming up with. The most popular one is from IBM – MQTT. The next big one is coming out from Google – Weave. There are other major ones – HTTP, WebSockets, PubNub, HAPI (Dweet.io), CoAP, and XMPP. The goal for these protocols is to offer secure communication on constrained devices (small footprint, lower CPU cycles, and lower power) connected to low-bandwidth and high-latency networks. In terms of data format, there seems to be a common acceptance of the JSON format. However, we have yet to see a standardization happening for the data format where an IoT device, e.g. Sump Motor, is represented with the same number of data fields and structures across different protocols. The good news is that the protocols do not put a constraint on the data representation, so we can standardize the representation within our solution even though similar devices speak different languages. For example, we can define a single format for two Sump Motors where one speaks MQTT and the other speaks PubNub.

Support for Different Visual Presentations

Your dashboard will have different users; when it comes to visual presentations, people have preferences on the best way to locate the right information on the dashboard. For a bulb, some would prefer to see ON/OFF text to represent the state of the button. However, some would like to see the color of the widget changing to gray to indicate the OFF state and bright yellow/white to indicate the ON state. There could be more choices that the dashboard may have to support to be usable by a wider audience.

Support for Multiple Visual Presentations

A user may want to see the same data presented differently to extract different information. For example, a user may want to see the current speed of the motor and at the same time link that with a line chart, so the user can see how the speed changed over a time period. Additionally, you may want to have another widget presenting the Pump Capacity parameter value. This helps the user to do focused, fine-grained monitoring and also manages the user’s dashboard area effectively. For example, the user can have one workspace for monitoring critical device parameters and another workspace for trends (data over a period), which can be used to make better decisions if something is wrong with one of the critical parameters.

Support for Asynchronous Data Update

Data from devices gets delivered asynchronously, and the dashboard must react to it instantaneously. As soon as the data arrives, the dashboard should recalculate all the expressions where the new data needs to be used. The new values are prepared and the same data is updated on different widgets, so the user sees the new values in all the applicable places. For example, we have three widgets: one to show the current temperature in Celsius, another to show the current temperature in Fahrenheit, and a third one to show how the temperature has been changing over a period. Now, when the new city temperature data arrives from the sensor, all three widgets need to be refreshed to show the new values based on the new data.

Reference Architecture

The following diagram depicts a reference architecture that can be used to build an IoT dashboard, which takes care of the challenges discussed earlier.

Walking Tree Reference Architecture - IoT Dashboard

The boxes enclosed in the gray box are part of the IoT dashboard architecture. The dotted lines indicate the flow of events.

  • Blade – Blade represents a unique visual presentation. For example, a widget to present the current pump capacity for a sump motor. A Blade has its own view template (HTML fragment) to present the data on the screen. Fields inside the template can be associated with one or more fields of a datasource for presentation. Every blade has its own ViewModel (VM) that helps keep the data clearly segregated for every instance.
  • Card – A card is a collection of one or more blades. This can be used by the user to create a group of related blades as a single card that can be positioned anywhere on the screen. For example, a card containing two blades can include one to show the current pump capacity and a second one to show how the pump capacity has changed over a time period. The Card has its ViewController (VC) that takes care of watching for the new data to arrive on the data sources that are used by its blades. The card then notifies the respective blade(s) about the new data, so the view is refreshed to show the new data.
  • DS Instance – This represents an instance of a DataSource, which is the way to communicate with a device. Based on the protocol that the device understands, a corresponding DataSource Instance is created and associated with one or more blades on different cards. For example, to communicate with an MQTT device, we will create an instance of the MQTT DataSource. A DataSource Instance holds the current data either read from the device or sent from the device. It also takes care of data polling if the device protocol needs explicit data read at a certain interval, such as an Ajax DataSource.
  • DataSource API – DataSource API is an abstraction interface for any DataSource implementation. Any implementation, such as MQTT, PubNub, etc., must implement this interface. It contains the implementation of behavior that is common across all types of data sources such as applying changes to the settings, starting a data polling timer, and explicit data refresh and asynchronous notifications (as events) as soon as data arrives from a device.
  • Protocols – This contains the implementation of different protocol clients. Because every protocol has its unique way of connecting and communicating with a device, each of these implementations is specific to the target protocol. For example, an MQTT protocol connects with an MQTT Broker (such as IBM IoTF, Mosquitto, or HiveMQ Broker) to communicate with the MQTT devices, whereas PubNub offers its cloud service. Because these implementations are stateless, they are instantiated as singletons, and they offer methods that are called from their corresponding DataSource implementation, which provides a common API interface to the rest of the application.
  • Devices – These are the devices that we connect and communicate with. For IoT, there are various micro-controller/processor based devices have been developed and more are being developed that offer the required resources to connect with the I/O devices such as Sump Motor, Bulb, Sensor, etc. These devices include Arduino, Raspberry Pi, BeagleBone, Brillo, and more. They offer required resources (memory, CPU, software, etc.) to set them up as an MQTT compatible or PubNub compatible device where they start responding to client (e.g. dashboard/broker) commands.

Now, let’s look at a sample implementation of this architecture – Arbela.

Arbela – an IoT-ready Dashboard

Arbela is a general purpose, IoT-ready, rich, extensible, customizable, and configurable dashboard. It implements the above proposed architecture using Sencha Ext JS. For example, if you have a PubNub device – Bulb – that you want to monitor using Arbela, you can do it in two simple steps:
1. Create a Datasource, for example a Bulb, choose the type as PubNub, and enter the PubNub specific settings, as shown below:

Create a Datasource - Bulb

2. Create a new Card with a Blade (because blade is all about presentation). We select the right presentation, for example a two-state that shows on/off state of a device along with the time since that state has been effective. Two-state presentation requires us to configure how the state and since information is retrieved from the datasource, as shown below:

Create a New Card with a Blade

The above configuration assumes that the device sends the data in the following format to the PubNub channel:
{"state":"ON", "since": "12:15 pm"}

That’s all! Once you click on the Save button, the Card below will appear on the dashboard:

New Card on Dashboard

Similarly, you can create an MQTT-based Datasource to receive city temperature data, as configured below:

Create a Datasource - Temperature

We are using HiveMQ hosted broker. After the Datasource is configured, I can create a Card and use Sparkline – Line type presentation, which will show a line chart with the current temperature as well as how the temperature changed over a time period.

Create a Card - Temperature

Unit indicates the value is in °C. The expression can be changed to:
datasources[‘Temperature’].temp*9/5+32
to convert the value into °F.

We can add more Cards with one or more Blades, and our dashboard will start to look something like this:

Dashboard with Cards and Blades

Notice that we have a Card – City Humidity & Temperature – that has two Blades. We are using the same City Temperature data source on two different Blades, and they are syncing properly.

How We Used Ext JS

  • Dashboard classes – Ext JS has built-in support to create a dashboard with components that are draggable, closable, and resizable. We use these components to create a dashboard with cards. Our card is an extension of Ext.dashboard.Part class.
  • Components, Containers, and Layouts – We rely heavily on Ext JS Components, Containers, and Layouts to create the overall dashboard structure. To create configurable and extensible Add Datasource and Add Card panels based on user input, we used containers and component events, and we dynamically managed (added/removed) their children.
  • Automatic registration of data sources – On the Add Datasource panel, we have a Type dropdown, which automatically lists all the data sources that we have in the application. We achieved this using the Ext.ClassManager to find all the datasource-related classes and use their static properties to fetch the nice name, e.g. PubSub (MQTT) for display.
  • Dynamically creating the Settings panel for Datasource and Blade – Based on the Type selection, we identify the class that the user has selected and then we use the Ext.create API to dynamically instantiate the Settings area with the corresponding class settings.
  • Reacting instantaneously to data arrival – Because most of the IoT protocols are asynchronous in nature, we needed some way to build on top of that, so the application waits for the data to arrive on a data source and then notifies the blades about it. Every Datasource fires a custom event – dataupdated – as soon as the new data arrives from a device. The ViewController (VC) on a Card parses all the datasources that are being used by its Blades and registers the handler for this event, which is called when the event is fired. Also, the VC runs the handler within a blade scope for better encapsulation. To notify the Blade view about the new data, the Blade view provides a ViewModel (VM) and uses data binding to bind the data with the view. The VC sets the VM data, and the rest is taken care of by the Ext JS Data Binding mechanism. The view is refreshed with new data in no time.
  • Modular design – Arbela uses an MVVM architecture to structure the complete application in the form of View-ViewModel-ViewController. It uses the instance-specific ViewModel for Blades to ensure better runtime encapsulation of the data. Data binding with view ensures automatic refresh of the view as soon as a change in data is detected. The Class system offered by Ext JS was very handy in defining the DataSource API and segregating and encapsulating the common and specific functionalities easily.

Summary

We talked about what kind of needs exist for a typical IoT Dashboard – different devices, different protocols, different visuals, etc. – and the unique challenges. We looked at a Sencha Ext JS based reference architecture for building an IoT dashboard and presented a sample implementation of that architecture in the form of Arbela. We briefly talked about Arbela features and how we leveraged different Ext JS features to keep the design clean and functional. We hope this article has given you an idea of what IoT dashboards offer, and how they can be implemented using Sencha Ext JS.

Leave a Reply

Your email address will not be published. Required fields are marked *

Ready to get started?

Create an account now!

Latest Content
Highlights of Virtual JS Days 2024

Highlights of Virtual JS Days 2024 From February 20-22, 2024, we held the third Virtual…

From the GM’s Desk 2023: An Exciting Year for Sencha & Ext JS 7.7

We are past the midpoint of 2023 and we are very proud of what we…

Sencha MVP Spotlight: Animap - The Historical Research Tool with Andy Allord

Welcome to our Developer Spotlight Series, where we showcase the remarkable talents and achievements of…

See More

Leave a Reply

Your email address will not be published. Required fields are marked *

coming soon

Something Awesome Is

COMING SOON!