Web Based Iot - Mini Project

Masaryk University
Faculty of Informatics
The web-based platforms for

IoT (Internet of Things)
management
Bachelor’s Thesis
Branislav Smik
Brno, Spring 2016

Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. All sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
Branislav Smik
Advisor: RNDr. Petr Švenda, Ph.D.
i
Acknowledgement
I would like to thank my advisor RNDr. Petr Švenda, Ph.D. for his
time and guidance.
My special thanks goes to my family for their continuous support
and care.
ii
Abstract
An increased popularity of the IoT calls for efficient ways of managing
the connected devices and processing the generated data. The aim
of this bachelor thesis is to provide an overview of a web-based plat-
forms for management and visualization of data provided by the IoT.
Various characteristics and capabilities of the platforms are described,
including security features and methods for data visualization. Se-
lected representative platforms, namely Xively, ThingSpeak, and AWS
IoT, are thoroughly described and put to the test on prepared scenarios.
The ThingSpeak platform is then used to demonstrate its capabilities
on data collected from a physical wireless sensor network.
iii
Keywords
Internet of Things, management platform, Xively, ThingSpeak, Ama-
zon Web Services, data visualization, MQTT
iv
Contents
1 Introduction 1
2 Platforms on the market and their features 2

2.1 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Development support . . . . . . . . . . . . . . . . . . . . . 4
2.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.7 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7.1 Data visualization . . . . . . . . . . . . . . . . . 6
2.7.2 Actions . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7.3 Data analysis . . . . . . . . . . . . . . . . . . . . 7
2.7.4 Data storage . . . . . . . . . . . . . . . . . . . . . 7
2.8 Overview table . . . . . . . . . . . . . . . . . . . . . . . . 8
3 A review of the selected platforms 9

3.1 Xively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Naming conventions . . . . . . . . . . . . . . . . 9
3.1.2 About . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Features . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Security . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 ThingSpeak . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 About . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Features . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4 Security . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 AWS IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 About . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 Features . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.4 Security . . . . . . . . . . . . . . . . . . . . . . . 21
4 The tested scenarios 23
5 Results of tested scenarios 25
v
5.1 Xively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . 25
5.1.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . 27
5.1.3 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . 28
5.1.4 Scenario 4 . . . . . . . . . . . . . . . . . . . . . . 28
5.2 ThingSpeak . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . 29
5.2.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . 29
5.2.3 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . 30
5.2.4 Scenario 4 . . . . . . . . . . . . . . . . . . . . . . 31
5.3 AWS IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.4 Scenario 4 . . . . . . . . . . . . . . . . . . . . . . 35
6 ThingSpeak and a testbed experiment 36

6.1 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . 36
7 Conclusion 38
Bibliography 39
Index 43
A MQTT protocol 43
B List of attachments 44
vi
List of Tables
2.1 A representative sample of web-based IoT platforms. 8
5.1 Results of tested scenarios. 25
vii
List of Figures
5.1 Raw datapoints from a single Xively channel. 26
5.2 A graph from the Xively’s GitHub web application. 27
5.3 A plot generated with the MATLAB Visualizations
app. 30
5.4 Visualization of data with the Kibana application. 34
6.1 Detected unique nodes in last 60 messages. 37
viii
1 Introduction
The rapid spread of the IoT and the increasing number of devices and
components of associated Wireless sensor networks (WSN) raises a
question how to efficiently process large amounts of data generated by
these networks. In recent years, multiple platforms for management
and visualization of data provided by the IoT have been created. These
platforms help to manage, process, visualize, and act upon changes in
the data.
The platforms differ in the way they store data, in the source of
computational power, protocols they use, supported hardware, offered
features, licensing, pricing, and many other aspects. The number of
platforms a user could use for his project can be quite big, therefore a
comparison and overview of the platforms on the market is expected
to be a helpful source of information.
The aim of this thesis is to provide an overview of the web-based
platforms for management and visualization of data provided by the
IoT. We focused solely on the platforms that are fully deployed in
a cloud and tested only free services, or services offered under an
academic license.
In the second chapter, the main characteristics of IoT management
platforms, such as their type of deployment, scalability, incorporated
libraries, security features, or used protocols, are described. Possible
capabilities to visualize, analyze, act upon, and store data are here
described as well. The third chapter is devoted to a detailed review
of the three selected platforms: Xively [1], ThingSpeak [2], and AWS
IoT [3]. A list of prepared scenarios for testing the selected platforms
is given in the chapter 4 and results of these scenarios are described
in the following chapter. Finally, a demonstration of capabilities of
the ThingSpeak platform on data from a real WSN is shown in the
chapter 6.
1
2 Platforms on the market and their features
Today, there are more platforms for management of Internet of Things
(IoT) resources on the market than ever before. Applications of such
platforms can go from various do it yourself projects, product proto-
types, to big scalable systems. Each project has different requirements,
might have different understanding of things, and therefor takes differ-
ent approach in implementing the IoT. Accordingly, platforms differ
in many aspects as they try to satisfy various needs of customers.
Before discussing various attributes of IoT platforms as a way of
comparing them and deciding which one to use for our project, it is
good to mention why to choose a pre-built platform in contrast to
developing one ourselves, in a first place. Availability of numerous
IoT platforms enabled many people to create and manage their own
IoT projects, without possessing any IoT management tools. However,
there are still (especially large) companies, that develop and operate
their own proprietary platforms to support their connected products.
Despite advantages of possessing and being in full control of a self-
hosted platform, many problems arise with this, in most cases, more
complicated solution. First of all, security issues with managing users,
provisioning products, or securing data might emerge. Some platforms
might not be prepared for increased demand for their services and
thus jeopardize the company or its product. Lastly, companies must
take into account the importance not only of the platform itself, but
also of the infrastructure and interconnected services, and be able to
provide a real-time support.
2.1 Deployment
The whole platform can be powered by cloud computing or deployed
locally on a computer or server of a user’s choice. Cloud powered
platforms are usually provisioned in form of a Platform as a Service
(PaaS) or Software as a Service (SaaS). PaaS platforms provide infras-
tructure and cloud computing services for IoT devices. These services
can include storage of data, communication and security protocols,
support, etc. This means that a user has environment for building
his applications and doesn’t have to take care of configuration and
2
2. Platforms on the market and their features
maintenance of the infrastructure. SaaS platforms are typically cen-

trally hosted applications that rather focusing on providing tools for
building applications, focus on the end user and provide finished
product that’s ready to use, despite of the cost of little or no configu-
ration options. In the case of the whole platform being deployed in a
cloud, the user takes care neither of data storage nor computational
resources. The advantages of locally deployed platforms (such as Kaa
[4]), that might in some cases appear also as disadvantages, are the
capability of personalizing settings, choosing a data storage system
that suits the user the best, absolute control over the deployment, new
features, or privacy of data.
2.2 Ownership
Opposite to commercially oriented ones (AWS IoT, Azure [5], IBM
Bluemix [6]), many open source platforms have been developed (Thing-
Speak, Nimbits [7], Kaa). Open source platforms typically offer all
services for free and depending on the license allow modification of the
source code. Commercial platforms usually offer part of the services
for free, with certain limitations. They limit users by time periods,
data storage, data usage rates, number of active devices and sensors,
number of application programming interface (API) keys, etc. Pricing
may vary from platform to platform. Users can be billed for example
periodically based on a number of connected devices (thethings.io [8],
M2X AT&T [9]), or billed based on a real usage of resources (AWS
IoT, Azure). Some platform providers offer free academic programs
allowing usage of a paid version of a platform for academic or research
purposes (AWS IoT, Azure).
2.3 Protocols
As described in [10], “the essence of an IoT platform is to enable the secure
connection of a multitude of heterogeneous sensing and actuating devices,
having different constraints and capabilities, to the Internet. In the absence
of de-facto communication standard(s), the sensing and actuating devices by
different vendors may subscribe to different interaction patterns, and may
implement different subsets of available communication protocols. As a re-
3
sult, arguably, the value of an IoT platform grows proportionally with the
number and the versatility of the supported devices. An ideal IoT platform
would offer a pool of standardized communication protocols where the device
manufacturer may select the appropriate protocols.” Most of the platforms
support the Hypertext Transfer Protocol / Secure (HTTP/S) commu-
nication protocol, thus require the devices to be more powerful and
capable of supporting traditional web protocols. Some platforms also
support more restricted protocols designed for constrained devices,
like MQTT1 (Carriots [11], IBM Bluemix), AMQP2 (Azure), or CoAP3
(thethings.io). Absolute majority of IoT platforms offer an API for
communication between connected devices that conforms to the rep-
resentational state transfer (REST) constraints. This communication is
typically done over the HTTP(S) protocol.
2.4 Development support

Not only support of different protocols, but also availability of libraries
and software development kits (SDKs) that simplify integration with
a platform’s API might raise a value of the platform for a user. Many
platforms, in addition to standard API’s that allow devices to commu-
nicate with the server, provide libraries (DeviceHub [12], SmartLiving
[13]) and SDK’s (Carriots, Azure) adapted for specific programming
languages and devices (such as Arduino, Raspberry PI, etc.). If libraries
(or any other third-party software) are developed externally, it might
be a good sign of an active community behind a platform. In many
cases, provided tools, API’s, SDK’s, or official documentation are not
clear, or sufficient enough, and thus large community and its support
can be one of a valid reasons for choosing a platform for a project.
2.5 Scalability
Most of the IoT projects start with a minimal number of devices in the
stage of prototyping and testing and increase the number of connected
devices as the demand grows. As the number of IoT devices becomes
1. See Appendix A for a brief introduction of the MQTT protocol.

2. Advanced Message Queuing Protocol.
3. Constrained Application Protocol.
4
very large, scalability of a platform becomes a critical issue. Platforms

may not be able to handle and efficiently manage millions of devices
and at the same time, devices, often with limited resources, may not
be able to handle increased number of requests. For that reason, it is
essential that a platform incorporates mechanisms that can coordinate
large number of devices and can deal with the scalability issues.
2.6 Security
“In IoT, physical objects are vulnerable to a large number of attacks, and thus
it is critical to ensure its security at different levels, starting from the object
level through the communication protocol up to the application level. Privacy
of users is also an important concern in IoT.” [14] “The main features that
differentiate IoT security issues from the traditional ones are the heterogeneous
and largescale objects and networks. These two factors, heterogeneity and
complexity, make IoT security much more difficult to deal with.” [15]
Authentication and authorization

Some platforms that allow users to determine the access rights to data
offer an option of setting a channel that stores data from devices and
sensor nodes as public (Xively, ThingSpeak). Data from these channels
are then accessible to anyone and don’t have to handle the overhead
of keeping the data private. Authentication of devices is mostly done
by providing API keys for each device. These keys, sometimes having
read and write part for each device (ThingSpeak), need to be pre-
sented as part of each API call, in order to retrieve or store data to
the platform. More secure way of authentication can be reached by
mutual authentication, for example with X.509 certificates (AWS IoT),
or with proprietary authentication methods. Also, authorization with
the OAuth4 protocol may be an option in some cases (Xively, M2X
AT&T).
Secure communication
Communication to and from cloud platforms can be secured with the
HTTPS protocol. Some platforms (Azure, AWS IoT) require the traffic
4. An open standard for authorization. See http://oauth.net/.
5
between the platform endpoints to be encrypted over the Transport

Layer Security (TLS). Encrypting communication to and from IoT
platforms can be challenging due to the diversity of things in IoT.
Many cryptosystems and security protocols are considered secure
and robust, but they may not be suitable for constrained devices with
limited computing power and battery capacity, such as sensor nodes
or wearable devices. [15]
Data ownership
One of the big concerns is also the ownership of data. The data pro-
duced by IoT devices may be confidential, and there is a risk of mis-
using or exploiting those data by the cloud provider. Although it is a
standard to declare the end user as an owner of his data in the terms
of service document of most of the platforms, only solution that truly
offers the full ownership of data to the end user is local deployment
of a platform (Kaa, locally deployed ThingSpeak).
2.7 Capabilities
2.7.1 Data visualization
One of the basic features of web-based platforms is visualization of
collected data. Data can be shown in a table or displayed on a graph
(static or dynamic). Various types of graphs can be seen across the
platforms, from simple line, pie, or bar graphs, to more complicated 3D
visualizations (ThingSpeak MATLAB, SensorCloud [16]). Devices that
can submit information about their location can bring visualization
one step further with platforms that support geolocation - visualizing
each device on a map (in real time). Graphs and tables may be arranged
on dashboards (AWS IoT, ThingSpeak), providing complex view over
the data. Platforms can provide tools and options for more personified
visualizations, by creating plugins and widgets using HTML, CSS,
JavaScript (ThingSpeak), or proprietary tools (SensorCloud).
2.7.2 Actions
IoT concept does not consist only of gathering data from nodes, but
also of processing them and acting upon certain detected changes. As
6
a response to certain changes in collected data, platforms can invoke

some predefined actions. These prescribed actions are sometimes re-
ferred to as triggers or rules. Conditions for invoking the actions may
vary from simple ones, as setting a threshold value for a data channel,
to fully customizable ones that allow a user to formulate his condition
in some programming language (SQL, MATLAB, JavaScript). Actions
may include sending a HTTP POST request to a specified Uniform Re-
source Locator (URL), changing an internal state of a connected device,
invoking a script, or integration with platform’s internal services (IBM
Bluemix, AWS IoT, M2X AT&T). Another way of triggering an action
is to integrate external services, such as email, Short Message Service
(SMS), or social networks, into the platform. These services can be also
used for scheduled alerts and notifications, if scheduling is supported.
M2X AT&T platform also offers integration of cellular connectivity
into the IoT applications for devices with SIM-based cellular support.
2.7.3 Data analysis
Cloud based analysys of stored or real time data is another example of

advanced features. Analysis can be done by incorporating computing
or scripting languages (GadgetKeeper [17], Carriots), e.g. MATLAB or
JavaScript language, or even by applying machine learning techniques
(Azure, AWS IoT). By analyzing data, user can get a helpful insight
into the state of IoT devices and its various metrics and can invoke
corresponding actions, or tune up settings of the platform.
2.7.4 Data storage
Advantageous feature can be cloud based data storage that allows

advanced search in the stored data (AWS IoT with Elasticsearch). Some-
times it is not necessary to store all incoming messages from IoT nodes,
e.g. when we only monitor the current state of the nodes. However,
when we want to analyze or access historical data points, data storage
is necessary. Data can be stored in a SQL/NoSQL database, in a form
of JavaScript Object Notation (JSON) files (AWS IoT) or just as simple
key-value pairs, depending on the format of messages and type of the
data. Some platforms also offer direct importing (ThingSpeak) and
7
exporting (ThingSpeak, AWS IoT) of data from IoT nodes in Extensible

Markup Language (XML) or Comma-separated Values (CSV) formats.
2.8 Overview table

Table 2.1 lists a representative sample of web-based IoT platforms
deployed in cloud that we considered for detailed comparison. Col-
umn (a) shows which platforms are still in a beta version and their
improved version is expected soon. Column (b) describes if a platform
is proprietary or open source (OS). Only one platform from the table
is open source, mainly because open source platforms are usually
centralized and require local deployment. Column (c) lists platforms
that offer support for developing applications on given platforms in
form of libraries or SDK’s for different languages or operating systems.
Column (d) shows that all listed platforms offer a RESTful API, which
is a standard feature for web-based platforms. Finally, support of the
MQTT protocol among the platforms is shown in column (e).
Platform a) Beta b) OS c) Lib./SDK’s d) REST API e) MQTT

ARM mBed [18] Yes No Yes Yes Yes
AWS IoT [3] No No Yes Yes Yes
Carriots [11] No No Yes Yes Yes
Device Hub [12] No No Yes Yes Yes
Gadget Keeper [17] Yes No No Yes Yes
Grove Streams [19] No No No Yes No
IBM Bluemix [6] No No Yes Yes Yes
M2X AT&T [9] No No Yes Yes Yes
Azure IoT [5] No No Yes Yes Yes
SenseIoT [20] No No Yes Yes No
Sensor Cloud [16] No No Yes Yes No
ThingSpeak [2] No Yes Yes Yes No
Xively [1] No No Yes Yes Yes
Table 2.1: A representative sample of web-based IoT platforms.
8
3 A review of the selected platforms
We have selected 3 different web-based platforms which we will com-
pare and test in detail in this thesis. Each of the platforms represents
particular group of platforms with common characteristics. Thing-
Speak is a representative platform for open source IoT projects, Xively
is a proprietary platform focusing on connected product management,
and AWS IoT is a platform developed by one of the leading companies
in the industry.
3.1 Xively
3.1.1 Naming conventions
Each platform uses different terms for representing similar concepts
across different platforms. Here is an explanation of key elements of
the Xively platform, as described in [21]:
• Channel – Every Datastream in the API is a two-way communi-
cations channel on the Xively platform. Channels are limited to
32 characters per Datapoint value.
• Datapoint – A single key value pair of a timestamp and the value
of a Datastream at a specific point in time.
• Datastream – A bi-directional communications channel that al-
lows for the exchange of data between the Xively platform and
authorized devices, applications, and services. Each Datastream
represents a specific attribute, unit or type of information (a
variable) archived as a series of Datapoints (data value plus
timestamp).
• Feed – A Feed is the collection of channels (datastreams), defined
for any given device. Every device has exactly one Feed.
• Device – Devices are individual, physical instances of a product.
• Product – Product is the highest level of abstraction in the Xively
data hierarchy. A product in Xively represents a specific type of
actual device.
9
3. A review of the selected platforms
3.1.2 About
Formerly known as Cosm and Pachube, Xively is developed by public
company LogMeIn, Inc., “a provider of software as a service and cloud-
based remote connectivity services for collaboration, IT management and
customer engagement.” [22] It is a cloud-based platform made with focus
on IoT. Its aim is to offer a complex solution for businesses, that are
seeking online management of their products, users and applications.
Xively presents itself as an enterprise IoT platform, but its design and
simplicity allows anyone to connect their devices or manage a project.
Platform sections
The platform itself divides the whole development process into three
steps: developing a device, deploying a device, and managing a prod-
uct. In the Develop stage, user can create and connect a prototype
device. These prototypes can be turned into products in the Deploy
stage by creating a batch of virtual products that correspond to user’s
physical devices. If created, the prototype device serves as a template
for creating the batch of virtual products. User can specify serial num-
bers for these devices manually, via the API, or by uploading a CSV
file. Finally, the Manage stage offers an overview of created products.
In this stage, the following actions are possible with devices: monitor,
search by entering (partial) serial numbers, deactivate, or add more
devices by adding new serial numbers.
3.1.3 Features
Visualization
In addition to a simple data visualization on a graph on a monitoring
page, Xively offers a preconfigured GitHub webpage [23] to present
data from feeds and channels. This webpage is written in JavaScript
and is available in a GitHub repository [24], free to modify under the
BSD 3-Clause license1 . Simple customizable graphs of a datastream’s
history can be also requested as a Portable Network Graphics (PNG)
images with the Xively API. Visualization of a current location of a
device on a map provided by Google is possible, if location data are
1. See https://opensource.org/licenses/BSD-3-Clause.
10
present. It is also possible to manually add location data to a device, if

the device is stationary and will not receive the data via API calls.
Data retrieval
After the data from physical devices are sent to the platform and stored
on the Xively server, user remains owner of this data. It is possible to
retrieve these datapoints within the specified range for one or more
datastreams with an API request. The time range for one API request
is limited to six hours, so if a user wants to retrieve data more than 6
hours apart, he needs to make multiple individual API requests.
Actions
Reacting to changes in data is possible via triggers. “Triggers provide
‘push’ capabilities by sending HTTP POST requests to a specified URL when
one or more conditions for a datastream are satisfied.” [25] The type of a
condition can be chosen from a final list of simple condition types, such
as greater than or equal to, and cannot be modified. Xively therefor
does not allow evaluation of more complex conditions and setting
custom triggers.
Pricing and limitations

Xively uses Pay as You Grow pricing model, but does not publically
share more specific details. Usage of the platform is free with certain
limitations, after a free registration. The unofficial statement describes
these limitations as:
• “Unlimited Development Devices with unlimited channels
• Development devices store data for 30 days
• Developer Account API limit of 25 API calls per minute across a
rolling 3-minute window” [26]
The unofficial limitations are tested and evaluated in the chapter 5.
API
Xively’s extensive API follows RESTful principles using the HTTP
protocol. Basically every operation needed for controlling and manag-
ing devices that Xively offers is accessible via the API. Depending on
11
the type of an operation, Xively accepts three formats in which data

is accepted/returned: JSON, CSV or XML. The API allows to search
feeds and limit or refine the search with query parameters (tags, units,
users, etc.). It also allows location-based searching of feeds. Any MQTT
enabled device can communicate and utilize full API interaction with
the Xively MQTT Bridge. MQTT topic strings are of the same format
as the API URLs.
Libraries
Xively offers libraries for integration with its API for wide range of
programming languages (C, Java, PHP, Ruby, etc.) and specific hard-
ware platforms (Android, Arduino, ARM mbed and Electric Imp). All
libraries are open source, mostly under the BSD 3-Clause license, and
hosted on GitHub.
3.1.4 Security
Protection of a device begins with its creation. After a user adds a
device into the platform by specifying its serial number, the device is
pre-registred, but not activated yet. The process of activating a device
is called provisioning. This term is derived from the fact that a device
is provisioned with a Feed identifier (ID) and an API key upon ini-
tial wake up (activation). A pre-registered device can be activated by
sending an Activation Code to the Xively API. “A device’s Activation
Code is generated using an HMAC-SHA12 hash that combines the device’s
Serial Number with its parent product’s Product Secret.” [27] The Activa-
tion Code is displayed in the device’s overview in the platform, but
can be also computed at each physical device, knowing the necessary
information.
User can choose if a device feed is public or private. Public feeds
can be indexed by search engines and their views are available at
a public URL. [28] Both public and private feeds use API keys to
control who can manipulate with the data they contain. One device
can have multiple API keys, each for different purpose. An API key
is a hierarchy of three objects: a key object, one or more permissions
objects, and optionally one or more resource objects. [28]
2. A Keyed-hash Message Authentication Code over a Secure Hash Algorithm 1.
12
Xively supports secure authorization of third-party applications

with the OAuth protocol implementation, which grants the third-party
application with an account-wide API key for accessing all resources.
Lastly, all communication to and from Xively platform is protected
with HTTPS over Secure Sockets Layer (SSL) security standard.
3.2 ThingSpeak
Here is an explanation of key elements of the ThingSpeak platform:
• Channel – The primary element of ThingSpeak activity, which

contains data fields, location fields, and a status field. [29]
• Field – A Field stores data uploaded to a channel. It could be

imagined as a variable.
3.2.2 About
ThingSpeak is an open source IoT web application built using the
Ruby on Rails framework and serves as a platform for creating IoT
applications. It was originally launched in 2010 by a company called
ioBridge [30] as an open data platform for the Internet of Things. The
whole application is deployed online on its dedicated website and it is
also available on GitHub [31] under the GNU General Public License
(version 3)3 for local deployment with customizable parameters.
ThingSpeak channel
The primary element of ThingSpeak platform is a channel. “Channels
store all the data that a ThingSpeak application collects. Each channel includes
eight fields that can hold any type of data in either numeric or alphanumeric
format, plus three fields for location data (elevation, latitude and longitude)
and one for status data.“ [32]
3. See http://www.gnu.org/licenses/gpl-3.0.html.
13
3.2.3 Features
ThingSpeak and MATLAB
ThingSpeak is collaborating with The MathWorks, Inc. (MathWorks)
corporation and has integrated support from MATLAB high-level pro-
gramming language oriented for numerical computing. Close relation-
ship with MathWorks allows users to utilize MATLAB’s capabilities
for visualization and analysis on uploaded data without requiring the
purchase of a MATLAB license. The ThingSpeak documentation site
is part of a MathWorks’ website and MathWorks user accounts can be
used as a valid login to the ThingSpeak website. Also, the ThingSpeak
support toolbox is available for desktop MATLAB to analyze and vi-
sualize data stored on the ThingSpeak platform (either web version
or private installation).
Visualization and analysis

For transforming and visualizing data or triggering an action in Thing-
Speak, so called apps are used. Visualizations of uploaded data are
possible with a simple embedded customizable line graph, or with
the MATLAB Visualization app. This application let’s user create an
interactive or static visualization using MATLAB functions in a user
friendly way. The MATLAB Code can be created from one of the
prepared templates and edited in the embedded code editor with the
output displayed directly below it. Another way to display custom
visualizations and controls on the private view of a channel is using
the Plugins app. For this, plugins allow user to use HTML, CSS and
JavaScript. Two JavaScript templates are already ready to use, a Google
gauge and a chart with multiple series.
MATLAB code can be also run in the MATLAB Analysis app,
which can be used for various calculations, data transformations, etc.
An example of a such calculation is calculating an average of a selected
feed, or finding and replacing missing values in data.
Actions
An unusual way of reacting to changes in data offer apps that integrate
ThingSpeak with the social networking service Twitter. These apps let
a user link a ThingSpeak account to a Twitter account and listen and
14
react to incoming tweets (TweetControl app), or send a new tweet as

an alert to a changes in data (ThingTweet).
React app “The React app works with other apps to perform actions when
channel data meets a certain condition.” [33] User can choose between
different condition types, test frequencies, conditions, and actions.
Although a user can choose condition type only from a list of given
conditions, more complicated triggers can be configured with the
MATLAB Analysis app. Actions can be run each time the condition
is met, or just once. When reacting to changes in data received from
physical devices that report their location, geo location condition can
be used. Reported latitude and longitude data can be checked with
constraints, such as is within or is farther then given range.
TimeControl app The TimeControl app triggers other ThingSpeak

apps at a specific time or on a regular schedule. It also has an option of
a triggering an app at a random time in given range. “TalkBack enables
any device to act upon queued commands.” [34] These commands are
managed via the REST API and the app have no maximum limit of
queued commands.
ThingHTTP app The ThingHTTP app enables communication of

devices with web services, APIs and any HTTP enabled devices. It
allows to send a HTTP request that is triggered by other ThingSpeak
apps. This request is fully customizable, from the URL, HTTP method
and version, headers and body, to an optional HTTP Auth username
and password.
Developer support
Since it is an open source project, naturally, it has an active community
of developers engaged in expanding the platform and creating third-
party applications, libraries, clients, or tutorials. All of the available
libraries, for example for Java, C, Ruby, or node.js languages, are open
source and developed externally by the community members. ThingS-
peak also has an application for Android devices called “ThingView”
[35] that enables visualization of ThingSpeak channels, both public
and private.
15
Limitations
The only officially stated limitation of the free ThingSpeak web ap-
plication is the ability to update a single channel every 15 seconds at
most. To meet stricter requirements, anyone can download and adjust
the source code and install the application locally.
API
ThingSpeak’s REST API can be used for every important operation
related to channels or feeds. The API is capable of processing numeric
data from channels when retrieving them, which includes summing,
rounding, averaging, or median. It also contains API calls for creating
end embedding ThingSpeak charts. All HTTP requests support re-
sponses in XML, JSON or text format. In case of a text format response,
the response is a webpage containing the response body. “Each channel
data entry is stored with a date and time stamp and is assigned a unique
entry ID.” [36] It is possible to retrieve stored data by specifying time
or this entry ID.
Apart from sending the data directly from a device to a channel,
data import in a form of a CSV file is possible. All the data from a
channel can be also exported to a CSV file at any moment.
3.2.4 Security
Channels are divided into two categories: public and private. By de-
fault, a channel is private and requires a Read API key to access its
feed. Owner of the channel can make a channel public, which gives
other users the ability to use the channel’s feed without a Read API
key. [36]
Write and read API keys enable writing and reading data to or
from a (private) channel using ThingSpeak API or MATLAB code.
API key is a 16-digit auto-generated string generated on a channel
creation. Both Read and Write API keys can be regenerated in the
channel settings, with the option of having multiple Read API keys
for different applications. API keys need to be specified in each HTTP
request or MATLAB function. A user’s API key is used for API calls,
such as creating a new channel, when there is no Read or Write API
key specified prior to the call.
The ThingSpeak web application and API calls are secured with
the HTTPS protocol.
16
3.3 AWS IoT

Here is an explanation of key elements of the AWS IoT platform, as
described in [37]:
• Thing – Things are applications, connected devices, or physical

objects that are supported by an Amazon cloud application.
• Thing Registry – Also referred to as the Device Registry. Orga-

nizes the resources and stores attributes associated with each
thing. Each thing can be associated with up to three custom
attributes.
• Thing shadow – Also referred to as a device shadow. “Device

Shadows are a persistent virtual version (a JSON document) of each
thing that includes the thing’s last reported state and desired future
state, even when the underlying thing is not connected.” [38]
• Message broker – It is a publish/subscribe broker service that

enables sending and receiving messages to and from AWS IoT.
[37] It is responsible for authenticating devices, securely ingest-
ing device data, and adhering to the access permissions placed
on devices using policies. [37]
3.3.2 About
AWS IoT is an IoT management cloud platform that’s part of a big col-
lection of cloud computing services offered by the American electronic
commerce and cloud computing company Amazon.com, Inc. Amazon
is one of the biggest providers of cloud computing services on today’s
market and many large companies rely on their availability. Amazon’s
cloud services are currently available in 12 geographic regions around
the world, powered by discrete datacenters. [39]
3.3.3 Features
In contrast to the other analyzed platforms, AWS IoT platform serves
solely as a platform for bi-directional communication between things
17
and the AWS Cloud. For data storage, visualizations, data processing,
etc., another AWS services are used. In most cases the platform is not
used independently and works as a gateway for devices to commu-
nicate with other AWS services. AWS IoT contains the Rule Engine,
which offers the ability of interaction with these services. Rules that
evaluate inbound messages are written in an SQL-based language,
which gives a user an option to fully customize these rules. “A rule can
apply to data from one or many things, and it can take one or many actions in
parallel.” [40] However, the Rule Engine has access only to the current
shadow state and cannot take any contextual information into account.
For this purpose, AWS Kinesis combined with AWS Lambda services
can be used. This situation is described in the chapter 5, in more detail.
AWS services that are directly integrated with the AWS IoT platform
through the Rules Engine are:
• Amazon CloudWatch, for capturing metrics, changing alarm
states, and logging.
• Amazon DynamoDB, for writing data to managed NoSQL databases.
• Amazon Elasticsearch, for data searching, analytics, and visual-

izations (via the integrated Kibana open source plugin).
• Amazon Kinesis, for real-time processing of streaming data.
• Amazon Simple Storage Service (S3), for data storage.
• Amazon Simple Notification Service (SNS), for sending notifica-

tions (even to external endpoints).
• Amazon Simple Queue Service (SQS), for queuing data to be

later retrieved.
• Amazon Lambda, for executing custom code in Java, Node.js or

Python on Amazon virtual servers.
Using rules, user can also republish received messages to another
MQTT topic.
Visualizations of data from thing shadows are not integrated into
the platform itself. Amazon takes more uniform approach with the
Amazon Elasticsearch Service, allowing real-time monitoring, search
18
and visualization of any data centrally, not only from the AWS IoT.
Amazon Elasticsearch Service is a AWS service that provides the open
source search engine Elasticsearch in the AWS Cloud. It integrates the
open source visualization platform Kibana (version 3 and 4), which
is an Elasticsearch plugin. Kibana offers various ways how to display
and analyze data in real time. For example, it can visualize data on
area, line, pie, or bar charts, display them in tables or metric widgets,
and can also display geographical data. These charts and widgets can
be arranged on dashboards. Additionally, all data can be exported in
a CSV format.
Pricing and limits

AWS are paid services billed based on real usage of resources and
each service has different pricing terms. AWS IoT prices are based on
the number of published and delivered messages. [41] Amazon offers
a free tier that expires 12 months after a free sign-up. The contents
of the free tier vary from service to service, AWS IoT offering 250,000
free messages (published or delivered) per month. However, there
is a requirement to enter a credit card information during a sign-up.
Amazon also runs the AWS Educate program [42] that offers students
and educators credits for AWS services. Combined with the GitHub
Student Developer Pack program, students from institutions that are
in non-member relationship with Amazon can obtain up to $50 worth
of credits for the AWS. “For AWS IoT, the payload for every publish message
is limited to 128 KB and the ingress and egress rate on each client connection
is limited to 512 KB/s.” [37] A detailed list of limitations can be found
in [37].
Scaling
The advantage of the large infrastructure behind AWS is the ability to
(rapidly) scale hosted applications. AWS IoT can support billions of
devices, and can process and route their messages to AWS endpoints
and to other devices by automatically scaling to user’s needs. [40]
API
The advantage of using a device shadow in IoT applications is that
these applications can provide always available API for interaction
19
with devices, even when the devices are not available. “In addition,
applications can set the desired future state of a device without accounting
for the devices current state, by comparing the difference between the desired
and last reported state” [40] AWS IoT supports two ways how to update
a device shadow – with RESTful API over HTTP protocol and with
MQTT publish/subscribe messages. The documents for UPDATE,
GET, and DELETE operations are called Request State Documents and
are in form of a JSON file.
Format of a Request State Document: [37]
{
"state": {
"desired": {
"attribute1": integer2,
"attribute2": "string2",
...
"attributeN": boolean2
},
"reported": {
"attribute1": integer1,
"attribute2": "string1",
...
"attributeN": boolean1
}
}
"clientToken": "token",
"version": version
}
SDK
There is an option to use the AWS IoT Device SDK for connecting
hardware devices to the platform. “It has been developed in C language
for constrained devices or systems on a chip (SoC) with 256 KB or more
of available memory. The Device SDK simplifies the process of connecting
embedded devices to the AWS IoT platform by implementing the security
requirements to connect to the broker of the AWS IoT service and providing
basic publish/subscribe functionality as well as access to device shadows over
20
MQTT.” [37] The SDK currently supports Arduino Yún, C for embed-
ded platforms, and JavaScript. All AWS services can be managed with
the AWS Command Line Interface (CLI), which is a unified command
line interface to AWS available for Windows, Mac, and Linux systems.
It provides tools to configure, control and automate the AWS services
through scripts.
3.3.4 Security
“Each connected device needs a credential to access the message broker or
the Thing Shadows service.” [37] After data reaches the message broker,
AWS cloud security mechanisms, such as the AWS Identity and Access
Management (IAM), protect data as it moves between AWS IoT and
other devices or AWS services. [37]
“All traffic to and from AWS IoT must be encrypted over Transport Layer
Security (TLS).” [37] TLS is used to ensure the confidentiality of the
application MQTT and HTTP protocols supported by AWS IoT. AWS
IoT supports several TLS cipher suites, with the ECDHE-RSA-AES128-
GCM-SHA256 cipher suite being recommended. [37]
Authentication
“AWS IoT supports three types of identity principals for authentication.”
[37] When using HTTP protocol, IAM (users, groups, roles) and Ama-
zon Cognito identities [37] are supported. When using MQTT, X.509
certificates [43] are supported.
“IAM users, groups, and roles are the standard mechanism for managing
identity and authentication in AWS.” For message broker connections,
they are authenticated using the signature version 4 signing process.
[37] The signature is calculated using information such as the AWS
service, region, action, timestamp and user’s AWS access key. The
signature is added to the header of the request or as a query string
parameter. [44]
Amazon Cognito Identity allows usage of custom identity provider
or leverage of other popular identity providers, such as Login with
Amazon, Facebook, or Google. Token from the identity provider is
then exchanged for AWS security credentials. [37]
“X.509 certificates are digital certificates that use the X.509 public key
infrastructure standard to associate a public key with an identity contained
21
in the certificate. X.509 certificates are issued by a trusted entity called a

certificate authority (CA).” The CA has private access to one or more
special CA certificates, maintains them and uses them to issue X.509
certificates. “X.509 certificates enable asymmetric keys to be used with
devices.” AWS IoT authenticates certificates using the TLS mutual au-
thentication with a client certificate. [37]
User is responsible for managing device credentials (X.509 certifi-
cates and AWS credentials) on connected devices and policies in AWS
IoT. “Device credentials must be kept safe in order to send data securely to
the message broker.” [37]
Authorization
Only authenticated identity can execute AWS IoT operations and only
if it has granted appropriate permissions. For communication between
two or more AWS services appropriate roles and policies need to be
set. By creating IAM roles user can control rules and their access to
the AWS resources. By creating IAM policies, permissions to IAM
users, groups, and roles can be applied. On the other hand, AWS IoT
policies control access to AWS IoT resources (MQTT topics, devices,
thing shadows, etc.). [37] Roles and policies have both form of a JSON
file with specified parameters and can be managed from the Identity
and Access Management (IAM) console, or via the API.
Each AWS resource has a unique identifier called Amazon Re-
source Name (ARN).
22
4 The tested scenarios
The following chosen scenarios try to simulate real life situations in
which web-based platforms for IoT management might be helpful and
beneficial. They focus on individual nodes communicating indepen-
dently and asynchronously with the cloud service. Properties and
details of individual scenarios were designed in a way in which they
would correspond with the setup of the WSN testbed in the Centre
for Research on Cryptography and Security (CRoCS) at the Faculty of
Informatics, Masaryk University.
The first scenario contains only basic requirements against the
tested platform (recording and visualizing data) and meeting them
should not be a difficult task for any IoT platform. Results of this
scenario could show how easy and time consuming it is to setup the
platform and connect minimal number of devices, as well as how user
friendly the platform is.
1. Let's have 3 temperature sensors in 3 different rooms. Each sen-

sor sends information about measured temperature every 15
seconds to the platform (cloud). We are measuring the data for
at least 30 minutes. We want to visualize sent data on a graph(s).
The second scenario includes the same number of nodes and the
same upload rate as the first one. However, it increases the number of
measured and recorded attributes for each node.
2. Let's have 3 nodes in 3 different rooms. Each node has 3 sensors:

one measures temperature, one measures humidity, and one
measures amount of light in a room. Each node sends measured
data from all three sensors (each in floating point precision)
every 15 seconds to the platform (cloud). We are measuring the
data for at least 30 minutes. We want to visualize sent data on a
graph(s).
The third scenario raises requirements for the number of nodes as well
as the upload ratio. It tests how big data load each platform is capable
of handling. It also adds a requirement for triggering an action if given
condition is met.
23
4. The tested scenarios
3. Let's have 15 temperature sensors distributed around an office

floor. Each sensor sends information about measured temper-
ature in floating point precision every second to the platform
(cloud). If any of the sensors detects temperature higher than
60°C, an alert or notification is sent/displayed.
The fourth scenario adds more complex requirements for triggering an

action and tests how would the tested platform perform under higher
demands for computational power, storage and processing speed.
4. Let's have 30 nodes with temperature sensors and humidity sen-

sors distributed around an office floor. Each node sends informa-
tion about measured temperature and humidity every second to
the platform (cloud). If any of the sensors detects temperature
higher than 60°C more than twice in previous 4 seconds, or dif-
ference between previous and current measurement is bigger
than 6°C an alert or notification is sent/displayed.
24
5 Results of tested scenarios
In this chapter, results of individual scenarios tested on selected plat-
forms are described and analyzed. To test the scenarios, we did not
use actual physical sensor nodes, but rather simulated these nodes
with prepared scripts. This was possible thanks to the RESTful APIs
(and MQTT publish/subscribe in the case of AWS IoT) individual
platforms offer, that are not platform dependent. Source codes of the
scripts can be found in the electronic attachments. Note that for this
testing we used only features of the platforms that were available for
free or under a free (student) trial. Thus some scenarios might have
different outcome when tested on paid versions of the platforms.
Below is a comparison table showing which of the three selected
platforms were able to fully meet the requirements (3) set in the pre-
pared scenarios. In some cases, results were successful only partially.
These cases are shown as unsuccessful (5) in the table, but are ex-
plained in detail below.
Scenario 1 Scenario 2 Scenario 3 Scenario 4

Xively 3 3 5 5
ThingSpeak 3 3 5 5
AWS IoT 3 3 3 —
Table 5.1: Results of tested scenarios.
5.1 Xively
5.1.1 Scenario 1
Procedure of work
After a free registration and login into the web application, user can
start with connecting his IoT devices. Note that for testing these scenar-
ios, we used only the version of Xively for personal use. For accessing
the enterprise version, user needs to submit a personal request. We
added a new private device in the Develop part of the application,
by providing its name and description and adding one channel for
25
5. Results of tested scenarios
storing temperature data. This development device served us as a pro-

totype for creating a batch of three product devices, that represent the
three simulated sensor nodes. After manually adding serial numbers
of our devices (in our case just simple names as Sc1_node1), it was
necessary to activate these devices prior to uploading data to them.
Activation code necessary for the activation can be computed knowing
the needed secrets. For simplicity of this test, we just copied generated
activation codes from the platform. We activated each device by send-
ing a HTTP GET request to the platform. If successful, a API key and
a feed ID that are needed for uploading data to channels, are returned
in the return body of each request. Again, this information can be
later accessed from the platform itself. After an activation, devices are
ready for uploading and retrieving data. We used a Python script with
imported Xively library for simulation of 3 sensor nodes, each updat-
ing a Xively channel every 15 seconds. Temperature was a number in
floating point precision randomly generated at each update. We were
simulating the nodes for 30 minutes and visualizing the incoming
temperature data on a graphs in the platform.
Results
This test fully met the requirements of the first scenario. Data were
continuously uploaded and visualized on a graph in real time. The
process of setting up the platform and connecting a device was not dif-
ficult, thanks to the complete documentation and the Python wrapper
library for the Xively API. Data from the channels are still accessible
after one month, when the test were executed.
Figure 5.1: Raw datapoints from a single Xively channel.
26
5.1.2 Scenario 2
Procedure of work
Preparation of Xively devices for the second scenario was done in a
similar fashion to the first one, only this time we added 3 channels,
humidity, light, and temperature, to the prototype device. In the first
try, we ran the simulation of sensor nodes with a similar Python script,
using the Xively library for Python. However, this library doesn’t
offer an option to update all channels of a feed in a single API call.
Instead, it requires to update each datastream separately, in this case
resulting in three API calls per one update of a feed. Execution of this
script repeatedly resulted in an HTTP 403 error after approximately
72 requests in 2 minutes. This result suggests looser API limits than
expected unofficial limit of 25 API calls per minute across a rolling
3-minute window. For the second try, we prepared another Python
script, this time uploading the whole feed at once using directly the
REST API. We were simulating the sensor nodes for 30 minutes and
visualizing the incoming data in the GitHub web application.
Results
This test fully met the requirements of the second scenario. The plat-
form managed the devices with 3 attributes without any problems.
The web application for data visualizations served as a convenient al-
ternative for the graphs in the platform, also with an option to specify
time ranges of displayed graphs.
Figure 5.2: A graph from the Xively’s GitHub web application.
27
5.1.3 Scenario 3
Procedure of work
As in the first and second scenario, we created and activated a batch
of 15 product devices. We added a trigger to each one of them, using
the Xively library for Python. The trigger was the same for all of
them, sending a HTTP POST to the Zapier web service [45] if the
temperature channel receives a value greater than 60. We tried to
continuously update all channels one after another in a cycle and after
a few minutes update the temperature value of a randomly selected
device to a value in a range from 61 to 65.
Results
We repeatedly tried to update the channels in the specified rate, and
every time we received an HTTP 403 error. Including the attempts from
the previous scenario, it seems that the API limit might be in a range
of approximately 75 API calls across a rolling 3-minute window. This
is just an assumption and we suggest to perform more detailed tests to
specify the API limits. The setup of triggers was straightforward using
the API, as well as manually. Body of the HTTP POST invoked by a
trigger contains information about the feed as well as the triggering
datastream value. The trigger was invoked correctly, but to receive
a notification we needed to use an external service that waits and
responds to HTTP requests. Because of the API limits, we weren’t able
to upload data to the platform in the required rate and therefor the
Xively platform doesn’t meet the requirements for the third scenario.
5.1.4 Scenario 4
Results
It is possible to connect 30 devices, but because of the API limits and
the impossibility to create custom conditions for triggers, the Xively
platform doesn’t meet the requirements for the fourth scenario.
28
5.2 ThingSpeak
5.2.1 Scenario 1
Procedure of work
After a free registration and login into the web application, we man-
ually created three channels in the platform. For each channel, we
specified its name, description, and a field label. If a channel is cre-
ated using the REST API, information about it, including the write
API key that is necessary for updating a channel, is in the response
of the HTTP request – in a text, JSON, or XML format, depending
on which data format we use. The API keys are also accessible via
the web application. We prepared Python scripts for the simulation
of the sensor nodes using the REST API. Temperature values were
randomly generated numbers from a given range generated at each
update. We were simulating the nodes for 30 minutes and visualizing
the incoming temperature data on a graphs in the platform.
Results
This test fully met the requirements of the first scenario. The web
application is user friendly and very intuitive. Data were uploaded
and visualized in real time. Also, the properties of the graphs can be
modified. The uploaded data are still available in the platform after
more than three months, when the tests were executed.
5.2.2 Scenario 2
Procedure of work
For this test, we created the channels using the REST API. For each one
of them, we specified three data fields. As in the previous test, we were
updating the data using the REST API. We were simulating the sensor
nodes for 30 minutes and for visualization we used the MATLAB
Visualizations app. For each graph we entered a custom MATLAB
code into the code editor in the web application and specified its
appropriate channel.
Results
This test fully met the requirements of the second scenario. While
29
updating the data, we monitored some lost messages, meaning that

approximately 10% of HTTP requests were not recognized and up-
dated in the platform. This might have been caused by many factors
and we suggest to carefully examine this, before using the platform
for more extensive applications. The created graph 5.3 is just a brief
example of possible utilizations of the MATLAB Visualizations app.
Figure 5.3: A plot generated with the MATLAB Visualizations app.
5.2.3 Scenario 3
Procedure of work
As in the previous test, we set up 15 channels via the API. We created
instances of the ThingHTTP and React apps manually in the web ap-
plication, because there is no option to create and manage them with
the API. Each channel needs to have a unique instance of the React
app. These instances then invoke the ThingHTTP app that invokes
HTTP requests. If we want a body of such request to contain an ID of
30
the channel that invoked the trigger, we also need a unique instance
of the ThingHTTP app for each channel. Otherwise, one instance of
the ThingHTTP app can handle all instances of the React app. For this
test, we set up a trigger only for one of the channels, as we believe that
setting up triggers for every channel would not affect the results and
would be just a redundant and lengthy activity, due to the unavailabil-
ity of API functions for the apps. As in the tests for Xively platform,
we used the third party service Zapier for notifications.
Results
We were unable to update each channel every second, because as
stated in the official documentation, the web platform has a limit of one
update of a single channel per 15 seconds. The platform returns status
code 200 (OK) for all update requests, but it updates each channel
only once per 15 seconds. The trigger was fired correctly and without
significant delay. Due to the API limits, the ThingSpeak platform
doesn’t meet the requirements for the third scenario.
5.2.4 Scenario 4
Procedure of work
As in the previous tests, we created 30 channels via the API. We cre-
ated an instance of the MATLAB Analysis app in which we defined
the conditions described in the fourth scenario using the MATLAB
language. If a user wants to analyze data of a channel with the MAT-
LAB Analysis app and subsequently react to the analyzed changes,
he needs to set up following data flow in the platform. Data need to
go from a channel via a React app to a MATLAB Analysis app, then if
conditions are met data are written to a second channel, from which
they go via a React app to a ThingHTTP app, which finally invokes
a HTTP request to some external service. This rather complicated
process needs to be manually configured for each channel separately.
For simplicity of this test, we set up the trigger only for one of the
channels.
Results
Because of the API limits, the ThingSpeak platform doesn’t meet the re-
quirements for the fourth scenario. The MATLAB analysis app worked
31
correctly for analysis of incoming data, including processing histor-

ical data and writing data to a ThingSpeak channel. The MATLAB
Analysis app is an effective tool, however the process of setting up
the platform and connecting all the apps together is time-consuming.
Especially because of the need of a custom MATLAB code for each
channel, a use of this platform might be impractical in similar real life
scenarios.
5.3 AWS IoT

5.3.1 Scenario 1
Procedure of work
To login into the platform, a user needs to have an Amazon account
with a validated credit card information. For purposes of these tests
we only used Amazon services included in the free tier or offered in
the scope of the AWS Educate program. For this test we manually
created three resources called things, that represent connected IoT
devices, in the web application. After creating a thing, a user has an
option to generate a certification authority (CA) certificate, a client
certificate, and a client key file, that are needed for authentication of
a device’s connection to AWS IoT. A user can also register and use
his own certificates. Subsequently, we needed to link these certificates
with our things. For each of the devices we created a resource called
a rule. For each rule, we specified its name, a source of the messages
we want to process specified with an SQL-like query statement, and
an action we want to happen when the message is forwarded by the
rule. In this case, we chose the Amazon Elasticsearch service as an
action. We added a policy that allows the AWS IoT to communicate
with the Elasticsearch service and configured the Elasticsearch service
in its dedicated console. For every Elasticsearch domain, there is a pre-
pared web application with implemented Kibana plugin that allows
visualization of data from that domain. For simulation of the sensor
nodes and updating the thing shadows, we were publishing MQTT
messages to the topics of each device using an open source JavaFX
application called mqtt-spy [46]. This application also allows a user
to authenticate his devices using the generated certificates. We were
simulating the nodes for 30 minutes and visualizing the data in the
Kibana web application.
32
Results
This test fully met the requirements of the first scenario. The generated
graphs could be arranged on a dashboard and allowed computations of
simple metrics, such as average or maximum values. The preparation
of the platform and connecting devices was rather complicated, mainly
because of more security features of the AWS IoT platform and the
need of forwarding the data to other AWS services. The uploaded data
are still available in the platform after more than two months, when
the tests were executed. It is also possible to retrieve data from specific
time periods or containing specific values for visualizations in Kibana.
5.3.2 Scenario 2
Procedure of work
For the testing of the second scenario we used the things and rules we
created in the first test. The number of attributes each thing shadow
stores depends solely on a format of the request state document, so if a
user wants to add more attributes to a thing, he only needs to modify
the JSON message. We changed the mapping of the Elasticsearch
domain as well as the index pattern in Kibana, so the messages could
be correctly processed. We used the same method for uploading and
visualizing data as in the previous test.
Results
This test fully met the requirements of the second scenario. Changing
properties of a thing shadow is straightforward and supported by
the platform. In the Kibana graph 5.4 we can see a comparison of
measured humidity values from the three sensor nodes as well as a
simple statistics of these measurements.
5.3.3 Scenario 3
Procedure of work
For this test we created 15 nodes using the AWS CLI. Once set up and
configured, it is the fastest way to control and manage AWS resources.
Using the AWS CLI and a configuration file, we also created 15 AWS
IoT rules. The rules were configured for forwarding a message from a
thing shadow to a AWS SNS topic, if a temperature value in the thing
33
shadow is greater than 60. In the AWS SNS service, we created a SNS
topic that sends an email to specified email address when invoked by
the AWS IoT rule. We used the same method for uploading data as
in the previous tests. We were updating all thing shadows once per
second for 30 seconds with a randomly generated value in a range
from 23 to 25 and then updated one thing shadow with a value greater
than 60.
Figure 5.4: Visualization of data with the Kibana application.
Results
This test fully met the requirements of the third scenario. The platform
handled the upload ratio without any problem. We also received the
email from the SNS service without any significant delay. Sending
an email is just one of many ways how to send a notification from
the SNS service. For example, the SNS service can also send a HTTP
request or invoke a AWS Lambda function. The option to send email
notifications directly from an Amazon proprietary service can be
a significant advantage over other platforms that require use of an
external service. The AWS CLI was well documented and performed
without problems.
34
5.3.4 Scenario 4
Procedure of work
Conditions in the fourth scenario require comparison of historical
data points, however the AWS IoT rules have access only to the current
state of a thing shadow. An AWS Kinesis service together with an AWS
Lambda can be used in this scenario. Following is a recommended
way of configuring the AWS Services for fulfilling the Scenario 4. After
creating 30 things and 30 rules for each thing, user needs to create and
configure an AWS Kinesis stream. The AWS IoT rules need to push data
from thing shadows directly into the Kinesis stream. Afterwards, the
user needs to create a AWS Lambda function with a custom JavaScript
code and add the Kinesis stream as its event source. The lambda
function needs to distinguish which message comes from which node
and based on this compute if the conditions for triggering an action
are met. User also needs to create and configure an AWS SNS topic
which will be invoked from the lambda function. Correct IAM roles
need to be set between each two AWS services that communicate with
each other.
Results
The AWS IoT platform handled the number of devices and rules and
corresponding upload rate without any problems. However, we were
not able to correctly set up and configure the AWS services, mainly the
AWS Kinesis and AWS Lambda, in a time frame of 2 days, which we
believe is an adequate time for such scenario. Fulfilling this scenario
using the AWS IoT platform also requires a deeper understanding of
other AWS services and their reciprocal communication. For testing
this scenario using the AWS IoT platform, we suggest to perform
separate tests and to research topics that are beyond this survey.
35
6 ThingSpeak and a testbed experiment
To further demonstrate capabilities of web-based platforms for IoT
management, we have decided to use data from sensor nodes from the
WSN testbed network located at the CRoCS laboratory at Masaryk Uni-
versity. The data were collected during an experiment that was carried
out in the July of 2015 over a period of 5 days. The WSN consisted of 25
TelosB sensor nodes, each separately broadcasting signal cyclically in
three output powers (-25 dBm1 , -15 dBm, 0 dBm). Only one node was
transmitting at a time. The nodes were disposed in an office floor and
directly connected with a server via a Universal Serial Bus (USB) hub.
Received signal strength indication (RSSI) was then measured on each
node and directly reported to the server. For this demonstration, we
have selected the ThingSpeak platform. The main reasons for choosing
this platform were the option to use MATLAB language for analysis
and visualization directly in the platform, the fact that ThingSpeak is
an open source project and can be locally altered if needed, and lastly
the simplicity of the ThingSpeak web application that allows a quick
setup of data channels and their analysis.
6.1 Demonstration
Instead of simulating the nodes and sending the data to the platform,
we took advantage of the option of the ThingSpeak platform to import
data from a CSV file. The database on the server contained three tables,
one for each output power, from which we extracted data points for one
representative node. These data points consist of an ID of a source node
that was transmitting a signal at that particular time, timestamp, and
a measured RSSI (in dBm). We created three channels in the platform,
each representing the selected node monitoring signal strengths from
the nodes transmitting in the three output powers. We processed the
data with the MATLAB Analysis and Visualization apps. In the graph
6.1 we can see how many nodes the selected node detected in last 60
messages transmitted in -15 dBm and their corresponding ID numbers.
1. Decibel-milliwatts.
36
6. ThingSpeak and a testbed experiment
Figure 6.1: Detected unique nodes in last 60 messages.
The following is a partial output of the MATLAB Analysis app,

in which we analyzed the recorded data. ThingSpeak server allows
to read and process up to 8,000 historical data points. Using MAT-
LAB functions user can then compute various statistical data, such
as maximal or minimal values and IDs of nodes they come from. By
comparing the analyzed outputs for different output powers, we can
see, for instance, that the number of detected nodes as well as the
maximum detected RSSI increases with an increasing output power.
Such analysis can be done in real time and could offer a useful insight
into a user’s network of IoT devices.
Number of detected nodes - last 100 messages: 18
Max detected RSSI [dBm] - last 100 messages: -65
Min detected RSSI [dBm] - last 100 messages: -92
Max RSSI from last 100 messages detected from nodes with
following IDs: 49 49 49 49 49 49
37
7 Conclusion
This thesis explored available web-based platforms for IoT manage-
ment from various perspectives. Their basic characteristics and capa-
bilities were described, including the security of the platforms and
the security of data transferred to and from the platforms. The out-
come of this part of the research is a description of features that can
be considered as a standard among IoT management platforms, such
as provision of RESTful API or basic visualization tools, as well as a
description of some distinct features.
In the next chapters, the three selected platforms, Xively, Thing-
Speak, and AWS IoT, were thoroughly described and their capabilities
were compared on the prepared scenarios. It was ascertained that
while platforms Xively and ThingSpeak offer user friendly interface
and are relatively quick to configure, they offer less security features
and allow only limited data upload rate. On the other hand, the AWS
IoT platform utilizes the most security features out of the three plat-
forms and is oriented more towards big business customers, than
towards developers of small scale IoT projects or application proto-
types.
After these comparisons, the ThingSpeak platform was used to
demonstrate its capabilities on data from real sensor nodes and it was
proved how web-based platforms can be utilized in real life situations.
Information provided in this thesis might be beneficial for users
seeking IoT management platforms for their projects or anyone want-
ing to gain more knowledge in the current offer of web-based IoT
platforms.
38
Bibliography
[1] LogMeIn, Inc. Xively. url: https://xively.com/ (visited on
02/12/2016).
[2] The MathWorks, Inc. ThingSpeak. url: https : / / thingspeak .
com/ (visited on 02/12/2016).
[3] Amazon Web Services, Inc. AWS IoT. url: https://aws.amazon.
com/iot/ (visited on 02/12/2016).
[4] CyberVision, Inc. Kaa. url: http://www.kaaproject.org/ (vis-
ited on 05/10/2016).
[5] Microsoft. Microsoft Azure. url: https : / / azure . microsoft .
com/en-us/services/iot-hub/ (visited on 02/12/2016).
[6] IBM Corporation. IBM Bluemix IoT. url: http://www.ibm.com/
cloud-computing/bluemix/internet-of-things/ (visited on
02/12/2016).
[7] Nimbits. url: http : / / bsautner . github . io / com . nimbits/
(visited on 02/12/2016).
[8] thethings.iO. url: https://thethings.io/ (visited on 02/12/2016).
[9] ATT Intellectual Property. M2X. url: https://m2x.att.com/
(visited on 02/12/2016).
[10] J. Mineraud et al. “A gap analysis of Internet-of-Things plat-
forms.” In: Computer Communications (2015). issn: 01403664. url:
https://www.scopus.com/inward/record.uri?eid=2-s2.0-
84961918608&partnerID=40&md5=04838d9bde2653161a5815fceeb194e4.
[11] Carriots. url: https://www.carriots.com/ (visited on 02/12/2016).
[12] OT Solutions Sp. z o. o. DeviceHub. url: https://www.devicehub.
net/ (visited on 02/12/2016).
[13] SmartLiving. url: http://www.smartliving.io/ (visited on
02/12/2016).
[14] I. Mashal et al. “Choices for interaction with things on Internet
and underlying issues”. In: Ad Hoc Networks 28 (2015), pp. 68–90.
issn: 1570-8705. doi: http://dx.doi.org/10.1016/j.adhoc.
2014.12.006. url: http://www.sciencedirect.com/science/
article/pii/S1570870514003138.
[15] Z. K. Zhang et al. “IoT Security: Ongoing Challenges and Re-
search Opportunities”. In: 2014 IEEE 7th International Confer-
39
BIBLIOGRAPHY
ence on Service-Oriented Computing and Applications. Nov. 2014,

pp. 230–234. doi: 10.1109/SOCA.2014.58.
[16] LORD MicroStrain. SensorCloud. url: http://www.sensorcloud.
[17] GadgetKeeper. url: http : / / gadgetkeeper . com/ (visited on
02/12/2016).
[18] ARM Ltd. ARMmbed. url: https://www.mbed.com/en/ (visited
on 02/12/2016).
[19] GroveStreams.com. Grove Streams. url: https://grovestreams.
[20] SenseIoT. url: http://www.sense-iot.com/ (visited on 02/12/2016).
[21] LogMeIn, Inc. Xively Glossary of Terms. url: https://personal.
xively.com/dev/docs/glossary/ (visited on 04/11/2016).
[22] Wikipedia. LogMeIn — Wikipedia, The Free Encyclopedia. [Online;
accessed 18-May-2016]. 2016. url: %7Bhttps://en.wikipedia.
org/w/index.php?title=LogMeIn&oldid=719928773%7D.
[23] Visualizing Xively Feeds. url: http://xively.github.io/channel-
viz/ (visited on 04/05/2016).
[24] GitHub, Inc. Xively Channel Visualization. url: https://github.
com/xively/channel-viz (visited on 04/05/2016).
[25] LogMeIn, Inc. Triggers. url: https://personal.xively.com/
dev/docs/api/metadata/triggers/ (visited on 04/25/2016).
[26] Electric Imp. Discussion forum. url: https://forums.electricimp.
com / discussion / 2108 / max - frequency - of - updates - to -
xively-w-o-getting-booted (visited on 04/25/2016).
[27] LogMeIn, Inc. Activate a Device. url: https://personal.xively.
com/dev/docs/api/product_management/devices/activate_
device/ (visited on 04/25/2016).
[28] LogMeIn, Inc. Security. url: https://personal.xively.com/
dev/docs/api/security/ (visited on 04/26/2016).
[29] The MathWorks, Inc. Getting Started with ThingSpeak. url: https:
//www.mathworks.com/help/thingspeak/getting- started-
with-thingspeak.html (visited on 04/28/2016).
[30] ioBridge, Inc. ioBridge. url: http://www.iobridge.com/ (visited
on 04/20/2016).
[31] GitHub, Inc. ThingSpeak. url: https://github.com/iobridge/
thingspeak (visited on 04/28/2016).
40
BIBLIOGRAPHY
[32] The MathWorks, Inc. ThingSpeak channels. url: https://thingspeak.

com/channels/ (visited on 04/28/2016).
[33] The MathWorks, Inc. React App. url: https://www.mathworks.
com/help/thingspeak/react-app.html (visited on 04/29/2016).
[34] The MathWorks, Inc. TalkBack App. url: https://www.mathworks.
com/help/thingspeak/talkback-app.html (visited on 04/29/2016).
[35] The MathWorks, Inc. ThingSpeak Community Blog. url: http :
//community.thingspeak.com/2016/04/thingview- mobile-
app-to-see-thingspeak-charts-on-android-devices/ (vis-
ited on 04/29/2016).
[36] The MathWorks, Inc. Channel Settings. url: https://www.mathworks.
com / help / thingspeak / channel - settings . html (visited on
04/29/2016).
[37] 1st ed. Amazon Web Services, Inc., 2016. url: http : / / docs .
aws.amazon.com/iot/latest/developerguide/iot- dg.pdf
(visited on 04/30/2016).
[38] Amazon Web Services, Inc. AWS IoT console. url: https : / /
console.aws.amazon.com/iot/ (visited on 04/12/2016).
[39] Amazon Web Services, Inc. AWS Global Infrastructure. url: https:
//aws.amazon.com/about-aws/global-infrastructure/ (vis-
ited on 05/05/2016).
[40] Amazon Web Services, Inc. How the AWS IoT Platform Works. url:
https : / / aws . amazon . com / iot / how - it - works/ (visited on
05/18/2016).
[41] Amazon Web Services, Inc. AWS IoT Pricing. url: https://aws.
amazon.com/iot/pricing/ (visited on 04/29/2016).
[42] Amazon Web Services, Inc. AWS Educate. url: https : / / aws .
amazon.com/education/awseducate/ (visited on 04/31/2016).
[43] D. Cooper et al. Internet X.509 Public Key Infrastructure Certificate.
May 2008. url: https://tools.ietf.org/pdf/rfc5280.pdf.
[44] Amazon Web Services, Inc. Signature Version 4 Signing Process.
url: http : / / docs . aws . amazon . com / general / latest / gr /
signature-version-4.html (visited on 05/10/2016).
[45] Zapier Inc. url: https://zapier.com/ (visited on 02/12/2016).
[46] K. Baczkowicz. mqtt-spy. https://kamilfb.github.io/mqtt-spy/.
2016.
41
BIBLIOGRAPHY
[47] A. Banks and R. Gupta. MQTT Version 3.1.1 OASIS Standard.

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-
os.html. Oct. 2014. (Visited on 05/18/2016).
[48] M. H. Amaran et al. “A Comparison of Lightweight Communica-
tion Protocols in Robotic Applications”. In: Procedia Computer Sci-
ence 76 (2015). 2015 {IEEE} International Symposium on Robotics
and Intelligent Sensors (IEEE IRIS2015), pp. 400–405. issn: 1877-
0509. doi: http://dx.doi.org/10.1016/j.procs.2015.12.318.
url: http://www.sciencedirect.com/science/article/pii/
S1877050915038193.
42
A MQTT protocol
MQ Telemetry Transport (MQTT) [47] is a machine-to-machine (M2M)/IoT
lightweight connectivity protocol. “It was formerly developed by IBM and
then released to the open source community. The latest standard for MQTT
as of writing is version 3.1.1 and standardized by OASIS. MQTT operates
based on publish-subscribe mechanism where a subscriber subscribes to a
topic published by a publisher to the broker.
To communicate, a publisher must first connect to the broker. After
successful connection denoted by a reply from broker, the publisher must then
register itself to the broker. After successful registration, the client publishes
the topic and message to the broker. To end the session a disconnect packet is
sent to the broker. If there are no disconnect packets or any packet received by
the broker, the publisher will be regarded as disconnected after a predefined
time. Registration is only done once. Subsequent connection only need a
connect packet followed by the publish message.
Whenever a publish message to a topic was sent, message will be sent to
all subscribers of that particular topic by the broker. Communication between
publishers and subscribers of a specific topic only occur through the broker.
Hence peer to peer communication between subscriber and publisher in
MQTT is impossible.
For reliability, MQTT offers three types of modes which are called Quality
of Service (QoS). QoS 0 mode sends a packet only one time without requiring
confirmation messages or ACK. QoS 1 mode ensures that the message is
delivered at least once by requiring an acknowledgement (ACK). QoS 2 mode
guarantees that the message is delivered exactly once. For MQTT, TCP is
used as the transport protocol. This means that even when QoS 0, which does
not require MQTT ACK responses, is used, TCP still provides TCP ACK for
every sent package.” [48]
The AWS IoT message broker implementation is based on MQTT
version 3.1.1 with some differences that are described in [37]. AWS IoT
also supports MQTT over the WebSocket protocol to enable commu-
nication of browser-based and remote applications with connected
devices. [37]
43
B List of attachments
Electronic attachments can be found in the thesis archive of the In-
formation System of Masaryk University. They are included in the
attachments.zip file with the following structure:
• AWS_IoT – JavaScript scripts for simulation of sensor nodes used

in the tested scenarios and additional information for setting up
the platform
• ThingSpeak – Python scripts for creating channels and simula-

tion of sensor nodes used in the tested scenarios, and MATLAB
source codes used in the MATLAB Analysis and MATLAB Visu-
alizations apps
• ThingSpeak_testbed – CSV files containing data from the labo-

ratory testbed and MATLAB source codes used in the MATLAB
Analysis and MATLAB Visualizations apps for their analysis
and visualizations
• Xively – Python scripts for activation and simulation of sensor

nodes used in the tested scenarios
44

Web Based Iot - Mini Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Based Iot - Mini Project

Uploaded by

Copyright:

Available Formats

Masaryk University

The web-based platforms for

Brno, Spring 2016

Advisor: RNDr. Petr Švenda, Ph.D.

2 Platforms on the market and their features 2

3 A review of the selected platforms 9

4 The tested scenarios 23

5 Results of tested scenarios 25

6 ThingSpeak and a testbed experiment 36

maintenance of the infrastructure. SaaS platforms are typically cen-

2.4 Development support

1. See Appendix A for a brief introduction of the MQTT protocol.

very large, scalability of a platform becomes a critical issue. Platforms

Authentication and authorization

4. An open standard for authorization. See http://oauth.net/.

between the platform endpoints to be encrypted over the Transport

a response to certain changes in collected data, platforms can invoke

2.7.3 Data analysis

Cloud based analysys of stored or real time data is another example of

2.7.4 Data storage

Advantageous feature can be cloud based data storage that allows

exporting (ThingSpeak, AWS IoT) of data from IoT nodes in Extensible

2.8 Overview table

Platform a) Beta b) OS c) Lib./SDK’s d) REST API e) MQTT

Table 2.1: A representative sample of web-based IoT platforms.

present. It is also possible to manually add location data to a device, if

Pricing and limitations

the type of an operation, Xively accepts three formats in which data

2. A Keyed-hash Message Authentication Code over a Secure Hash Algorithm 1.

Xively supports secure authorization of third-party applications

• Channel – The primary element of ThingSpeak activity, which

• Field – A Field stores data uploaded to a channel. It could be

Visualization and analysis

react to incoming tweets (TweetControl app), or send a new tweet as

TimeControl app The TimeControl app triggers other ThingSpeak

ThingHTTP app The ThingHTTP app enables communication of

3.3 AWS IoT

• Thing – Things are applications, connected devices, or physical

• Thing Registry – Also referred to as the Device Registry. Orga-

• Thing shadow – Also referred to as a device shadow. “Device

• Message broker – It is a publish/subscribe broker service that

• Amazon DynamoDB, for writing data to managed NoSQL databases.

• Amazon Elasticsearch, for data searching, analytics, and visual-

• Amazon Kinesis, for real-time processing of streaming data.

• Amazon Simple Storage Service (S3), for data storage.

• Amazon Simple Notification Service (SNS), for sending notifica-

• Amazon Simple Queue Service (SQS), for queuing data to be

• Amazon Lambda, for executing custom code in Java, Node.js or

Pricing and limits

in the certificate. X.509 certificates are issued by a trusted entity called a

1. Let's have 3 temperature sensors in 3 different rooms. Each sen-

2. Let's have 3 nodes in 3 different rooms. Each node has 3 sensors:

3. Let's have 15 temperature sensors distributed around an office

The fourth scenario adds more complex requirements for triggering an

4. Let's have 30 nodes with temperature sensors and humidity sen-

Scenario 1 Scenario 2 Scenario 3 Scenario 4

Table 5.1: Results of tested scenarios.

storing temperature data. This development device served us as a pro-

Figure 5.1: Raw datapoints from a single Xively channel.

Figure 5.2: A graph from the Xively’s GitHub web application.

updating the data, we monitored some lost messages, meaning that

Figure 5.3: A plot generated with the MATLAB Visualizations app.

correctly for analysis of incoming data, including processing histor-