A Unified Web Interface for the Internet of Things

Kapil Kumar, Joy Bose, Samarth Tripathi

Web Solutions
Samsung R&D Institute India- Bangalore
Bangalore, India
{ kapil.kumar, joy.bose, sm.tripathi }@samsung.com

Abstract— The Internet of Things (IoT) includes many

applications, frameworks and protocols that are specific to the
types or categories of devices that are controlled. The web
browser represents a widely used and available interface to
access functionality and is present in most mobile devices. In
this paper we present an integrated interface to control IoT
connected devices through the medium of the web browser. We
describe a lightweight method to integrate an IoT interface with
a web browser with the help of various REST APIs and
wrapper functions. We use features and technologies specific to
the browser, such as bookmarks, authentication and offline
mode to control devices directly through the browser instead of
going through a centralized server. Our solution will enable any
user to easily control any connected smart device via a web
browser. We also describe the architecture of an EEG
controlled IoT interface for the web browser.

Keywords— Web Browser; Web of Things; Internet of Things;

REST API; HTML
I. INTRODUCTION
Internet of Things (IoT) refers to a network of connected
physical devices or objects that can talk to each other and
mutually exchange data. IoT is becoming more widespread
recently due to support from a number of big manufacturers
and standards bodies [1-4]. The vast number of protocols and
standards now presents interoperability issues. One solution
has been to use the web browser as a platform to access the
state of the connected objects or things.
When the connected objects in IoT are also made part of
the World Wide Web, the network is referred to as the Web of
Things (WoT). Control of the connected devices in an IoT
environment is commonly performed via a centralized hub. In
many cases, the hub generates commands to control various
parameters in the device, as well as receive the current sensor
outputs from the connected devices. Current solutions for
WoT are commonly not integrated with the web browser;
rather they use the browser merely as the means to access the
control interface on the server. This presents the problem of
additional latency for control commands for the connected
devices, and does not enable the user to take advantage of the
browser’s in built interface and capabilities such as additional
authentication. Moreover, they cannot work in the offline
mode.
Fig. 1. Illustration of the high level architecture of the Web of Things
(WoT) interface. This comprises remote control of IoT devices via a
web browser running on a mobile device. The commands are
transmitted using a cloud server/WIFI to a centralized hub which
controls the IoT devices.
In this paper, we propose a way to integrate the control
interface for the connected devices in an IoT framework
within the web browser, that also works in the offline mode.
The proposed web browser integration would enable control
of various devices supporting IoT to be done via any browser
independent of the operating system running on the device.
This implementation is lightweight and does not require a
dedicated cloud server for controlling the things. It also
enables us to use common web browser functions such as
bookmarking a device or seeing the device’s history.
The rest of the paper is organized as follows: Section 2
surveys related work in the area of web interfaces for IoT.
Section 3 describes the browser architecture with component
modules. Section 4 describes an integrated Web of Things
(WoT) session in the web browser, including an EEG
interface for the same. Section 5 covers the implementation
details, and section 6 discusses some limitations of our
approach. Finally, section 7 concludes the paper.
II. RELATED WORK
In this section we look at some related work in the area of
web interface for the internet of things. Some of the existing
solutions enable a smart device such as the smartphone as the

978-1-5090-3646-2/16/$31.00 ©2016 IEEE

Authorized licensed use limited to: VIT University. Downloaded on October 24,2020 at 08:28:27 UTC from IEEE Xplore. Restrictions apply.
control hub for IoT using APIs, while others have a custom
physical device used exclusively as the hub.
Fig. 2. Building blocks of the Web of Things (WoT) interface. The
component modules run on top of the web browser built on Chrome in
an Android system.
Apple’s HomeKit [5] enables the user to monitor and
control smart homes and appliances using the smartphone as
the control hub. A dedicated native application running on the
smartphone is needed to access and control the state of the
devices via a cloud server.
SmartThings [6] have a control hub along with an Android
based integrated user interface (UI) application for controlling
various connected appliances. However, any separate native
application to control the IoT connected devices would be
specific to the type of device and operating system. Some
developers have developed an open source web interface
called ThingLayer [7] for controlling devices connected using
SmartThings. However, the ThingLayer solution too is not
integrated with the web browser, and to use it the control
interface needs to be hosted on the ThingLayer server in the
cloud.
Guinard et al [8, 9] coined the term ‘Web of Things’ and
described a web oriented architecture for the IoT by
integrating sensor nodes via RESTful APIs. Framling et al
[10] also proposed interface standards to enable any IoT
device to be connected on an ad-hoc basis. In this paper we
use similar principles; only our approach is more integrated
with the web browser and can work in the offline mode as
well, in case the web server is not accessible.
Google’s Physical Web [11] envisages an URL for each
connected ‘thing’ or device, which hosts a tiny web server.
This URL can be used to access the current state of the device
and modify the state if necessary. Google’s project Brillo
[12], along with a protocol layer called Weave, presents a way
for IoT devices to communicate with each other. Frameworks
such as OpenIoT [20] enable integration of heterogeneous IoT
devices. Our solution can use these and similar technologies
as building blocks while leveraging the additional capabilities
of the web browser.
Thus, some current solutions involving native apps such as
Apple’s HomeKit, can handle offline functionality as long as
the appropriate APIs are available, but no web based solution
is available that provides offline support to manage the IoT
Authorized licensed use limited to: VIT University. Downloaded on October 24,2020 at 08:28:27 UTC from IEEE Xplore. Restrictions apply.
devices directly, since the web browser cannot handle the web
content offline. In this aspect our approach is useful.
In the following section we introduce our proposed
architecture that is integrated with the web browser.
III. PROPOSED ARCHITECTURE OF THE IOT WEB INTERFACE
In our architecture, interaction with the connected devices
in an IoT framework is handled through the Web Browser.
The Web Browser has integrated inline support for handling
the Web of Things URL and providing user interaction.
The Web Browser communicates with the cloud server
through standard REST APIs. The control of individual
devices is performed by passing commands to a centralized
hub via a cloud server, as is currently done in SmartThings.
However, the control interface is part of the web browser and
does not need to be hosted on a separate cloud server. This
makes our solution lightweight, reduces latency and able to be
used in offline mode.
Currently, new devices in the system can only be added
using the SmartThings app. In future we will integrate the
addition and deletion of devices with our web interface.
Once the control command is executed in the connected
IoT device, the status is sent back to the cloud and the
response is received in the client side in JSON format. This
response is then parsed and presented to the user in HTML
view.
The components of the Web of Things (WoT) interface on
the web browser are mentioned in the following subsections.
While we have implemented the modules on the Chrome
browser on Android, the same can be implemented in
principle for any web browser on any mobile platform.
Fig. 2 shows the browser architecture having the
mentioned modules.
A. Content installation module
The Android web view [13] allows loading of the web
content from Android assets using file:// scheme. But current
Chromium [14] based browsers cannot load html content from
assets directly using “file://” scheme, as this is blocked for
security reasons. This module takes care of installing the
required files and allows the browser to access the resources
through the “content://” scheme. The “content://” scheme
addresses the security concerns of the “file://” scheme because
here all the resources are in a private folder of the device and
the rest of the files are protected. In this module, the
resources (HTML/CSS/JS files along with any icons for the
devices and other resources) will be installed during the
installation of the browser APK on the device.
B. URL interpreter module
As the browser does not understand the “wot://” URL
which is a non-standard URL (rather than say http://), so this
module interprets the URL to map from “wot://” to
“content://” scheme along with basic filtering. This shortens
the URL and also makes the web address of the IoT device
more intuitive and easier to remember. Other files in that
directory will be accessed under that URL.
C. User interface module
This module consists of user interface (UI) elements
created by basic HTML/CSS/JS code. This HTML code
incorporates a state machine, which presents the user with the
login screen or options to access their account and device
details. This also handles saving the data to local storage for
caching it and reusing it, to avoid user re-login.
Fig. 3. Flowchart representing the handling of the authentication process
D. REST Interface Module
REST APIs are implemented in the JavaScript (JS)
backend to allow communication (using a suitable existing
protocol such as ZigBee or Z-Wave) between the client and
the cloud server. The main APIs implemented in JS backend
are as follows: Fetch the authentication token using the
username/password, fetch the list of locations for a user, fetch
the list of devices in a location, fetch the current state of a
device type, fetch the commands supported by the device, etc.
E. Device APIs
This component in the web browser application allows
JavaScript binding, which provides a mechanism to call
exposed Java APIs directly from JavaScript. The device API
has been exposed by JSInterface [17], which is an interface
for callback from JavaScript to a Java application. Using this,
any custom interface, such as ours, can be exposed to
JavaScript for callback to Java. Puder et al [25] among others
have studied approaches for using native device APIs in web
based apps.
Authorized licensed use limited to: VIT University. Downloaded on October 24,2020 at 08:28:27 UTC from IEEE Xplore. Restrictions apply.
Fig. 4. Flowchart representing the state handling and fetching the device
state for a particular location of a user
F. Offline Handler
This component allows the browser can get the status of
devices directly from the centralized hub (referred here as
Smart Hub) through a Wi-Fi connection, as long as the
connected devices are using the same Wi-Fi. It does not need
to connect to the cloud server for this purpose, as in the
existing WoT architecture. Whenever the user clicks on any
button or icon in the web content, the JavaScript function in
the “onclick” callback will check if the device is connected to
the internet or not using the Device APIs.
If the device is connected to the local WiFi without any
internet service, then the offline handler will try to search the
Smart Hub in the same WiFi network using APIs provided by
SmartHub [18]. If the Smart Hub is available, all commands
will be redirected to the Smart Hub without the active internet
connection, allowing the user to control connected devices
without any internet. This was not possible in previous WOT
architecture. In this case, the Smart Hub will try to
synchronize the state of all devices when internet becomes
active.
The implementation of the offline mode requires
additional effort to implement the offline support handling on
the smart hub side. One issue with the offline mode is that it
cannot support the devices from an external network or
location.
 IV. INTEGRATED WEB OF THINGS (WOT) SESSION IN THE
WEB BROWSER
In this section we describe the integrated interface for the
web of things, using the web browser architecture described
in the previous section.
A. Integrated WoT access
The user can access details of the connected devices
within the web browser. The user may have multiple Smart
Hubs to control devices at different locations such as home,
office, garage, etc. Using the WoT interface, the user can
fetch all the devices connected to a Smart Hub. The user can
also see all details about a device in a detailed screen,
whenever they tap on any particular device icon.
The user needs to enter their credentials to fetch the
authentication token governed by the OAuth standard. Once
received, the token is saved in local cache. The token can be
used to fetch different locations registered in the user’s
account. Upon a successful request, the response is received
in JSON format and parsed to save all location related
information. Fig. 3 illustrates the authentication process.
To fetch all devices in any particular location, once the
user has entered their credentials, the process is explained
through the flowcharts in fig. 4. The authentication token will
be used to fetch different locations registered in the user’s
account. Upon a successful request, the response will be
received in JSON format and will be parsed to save all
location related information.
Once the location id is received, other requests will be
used to fetch all the applications installed for a particular
location. This uses server side logic, where all the connected
devices are controlled through a Smart Hub based on the
request parameter. The user can fetch all devices and related
information using a location id and an authentication token. A
JSON response will be received on a successful call and
parsed to display all the devices in HTML resources.
The user can also see all the details about a device in a
detailed screen, when they tap on any particular device icon.
(a) (b)
Fig. 5. (a) Illustration of the login screen (b) The main dashboard user
interface after a succesful login.
Authorized licensed use limited to: VIT University. Downloaded on October 24,2020 at 08:28:27 UTC from IEEE Xplore. Restrictions apply.
B. Device state and details
As shown in fig. 5, the user can navigate to a particular
connected device (such as a thermostat) and see all the details
and properties for that device. Also, the user can select and
modify the properties, as per supported commands in the
device.
C. Services and interfaces of the unified web browser
interface for IoT
With the proposed unified web browser interface for IoT,
we can provide a number of additional services and interfaces
such as the following:
x Bookmarking a device: Once this is done, the user
can access the device features, properties and control
interface simply by clicking on the bookmarked
device in the web browser. The quick access icon can
show the updated device status in the browser home
screen for every new tab.
x Device APIs Access: As HTML/JS code is bound to a
particular device, so it can access the Device APIs
through the browser interface. So JavaScript can
directly call exposed APIs of the Android framework.
x History of commands previously given for a device.
This can be accessed just like browser history
x Single authentication for all connected devices
through the web browser. In this way, the user would
have to enter their credentials just once, in order to
access multiple connected devices.
D. Brain controlled unified web interface
An additional enhancement for our proposed web
interface can be in the form of a brain controlled interface
(BCI). With the popularity of commercial brain controlled
interfaces for a variety of functions today, and the advent of
cheap commercial grade dry BCI kits, one can visualize a
future when the connected devices, such as home appliances,
are controlled through the brainwaves generated by the user,
or what can be termed as the “Brain of Things”.
Fig. 6. Architecture of the brain controlled interface for the web browser
 A popular kind of BCI is Electroencephalography (EEG).
A number of wearable EEG sensor kits are available today
developed by manufacturers such as NeuroSky, Emotiv, and
MUSE [21-23]. Liu et al [24] have shown that the attention
value can be extracted from the EEG sensors. The Neurosky
EEG kit uses eSense meters to measure the attention level as a
scale of 1 to 100. Our unified web interface can be further
enhanced by adding EEG based control, where the attention
level of the user is used to navigate through the web menu.
A high level overview of the system is shown in Fig. 6.
The general steps for processing the EEG inputs by the
unified web interface are as follows:
x The EEG Sensor output is captured through a
wearable EEG kit, such as NeuroSky’s MindWave,
and sent to the mobile device, which is paired using
Bluetooth.
x The output is then preprocessed on an application
running on the mobile computing device. Feature
detection is done on the EEG output in the mobile
device to identify the user’s mental state, which can
be used to perform actions as per the preset user
settings. In case of the NeuroSky EEG kit, the
attention and blink level of the user is detected using
given APIs.
x The User Interface component of the unified web
interface for IoT is then updated in response to the
received attention and blink level.
An activity on the Android mobile device listens for inputs
from the EEG sensor. Once the EEG input is detected, it
classifies the input as belonging to one of the pre-determined
categories (attention, blink, relaxation, etc.) and finally
invokes the specific web interface function as required. Using
the attention level, the user navigates to items in the device
home screen and selects a particular item to see the contents.
For visualization for items under navigation a user friendly
interface is provided.
In our implementation, we use deliberate blinks, also
detected by the EEG sensor to open a currently selected item
in the web browser, and the attention level to navigate across
a list of items. While navigating a list in the web browser, if
the attention level stayed over the threshold for 1 second, the
system navigates to the next item in the list. If the level
dropped below the threshold, the system would not navigate
further but stay at the currently selected item. If the user
makes a deliberate double blink, the system opens the selected
link in a new browser tab.
Having an EEG controlled interface for IoT can be utilized
in a number of use cases and productivity enhancement
features. For example, in case the user’s attention level is
above a threshold, the actions can include turning the phone to
silent mode or block calls so as to not to disturb the user.
Other use cases include controlling the AC temperature if the
relaxation level is high, playing a relaxing song when the user
is stressed, and so on.
Authorized licensed use limited to: VIT University. Downloaded on October 24,2020 at 08:28:27 UTC from IEEE Xplore. Restrictions apply.
V. IMPLEMENTATION AND PROTOTYPING
We have implemented the basic working prototype on the
Chromium based browser on the Samsung Galaxy S6 device.
For our implementation, we used SmartThing’s Smart Hub
and developer account for the simulation of a few virtual
devices.
As shown in Fig. 7, the first time the uses accesses the
hub, the login screen is presented to the user for their
credentials. Once the credentials are provided and
authenticated, the system displays the main dashboard with
the status of all connected devices. The user can view details
for any particular device by tapping on it, as shown in fig. 8.
The interface also allows the user to view their profile, along
with an option to choose their location and an option to
logout.
(a) (b)
Fig. 7. (a) Illustration of the detailed screen for a device status (b)
Illustration for a user profile with slide bar navigation panel.
As we have implemented this system on a Chromium
based browser, it is very easy to port this implementation on
any similar browser. As all the data is handled and displayed
with HTML pages, there is a very minimal dependency on the
user interface as long as it is capable of displaying HTML
pages.
mappings {
path("/switches") {
action: [
GET: "listSwitches"
]
}
path("/switches/:id/:command") {
action: [GET: "updateSwitch" ]
}
}
Fig. 8. Illustration of the mapping of the APIs with the switch device type
To test the device status update for the virtual devices, we
have written a small wrapper on the server side. We have used
Groovy language [19] as required from SmartThing’s IDE
and implemented a groovy application to handle requests for a
different device type. Using the application id for this
interface, the browser can fetch or update the state of the any triangulation and measuring the Bluetooth signal strength to
particular device. This interface will have mapping of the API calculate the approximate distance of connected devices from
with the corresponding device type, as shown in fig. 8. On the the mobile device. This can further be used to implement a
client side, the web browser can consume this API with help drag and drop interface for moveable devices.
of utility functions, as shown in fig. 9.
function updatedevice(appid,access_token,type,id,command,value) { REFERENCES
var url = [1] Internet of Things: IEEE Standards Association [Online]. Available:
"https://graph.api.smartthings.com/api/smartapps/installations/" + standards.ieee.org/innovate/iot/stds.html
appid + "/" + "update" + type; [2] Saroj Kar. Intel, Samsung & Cisco Launches IoTivity Open Source
Standard for the Internet of Things. CloudTimes, Jan 21, 2015.
var request = { type: type, id: id, command: command, value: value}; [Online]. Available: cloudtimes.org/2015/01/21/intel-samsung-cisco-
if (access_token) request["access_token"] = access_token; launches-iotivity-open-source-standard-for-the-internet-of-things
[3] Internet of Things Council. [Online]. Available: theinternetofthings.eu
$.get(url, request).done(function( data ) {
[4] WebIOPI Internet of Things Framework. [Online]. Available:
if (data.status == "ok") { code.google.com/p/webiopi/
console.log("request success:"); [5] HomeKit: Apple Developer [Online]. Available:
developer.apple.com/homekit/
} [6] S. Mayer, A. Tschofen, A. K. Dey, F. Mattern. User interfaces for
}).fail(function() { smart things: A generative approach with semantic interaction
descriptions. In ACM Transactions on Computer-Human Interaction
alert( "updatedevice Failed:"); (TOCHI) Volume 21 Issue 2, February 2014
}); [7] Jodyalbritton. ThingLayer: An open source real-time web interface for
IoT. Mar 6, 2015. [Online]. Available:
} community.smartthings.com/t/thinglayer-an-open-source-real-time-
web-interface-for-iot/12295
Fig. 9. Illustration of the client side function to conssume the API to update [8] D. Guinard. Towards the web of things: Web mashups for embedded
the device status devices. WWW (International World Wide Web Conferences),
Enterprise Mashups and Lightweight Composition on the Web (MEM
2009) Workshop, 2009.
VI. LIMITATIONS OF THE SOLUTION [9] D. Guinard, V. M. Trifa, E. Wilde. Architecting a mashable open world
wide web of things. ETH, Department of Computer Science, 2010
Since there is currently no standardized format defined for
the data and communication between the cloud providers and [10] Kary Framling, Sylvain Kubler, Andrea Buda. Universal Messaging
Standards for the IoT from a Lifecycle Management Perspective. IEEE
the client device, so our solution is specific to the Internet of Things, Vol. 1, Issue 4, 2014. pp. 319-327
implementation platform and cannot be generalized per se. [11] Google Cloud Platform [Online]. Available:
However, it is easy to port our web browser based solution to cloud.google.com/solutions/iot/
multiple ecosystems with relatively less code rework. Also, [12] The Physical Web [Online]. Available: google.github.io/physical-web/
some device APIs for controlling IoT devices through the [13] Project Brillo [Online]. Available: developers.google.com/brillo
browser might not be currently available. Moreover, [14] Android Webview interface [Online]. Available:
controlling IoT devices through the web browser may cause developer.android.com/reference/android/webkit/WebView.html
some performance degradation when compared to native [15] Chromium Browser. [Online]. Available: chromium.org
apps. [16] OAuth [Online]. Available: oauth.net/
[17] Android Developers. Javascript Interface. [Online]. Available:
VII. CONCLUSION AND FUTURE WORK developer.android.com/reference/android/webkit/JavascriptInterface.ht
ml
In this paper we have presented the design of a web [18] SmarThing SDK Documentation [Online]. Available:
browser to control connected devices in an Internet of Things http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-
(IoT) environment. Integrating the control of devices within types-developers-guide/index.html
the browser, rather than having a separate web application for [19] The Groovy programming language [Online]. Available: groovy-
the same, provides a number of benefits for the user and lang.org
allows them to go beyond certain limitations. For example, [20] Github. OpenIoT project.[Online]. Available:
the user can use the single sign in process from saved github.com/OpenIotOrg/openiot
credentials in the browser or can use offline feature etc. [21] NeuroSky store: Mindwave. store.neurosky.com/products/mindwave-1
[22] Emotiv EPOC headset. emotiv.com/epoc.php
In future, we aim to create a framework to provide easy [23] MUSE: The Brain Sensing Headband. choosemuse.com
setup with the help of generic interfaces. We will explore [24] Liu, N.-H., Chiang, C.-Y., Chu, H.-C. Recognizing the Degree of
using data locally available in the mobile device such as Human Attention Using EEG Signals from Mobile Sensors. Sensors
sensor data, contacts data using native device APIs and use (Basel, Switzerland), 13(8), 10273–10286.
extracted information from this data such as information [25] Arno Puder, Nikolai Tillmann, and Michał Moskal. Exposing native
about the user’s schedule, to control the connected devices. device APIs to web apps. In Proceedings of the 1st International
Conference on Mobile Software Engineering and Systems
We also plan to use a location engine that allows the user to (MOBILESoft 2014). ACM, New York, NY, USA, 18-26. 2014.
see the approximate location of connected devices, via

Authorized licensed use limited to: VIT University. Downloaded on October 24,2020 at 08:28:27 UTC from IEEE Xplore. Restrictions apply.