Node-RED Interoperability Test

!
1
@BorisAdryan - April 2014
Data Storage & Visualisation in the Internet of Things
Node-RED Interoperability Test

!
Summary
A significant proportion of developments in the Internet of Things (IoT) is driven by non-technical innovators and ambitious hobbyists.

Node-RED targets this audience and offers a widely used rapid prototyping platform for IoT data plumbing on the basis of JavaScript.

Data platforms for the IoT provide storage facilities and value in the form of visualisation & analytics to business and end users alike.

This report details how Node-RED connects to 11 different platforms and what additional services these provide.

2
carriots
Emoncms
Evrythng
eyehub
exosite
Geras
opensensors.IO
Tinamous
Thinkspeak
ubidots
xively
Ease-of-use
with Node-RED
Documentation
of API and I/O
Functionality
Visualisation
&
Analytics

Introduction
One significant advantage of the Internet of Things is the worldwide availability of one’s things’ data. That is, no matter where you are and
where your thing is, if you’re both connected to the internet, you can learn from it. Whatever your thing is, in many cases you can learn some
sort of numerical data from it: Let it be a temperature, energy consumption or cups of coffee left.

Humans are visual animals and most people prefer to see their numbers in
a historical context. For any value we see, we implicitly compare it: Is it low? Is
it high? Is it higher on average than four weeks ago? Seeing the temporal
development of your data in a graph is often essential to making sense of it and
to informed decision making. Even the famous statistician John Tukey promoted
the thought of explorative data analysis before embarking on more sophisticated
analyses.

So what options are there? When we installed an internet-connected freezer,
we followed a recommendation for the matplotlib framework in Python to create
a graph. While it is totally possible to make powerful visualisations in this or
other scripting languages and make those available on the internet, without a lot
of coding they are static images and don’t offer any interactivity.

This is where colourful names such as Carriots, Emoncms, Evrythng, Eyehub,
Exosite, Geras, Opensensors, Tinamous, Thinkspeak, Ubibots or Xively
come into play. The alternative to coding your own graphing solution for sensor
data is using an IoT platform (sometimes referred to as hub or silo) that takes data from you, stores it in the cloud, and provides interactive
display and ideally analysis of your information. This user experience is one of the key differences between the IoT and human interaction in
comparison to machine-to-machine (M2M) applications, as the graphical representation and interactivity is irrelevant for the latter.

!
3
A graph generated with matplotlib in Python.

!
The Node-RED Interoperability Test
We have chosen Node-RED (http://nodered.org) as our perceived game changer for many IoT developments that are not driven by
programmers and engineers. In the most simple terms, Node-RED is a graphical user interface that allows the creation of workflows for IoT
data plumbing. By connecting simple components with defined functionality (the “nodes”), it is possibly to write applications that take data
from one source (e.g. a sensor, a website, a Twitter account) and publish or act on this information in many cases without any programming.

If programming should be necessary, Node-RED fully builds on node.js and allows the incorporation of JavaScript code. As such it is very
accessible even for innovators with limited previous programming experience. While Node-RED can be installed on any computer system that
supports node.js, it has been developed particularly with the Raspberry Pi in mind. This implies that a large proportion of Node-RED users
may have only a superficial understanding of web technologies - a potential constraint for grass roots IoT development.

4

Here we are trying to see how IoT platforms facilitate access to their services, in what form they are provided and how much support they are
offering. We chose a common scenario of Raspberry Pi usage: The AirPi weather station is a hardware shield for the GPIO, whose default
software stores and shows weather data on Xively (formerly also known as Cosm/Pachube, an originally free service that supported the
AirPi.es project). It is not unreasonable to assume that it reflects what many hobby users consider “their IoT”.

The IoT platform market has grown enormously over the past few months and there are now more than a dozen players round (many of which
are included in our test), and there is possibly an even bigger number of services that are exclusively advertised and available to paying
customers (e.g. ThingWorx or Gemalto). What are their unique selling points? Most of these platforms have their own niche and follow
different conceptual models. So which one should you use? Which one is easy to use with Node-RED? And what sort of visualisation and
analytics do they offer?

In this review, we’re trying to compare the platforms for one particular use case: Which IoT platform works best with weather data
served from a Raspberry Pi AirPi shield using the Node-RED workflow we had published earlier?
!
Technical Background
Node-RED supports a range of input options. For interactions with the AirPi shield, we are using a modified version of their Python scripts that
broadcasts the measurements via UDP. The Node-RED workflow monitors the incoming traffic and can restart the Raspberry Pi if no
measurements have been received for several minutes, or by default restarts the system once a night. The workflow also coordinates the
setup of the Python scripts.

Node-RED can communicate with the outside world using TCP, UDP, HTTP, MQTT and can provide sockets. Some of the platforms we are
looking at support MQTT (http://mqtt.org), a simple and unified Message Queue Telemetry Transport protocol that has been developed with
IoT applications in mind. Others provide RESTful APIs that can be used with HTTP requests. These are more flexible and some APIs even
allow powerful manipulations of the data structures, at the cost of solution-specific modifications to HTTP header structure and message
body.

5

!
!
The Platforms
We have accounts and login details for the services listed above. These range from hobby projects to commercial IoT products of companies
with a large portfolio of IT solutions. We further looked at onion.io and ThingWorx. Unfortunately we were unable to include onion.io into our
test as it currently requires a library for the Arduino; a forum post indicates C/Python libraries for the Raspberry Pi are under development but
we couldn’t ﬁnd any REST API. We had contact with ThingWorx and Gemalto, who both frequently sport powerfully looking dashboards at IoT
conferences, but despite verbal agreements from representatives and various emails we were unable to obtain access to these sites.

6
Ease-of-use
with Node-RED
Documentation
of API and I/O
Functionality
Visualisation
&
Analytics
carriots
Emoncms
Evrythng
eyehub
exosite
Geras
opensensors.IO
Tinamous
Thinkspeak
ubidots
xively

Money Talks
There is no free lunch. Most if not all IoT platform providers would like to make a living through their services. However, while commercial
usage of some can cost you a signiﬁcant amount of money, developers and hobbyists can usually get away with free accounts.

!
Note that the terms and conditions of your free account may change, and that undocumented limits may exist for non-paying customers.

The reasonable limitations on API calls per minute for some of the platforms has implications for our test scenario. While our AirPi outputs
data from two diﬀerent temperature sensors, barometric pressure, humidity, light level, volume, and relative CO and NO2 levels every 15
seconds (i.e. 4x 8 = 32 measurements per minute), for those platforms we aggregate the measurements for the submission in a single API call.

CARRIOTS free, limits on number of devices and incoming connections
EMONCMS free, but asking for donations and a reasonable post rate limit (5-10sec)
EVRYTHNG free for developers
EYEHUB free for developers
EXOSITE free for developers, limited on number of devices and users
GERAS free for developers
OPENSENSORS.IO free by agreeing to share the measurements with the public
TINAMOUS free, limits on number of devices and users
THINKSPEAK free, “a rate limit of an update per channel every 15 seconds”
UBIDOTS free, 30,000 “dots” included (could be data transmissions, triggered emails, etc.)
XIVELY free for developers, limited to 25 API calls per minute
7

Architectural Differences & Security
How is the measurement of the physical device represented? There are two extremes that we are briefly discussing:

We have seen the most device-agnostic and generally applicable data model at 1248.io’s Geras platform, where each sensor can be
considered the final node in a directory structure and the measurements can be published via MQTT as time-dependent entries to, for
example, /instrument/sensor or any other logical path. The Geras web interface allows the aggregation of path elements and it is possible to
gain an overview of all instruments or all sensors by browsing to the appropriate level in the hierarchy.

This simplicity has advantages and disadvantages. While the directory structure is established ad hoc simply by posting to a directory entry
(so writing a value to /AirPi/humidity creates both the instrument and the sensor on Geras if they haven’t existed before), there is no policy for
the granularity of directory structure. It is entirely feasible to maintain /AirPi/humidity and a different device /weather/AirPi/humidity at the
same time, with all the implications for redundancy and fragmentation.

The opposite is true for platforms with a complex device model. In
these cases, measurements are tied to sensors, which are mounted on
devices, based at locations, maintained by device owners in a detailed
network of relationships. Often the devices have then to be explicitly
created before Node-RED can write to them via MQTT or RESTful
APIs. This can either be done using different sets of API commands via
HTTP requests, or directly on the web sites of the IoT platform.

In most cases Node-RED users can get away with just one password
(API key or device key), but there are notable exceptions where
privileges are fine-grained and manipulations require different keys that
are accessible through the platforms’ user settings.

8
The data model behind the Eyehub API.

We receive data from the AirPi Python scripts via recUDP. The splitMessage node separates our measurements into {topic: sensor name,
payload: measurement} pairs. These are then published by reformatting them for RESTful API calls (via feedXXX function and http request
nodes) or by by adding path information for MQTT transmission. Depending on the platform, collectMessages nodes prepare data for bulk
transmission.

The flow components in the upper right (TheServer) prepare data for display on an internal website and those in the lower left (onStartup) are
for general system maintenance.

!
Documentation and Ease-of-Use with Node-RED
We believe that the majority of Node-RED users are not necessarily experienced web developers. While it is clear that the IoT platforms
require some sort of authentication to allow users access and some sort of address system to assign a measured value to a sensor, there are
many ways how this information can be transmitted. The exact How-to should be described in a short and concise documentation. In the
following, sections, we describe our tour-de-force of connecting Node-RED with the various platforms.

While MQTT transmissions are standardised, there are three possible entry points for transmitting information as part of a HTTP request:

1. as part of the URL, as exemplified in the EmonCMS or Thingspeak transmission, where password, sensor name and measurement are
part of the very internet address.

2. as part of the HTTP header, as seen in the majority of platforms for authentication purposes.

3. as part of the HTTP body, where we should point out that some but not all platforms insist in the definition of the Content-Length
parameter in the header, as otherwise contents of the body are not correctly transmitted - this seemed to be highly platform specific.

!
10

Another issue that we discovered as potentially tedious is how our sensors names are represented on the various platforms. While the
majority of platforms allowed the use of our actual sensor name, Tinamous, Thingspeak and Ubidots require a mapping to their field identifiers
(either broadly called field0..field8, or variable IDs in the case of Ubidots).

The precise notation of the sensor reads is also surprisingly diverse. Most platforms adhere to some sort of JSON format
{“sensor”:”measurement”}, but virtually any deviation from this pattern such as { [{sensor = “measurement” }] } etc seems to exist. We also
identified a case with Tinamous where node.js JSON.stringify produced a correctly looking string, but the platform would only accept the
input when we constructed the string manually.

The following list summarises the code we have used for data transfer out of Node-RED. This is best understood in reference to the figure on
page 9.

!
11

CARRIOTS. The control panel of Carriots is a complex beast. Their API documentation is openly accessible at
https://www.carriots.com/documentation and it took us a while to ﬁgure out what exactly is needed to create
our device (the AirPi) and its sensors (here called Data streams).

The API key is available in your user control panel. We created our device manually on the website, but the
data streams are created dynamically on the basis of the data object, which is a JSON construct with sensor
name and measurement.

!
In the feedCarriots function node:
msg.url = "http://api.carriots.com/streams";
!
var stuff = "{ "+msg.topic+" : ""+msg.payload+""}";
msg.payload = JSON.stringify({
protocol: "v1",
at: "now",
device: "AirPi@adryan.adryan",
data: stuff
});
!
var alength = msg.payload.length;
!
msg.headers = {
'User-Agent' : 'AirPi@adryan.adryan',
'Content-Type' : 'application/json',
'carriots.apikey' : '9ce9e9cXXXXXXXXXXXXXXXXXXXX0923720be050ee3d0bd0023dacf14716fb869',
'Content-Length' : alength
}
!
msg.method = "POST";
!
return msg;
!
12

EMONCMS. Emoncms is an open-source energy management software that provides features that are useful in a
wider range of IoT application. The open documentation is extensive, but also details (for us unnecessary details)
building the Emoncms for your own server and such. Finding the relevant API information was a challenge, but
fortunately, feeding data into their platform is not: A JSON object as part of the URL generates the sensor ﬁeld in
the database and populates it.

Your API key is available in your user settings at http://emoncms.org/user/view.

In the feedEmonCMS function node:
msg.url = “http://emoncms.org/input/post.json? json={“+msg.topic+":"+msg.payload+"} &apikey=27bb0faeXXXXXXXXXXXXXXXc387c5bb3”;
return msg;
!
!
EVRYTHNG. The Evrythng Developer Resources (https://dev.evrythng.com/documentation) give well-structured
insight into architecture of the platform, where the most important component are your THNGs, which can have
properties (i.e. your sensor measurements). Evrythng is not necessarily built with hobbyist users in mind and there
are plenty of API functions for product management and the like that we didn’t need.

THNGs can be created through the API or on the website, but this needs to happen before populating them with
properties. Importantly, properties are created for your THNG on the ﬂy while you submit data to them.

Your API end point contains a unique ID (the THNG ID), and authorisation requires a token, which is available from your account at https://
dev.evrythng.com/account/token.
!
In the feedEVRYTHNG function node:
msg.url = "https://api.evrythng.com/thngs/534XXXXXXXXXXXXXXXf821d7/properties";
13

!
msg.payload = "[{ "key" : ""+msg.topic+"", "value" : ""+msg.payload+""}]";
!
!
msg.headers = {
'Authorization' : 'tuyvvWMboGc3AxNAxjj4GPEORuYpRro1t1dunI0QxN7m6XXXXXXXXXXXXXXXXXXXXlPNdngo9ukMaA',
}
!
!
return msg;
!
!
EYEHUB. Eyehub is by far the most complex system we have included in this test (the exemplary figure on page 8
is from their API documentation, which is more than 150 pages long). Eyehub operates a public section on Github,
but access to the system requires an invitation.

It took us a while on their web tool https://hub.flexeye.com to find the appropriate entry point: We manually created
a Device Manager (AirPi_DM), to which we then assigned our AirPi as Device (automatically receiving a Device ID,
here: Device_1997, that’s required for the API call), and the Sub Devices (our sensors - which we named according
to the incoming topic). The documentation describes how to create Manager and Devices via the API, but we needed the visual context of the
website to understand this logic.

As for the authentication password that is required in the HTTP header: We remember it’s base64 encoded, but we can’t remember how and
where we retrieved it. That much for complexity!

14

!
In the feedEyehub function node:
msg.url = “https://hub.flexeye.com/v1/iot_Default/dms/AirPi_DM/devices/Device_1997/subDevices/"+msg.topic+"/events";
!
msg.payload = JSON.stringify({"payload": msg.payload, "type": 1.0});
!
!
msg.headers = {
'Authorization' : 'Basic YmFkcnlhXXXXXXXXXX3MjFxYXo=',
};
!
!
return msg;
!
!
!
EXOSITE. Exosite maintains public API documentation on Github. It’s not extremely well structured, but https://github.com/exosite/docs
contains a short straightforward description how to post data points to their platform.

Devices are created on the website (the dialogue also mentions your device identifier CIK, which is needed for
authentication). Sensors were created on the fly while posting data to them.

In the feedExosite function node:
msg.url = "http://m2.exosite.com/onep:v1/stack/alias";
!
msg.payload = msg.topic+"="+msg.payload;
15

!
!
msg.headers = {
'X-Exosite-CIK': 'ac1696XXXXXXXXXXXXXXXXXXXXbbdebd657b799f',
'Content-Type' : 'application/x-www-form-urlencoded; charset=utf-8',
'Accept' : 'application/xhtml+xml',
};
!
!
return msg;
!
GERAS. 1248.io have a fairly concise API for communication with Geras. Unfortunately, one has to be registered to
gain access to the documentation. However, most of their examples are then easy to use, as in fact all user
credentials in the examples are adjusted to the current user. Publishing data via MQTT is encouraged, using their
geras.1248.io server on port 1883 and using the data channel (e.g. “/AirPi/Temperature”) as topic in the Node-RED
MQTT node, and your personal key as user name. It is worth mentioning that once a data channel is present in the
database, one can automatically generate JSON code for import into Node-RED for future applications.

In the addPath function node:
msg.topic = "/AirPi/"+msg.topic;
msg.payload = msg.payload;
!
return msg;
!
MQTT settings:
!
Broker: geras.1248.io
16

Port: 1883
Username: your Master API key from http://geras.1248.io/user/settings
!!!
OPENSENSORS.IO The Opensensors.IO project is currently in pre-beta and access is by invitation only. Their “Getting Started” guide is a
simple description of the MQTT interface and help is provided mostly in form of the command line parameters one
would use with mosquitto. Topic names take the form of yourusername/devicename/sensorname. In contrast to the
other platforms that support MQTT in our test, Opensensors.IO make use of the client ID to authorise connections.
Care has to be taken when creating a new device in the account settings: Your device password will be displayed
once, and only once, when that device is created. If you miss taking note of it, you will have to create the device
again. From within the device, one has to create the topic for each sensor manually before submitting data to it.

!
In the addPath node:
msg.topic = "boris/AirPi2.0/"+msg.topic;
msg.payload = msg.payload;
!
return msg;
!
MQTT settings:
!
Broker: opensensors.io
Port: 1883
Client ID: YOUR DEVICE CLIENT ID
Username: YOUR LOGIN/USER NAME
Password: YOUR DEVICE PASSWORD
!
!
!
17

TINAMOUS. Tinamous haven an open API documentation at https://tinamous.com/ApiDocs. Submitting
measurements is easy, provided that one has defined a device and appropriate data fields. This is possible via the
API, but we found the GUI at http://yourusername.tinamous.com more convenient when first getting to grips with
this platform. The data fields are labelled Field1..12, and we perceive this as a potential limitation for some users
with more sensors on their device. While it is possible to submit one sensor reading at the time, this has to be
done through the concept of “channels”, something which we found not extensively documented and therefore
resorted to collating measurements before invoking the API. Tinamous offer a wizard on their website that
generates the http request header including the authorisation token.

In the collateMessages node:
var field = "";
switch(msg.topic) {
case "BMPTemperature":
field = "Field1";
break;
case "DHTTemperature":
field = "Field2";
break;
…
context.buff = context.buff || "";
context.count = context.count || 0;
!
if (msg.topic != "purge") {
if (context.buff.length > 0) {
context.buff = context.buff+", ""+field+"":""+msg.payload+""";
} else {
context.buff = """+field+"":""+msg.payload+""";
}
context.count += 1;
}
if (context.count == 8 || (msg.payload=="purge" && context.count >= 1)) {
msg.topic="";
msg.payload = context.buff;
18

context.buff = "";
context.count = 0;
return msg;
}
return null;
!
And in the feedTinamous call node:
msg.url = "https://adryan.Tinamous.com/api/v1/Measurements";
msg.payload = "{"Channel": 0,"+msg.payload+","Lite": false}";
!
!
msg.headers = {
'Authorization' : 'Basic QWlyXXXXXXXXXXJlcnJ5',
}
!
!
return msg;
!!
THINGSPEAK. Thingspeak channels are documented openly at https://thingspeak.com/docs/channels#channels. We
created our AirPi on their website, where we also added the different sensors. These got assigned data fields
field1..8, a name which has to be used through the API. The Channel View also provides access to the API keys that
19

are needed to update or view the data. There are multiple places to learn about the API, and we found http://community.thingspeak.com/
documentation/api/ one of the better descriptions how to use the platform.

In the collateMessage node:
var field = "";
switch(msg.topic) {
field = "field1";
break;
field = "field2";
break;
…
}
!
!
context.buff = context.buff+"&"+field+"="+msg.payload;
} else {
context.buff = field+"="+msg.payload;
}
context.count += 1;
}
msg.topic="";
context.buff = "";
context.count = 0;
return msg;
}
return null;
20

!
In the API call node:
!
msg.url = "http://api.thingspeak.com/update?key=TUQOXXXXXXXXXXTZ2&"+msg.payload;
return msg;
!
UBIDOTS. Ubidots feature a Raspberry Pi on their home page and they have an extensive public documentation
section: http://ubidots.com/docs. The documentation of their RESTful API is extensive and has many examples
that work directly from the command line.

Ubidots know a Data Source (our AirPi) and Variables (our sensors). The sensors need to be pre-deﬁned, either on
their website or through API commands that are submitted through HTTP POST calls. Each sensor is getting
assigned a 24 character variable ID, to which the POST requests have access if they know the authentication
token, which are managed at http://app.ubidots.com/userdata/api.

!
In the feedUbidots function node:
var varid = "";
switch(msg.topic) {
varid = "5336c5acXXXXXXXb639aa9ba";
break;
varid = "5336f998XXXXXXX2c45a81b4";
break;
….
}
21

!
msg.url = "http://things.ubidots.com/api/v1.6/variables/"+varid+"/values";
msg.headers = {
'X-Auth-Token' : 'fxh0fCSY6V82XXXXXXXXXXXXXXXngBvPZPByuCJiqWLdsAWiMzrhTQHjUtPF'
}
msg.payload = "{"value":"+msg.payload+"}";
!
return msg;
!

XIVELY. Xively operates a Developer Center (https://xively.com/dev), and once you choose a Development Device
(here: our AirPi), you can see the Device Key needed to deposit data in your “data channels” (i.e. one channel per
type of measurement). Note that you need to create your channels manually (i.e. either using the website or the
API) before submitting any measurements - this is something that caused us some confusion in the beginning. The
API Documentation (https://xively.com/dev/docs/api) is very clear and has a few examples how the RESTful
communication to api.xively.com works. While it would be possible to create a JSON, XML or CSV object and
submit that via a Node-RED http request, the MQTT node can encapsulate the information and send it to /v2/feeds/YOUR FEED ID.csv to
api.xively.com on port 1883, using your device key as user name.

In the collectMessages function node:
!
context.buff = context.buff+"n"+msg.topic+", "+msg.payload;
22

} else {
context.buff = msg.topic+", "+msg.payload;
}
context.count += 1;
}
msg.topic="";
context.buff = "";
context.count = 0;
return msg;
}
return null;
!
In the MQTT settings:
Broker: api.xively.com
Port: 1883
Username: YOUR DEVICE API KEY
Topic: /v2/feeds/YOUR FEED ID.csv
!
23

Visualisation, Analytics & Functions
The primary motivator for our test was the search for a convenient platform for visualisation of IoT data. We further looked for useful tools to
analyse our data, or if that was not possible, what options we had to share our information with others or how to download whatever we
had stored. A systematic assessment is beyond the scope of this document, but we are trying to give our readers some insight into what is
currently in store for them. What we found most disappointing at this stage was the lack of meaningful data analytics on all of the IoT
platforms.

!
CARRIOTS. Carriots have an extensive Data Management section on their web interface at https://cpanel.carriots.com/data-management. We
were pleased to see a Data Export service that lets you download slices of your data in JSON, XML and CSV formats. A wizard allows the
configuration of a data stream that can post your data as a JSON object at a specified URL. Another wizard takes care of visualisation:
However, in our hands, it did not produce any useful output. We believe that the graphics API, which is documented at https://
www.carriots.com/documentation/graphs, may be your best bet for visualisation. We perceived this route as ‘too involved’ for our quick test.

!
EMONCMS. It took us a moment to understand the logic behind the EmonCMS
Dashboard. In fact, close to giving up, we discovered that measurements need
to be translated into “feeds” (of which the configuration happens in the Input
arena). Those feeds might be your raw data, but also time averaged means or
your data where an arithmetic operation has been performed on the data are
available. Feeds can be downloaded for defined intervals and time slices. Feeds
further provide the input for graphs, where EmonCMS offers a wide selection of
common types. Different graphs and widgets can be arranged on a dashboard,
which can be shared with others.

24

EVRYTHNG. As in the case of their competitor Carriots, the power of Evrythng comes packaged in complex APIs that allow the creation of
attractive front-end applications or retrieving any of your data back. For the purposes of our test, we focussed on what we could get on
screen without much further development work. In your THNG section, a list of all properties (here: the sensors) is available. The click on any
of the properties brings up a vanilla graph with your sensor readings - this is a static display without any on-the-ﬂy updates. These graphs can
be printed or downloaded in various graphic formats. We couldn’t see any option for sharing these images with the public.

EYEHUB. At this stage, Eyehub does not oﬀer any data retrieval or visualisation
through their web interface. We have been told that a D3.js based library for
custom-designed graphs is in development, but for now, without using the
really extensive API, the Eyehub looks more like a data one-way street.

!
EXOSITE. Exosite have a very intuitive way of creating Dashboards from your
data. They provide a wide selection of graphs, some of which can take more
than one measurement and lend themselves for comparing data. As with most
other sites, axis scaling is not a particular strength of Exosite and we missed
logarithmic scaling and better interactivity with the graphs. However, amongst
the blind, the deaf is king and therefore our criticism shouldn’t be taken to
harshly. It is easily possible to declare a dashboard as public and it can then be
viewed through a URL.

The Scripts section of Exosite is a possible entry point for exporting your data -
if you know how to write code in Lua.

!
25

GERAS. 1248.io’s Geras provides a plain directory structure to navigate your
devices and sensors. On the device level, a tabular view with your sensor
names, a thumbnail with a graph of the past 12 hours and the current value are
displayed. This view also shows little Node-RED icons that link to code that one
can use for MQTT-based in- and output. Geras allows command line or
programmatic access to all stored data. This is simplified to an extent that a simple copy & paste to a terminal console retrieved all of our
temperature data. Clicking on a sensor calls up a larger graph. The graphical interface that is available for each sensor spits out a warning if
this would require more than 5k data points, but in principle any time frame can be defined. Data can be shown as rolling averages or raw
measurements. Those graphs cannot be shared.

!
OPENSENSORS.IO do not provide any visualisation at the moment. Live data sharing is the key purpose of this platform at the moment, and
we understand it as a dispatcher of MQTT-based feeds for your data. We’ve been told that super analytics goodness [...] including all the usual
real time charting is going to arrive at the end of May.

!
TINAMOUS. Tinamous wants to be understood as a Twitter for the IoT. Their
graphing solution reminded us much of Evrythng, in fact we believe that both
platforms use the same library with the same functionality (e.g. saving of
images). Unfortunately, the axis are pre-defined and just focus on the past four
or so hours. Data retrieval seems possible through the API.

!
THINGSPEAK. Thingspeak have an intuitive interface that allows the creation
of live graphs and provides simple data export, either as file export or an online
API. We were very pleased with a many options that are available for
customisation of the graphs: The number of past data points or a time frame
26

can be defined for the temporal axis, and the unit axis can either adjust dynamically or be set to defined min and max values. The settings for
each graph (column, bar, line) also allow to specify whether data is to be shown as raw value, as average, or have an arithmetic operation
applied to it. Creating dashboards with multiple of these graphs is easily possible, so is their sharing on the internet with a defined URL.

UBIDOTS. Ubidots easily wins the prize for the most striking ‘on first sight’
display of our data. The status of our AirPi greets us with our recent readings
shown in large letters (unfortunately with a lack if sensible scaling in some
cases). The overall impression remains good, but we found the graphs that
are accessible through clicking on these sensor images slightly inflexible.
There is no sensible scaling for the measurements, and zooming on the time
frame was a little bit hit and miss with the sliders that appear underneath the
graph. While the currently displayed data can be downloaded in CSV format
using the GUI, your best bet for large-scale retrieval of your information may
be the API.

XIVELY. Xively probably offers the most convenient way to graphically browse
through your data. The data can be viewed with varying temporal resolutions
of 5 min to 1 hour for raw data points, or with average values for longer
intervals of up to 3 months, and by navigating using the prominent left and
right buttons underneath the graphs. By default each of your feeds also has a
public URL for viewing the data, which is quite similar to your private view of
the data except it lacks API key information. Bulk download of historical data
is only possible through the API.
!
27

Concluding Remarks
With the notable exception of arithmetic operations on incoming data a few of the platforms (EmonCMS, Thingspeak) or multiple line graphs
and scatterplots in Ubidots, not a single platform could convince us in terms of analytics. We missed histograms, box plots or even
simple tables informing us of the basic descriptive statistics for our measurements. This is where all of them need to do better!

If you need graphs for your own website, Ubidots and Thingspeak provide you with iFrame code that one can simply use for plug & play.
Alternatively, Eyehub are promising D3.js based graphs for the near future, and Carriots also have examples in their API documentation how
to bring their graphical goodness to your website.

In cases where fancy dashboards are desirable, have a look at EmonCMS, Exosite and Ubidots.

When it comes to the simple display of numerical data, not a single platform could take home the cup. While we liked Xively’s way of
navigating through historical data, we were not happy with the lack of scaling that is essential when looking at sensor data which follows a
logarithmic scale. Also, we would have hoped for better outlier detection in all of the tools. We also quite liked Geras’ tabular summary of data
including the thumbnail picture, or the quite interactive way that Thingspeak have with their widgets.

We were positively surprised that most platforms export historical data, although using an API to do so may not be everyone’s taste.

!
Acknowledgements
Boris Adryan (@BorisAdryan) wishes to acknowledge the help of Dave Conway-Jones & Nick O’Leary from the Node-RED team (@NodeRED),
as well as all platform providers that granted us free and sometimes early access to their services, and often free email support to resolve
administrative and technical issues. Further comments on this document came from Andy Stanford-Clark (@andysc), Christopher Mobberley
(@hardware_hacks) and Andrew Lindsay (@andrewdlindsay).
28

Node-RED Interoperability Test

More Related Content

What's hot

Viewers also liked

Similar to Node-RED Interoperability Test

More from Boris Adryan

Recently uploaded

Node-RED Interoperability Test