!

�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

FunctionalityVisualisation

& 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 find 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

FunctionalityVisualisation

& 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 significant 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 different 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.

Our Node-RED Test Flow

�9

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 figure 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 field 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 fly 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+"\"}]"; !var alength = msg.payload.length; !msg.headers = { 'Content-Type' : 'application/json', 'Authorization' : 'tuyvvWMboGc3AxNAxjj4GPEORuYpRro1t1dunI0QxN7m6XXXXXXXXXXXXXXXXXXXXlPNdngo9ukMaA', 'Content-Length' : alength } !msg.method = "POST"; !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}); !var alength = msg.payload.length; !msg.headers = { 'Authorization' : 'Basic YmFkcnlhXXXXXXXXXX3MjFxYXo=', 'Content-Type' : 'application/json', 'Content-Length' : alength }; !msg.method = "POST"; !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

!var alength = msg.payload.length; !msg.headers = { 'X-Exosite-CIK': 'ac1696XXXXXXXXXXXXXXXXXXXXbbdebd657b799f', 'Content-Type' : 'application/x-www-form-urlencoded; charset=utf-8', 'Accept' : 'application/xhtml+xml', 'Content-Length' : alength }; !msg.method = "POST"; !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\}"; !var alength = msg.payload.length; !msg.headers = { 'Content-Type' : 'application/json', 'Authorization' : 'Basic QWlyXXXXXXXXXXJlcnJ5', 'Content-Length' : alength } !msg.method = "POST"; !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) { 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; 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; msg.method = "POST"; 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-defined, 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) { case "BMPTemperature": varid = "5336c5acXXXXXXXb639aa9ba"; break; case "DHTTemperature": varid = "5336f998XXXXXXX2c45a81b4"; break; …. }

�21

!msg.url = "http://things.ubidots.com/api/v1.6/variables/"+varid+"/values"; msg.headers = { 'Content-Type' : 'application/json', 'X-Auth-Token' : 'fxh0fCSY6V82XXXXXXXXXXXXXXXngBvPZPByuCJiqWLdsAWiMzrhTQHjUtPF' } msg.payload = "{\"value\":"+msg.payload+"}"; msg.method = "POST"; !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 || ""; context.count = context.count || 0; ! if (msg.topic != "purge") { if (context.buff.length > 0) { context.buff = context.buff+"\n"+msg.topic+", "+msg.payload;

�22

} else { context.buff = msg.topic+", "+msg.payload; } context.count += 1; } if (context.count == 8 || (msg.payload=="purge" && context.count >= 1)) { msg.topic=""; msg.payload = context.buff; 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-fly 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 offer 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