INTERNET OF Things Alex Comer Crook Simon Groll Sean Michaels

INTERNET OF Things
Project 3: Participatory Cloud Computing
Alex Comer Crook
Simon Groll
Sean Michaels
Taariq Mullins
Brief
The idea of this Tutorial was to build on the experiences and knowledge gained in the previous two
tutorials. The objective, now that effective data dissemination was taking place, was were we able
to effectively store, use and share this data to participate in a collaborative process to convey
meaningful interpretation of wireless sensor data gathered in the field.
Methodology
We were to gather humidity, temperature and light readings from our environment via our Z1 motes.
The process of collecting this data could be approached in various ways.
These are:
• Reading sensor values from a mote directly connected to the serial port. This can be done
either by use of various programming languages to connect to the serial port and parsing the
data. The parsed data can then be easily inserted into a MySQL database. The other option,
which was the first approach we took in gathering this sensor data, was using picocom
(picocom is a serial port terminal that outputs its values to stdout) to listen to all printed
statements from the mote. This output was then piped into a PHP script which in turn parsed
the text and inserted it into a MySQL database.
• The second method, which was the final approach that we settled on, that could be used in
collecting data was to use the BLIP stack to facilitate IPv6 communication from mote to
gateway and listen for packets being sent from the mote(s) to the gateway.
The advantages of each method can be shown in the table below:
Read from serial
•
•
•
•
•
Read from socket
Connected motes limited to number of
serial ports
One mote per port
Have to run multiple instances of
picocom and PHP parsing script to
interpret data
One mote crash; the mote, picocom and
the parsing script have to be restarted
•
•
Needs BLIP stack to run
If a large dissemination network is in
place, basestation failure causes entire
network to go down
Simpler to implement for rapid
monitoring solution
•
•
•
Scales better
Handles multiple motes more easily
Node failure does not bring down entire
monitoring network
Table 1: Advantages and Disadvantages of mote information collection
The use of picocom was used almost immediately and without delay as this provided us with
immediate access to the data. This was largely decided due to frequent mote crashes and lock ups in
the previous exercises carried out.
printfUART("sensor=1:%d\n", data);
…...
printfUART("sensor=2:%d\n", data);
This outputs data to the stdout which is captured in the following way..
tmullins@mackerel:~/$picocom -b 115200 /dev/ttyUSB0 | php serial.php
…. in serial.php:
$line = trim(fgets(STDIN)); // reads one line from STDIN
This approach though too was ineffective against guarding against mote failure, which we had
attributed to interference. There were frequent crashes and this was causing inconsistencies in the
data whereby the first temperature reading received after rebooting the mote would be zero. We had
at this point an estimated average uptime of 36-40 hours before the mote would crash.
At this point it was decided that a further examination into the causes of the crashes should be
further investigated. It was then that we noticed that the cause most probably arose from race
conditions due to their being two separate timers firing for the collecting of temperature and light
data at the same intervals.
To remedy this one timer was implemented to run at 15 minute intervals, where every 15 minutes
the alternate sensor reading was made. Setting the value for the interval was trivial and so was
implementing the logic in the timer.fired() call.
Data was transmitted by the motes and in turn received by the JAVA application, network unsigned
integers are converted to signed integers which are then parsed and inserted into the MySQL
database. Temperature values were readings given from the ADC. This was calculated to be a 12bit
ADC which gives one 4096 bits. The range of values the sensor can detect go from -40ºC to 125ºC.
This gives a us a total of 165 discreet temperature values.
165
= 0.040283203
4096
This value is then used with the ADC reading to give us a better approximation of the temperature
in degrees Celsius.
Database
Since we all had access to Ubuntu Linux desktop machines, this made it easy for us to setup
MySQL as the database of choice. The following table structure was decided upon:
mysql> describe project3;
+­­­­­­­­­­­­­+­­­­­­­­­­­­­+­­­­­­+­­­­­+­­­­­­­­­­­­­­­­­­­+­­­­­­­+
| Field | Type | Null | Key | Default | Extra |
+­­­­­­­­­­­­­+­­­­­­­­­­­­­+­­­­­­+­­­­­+­­­­­­­­­­­­­­­­­­­+­­­­­­­+
| reading | int(11) | YES | | NULL | |
| sensor_id | int(11) | YES | | NULL | |
| group_id | int(11) | YES | | NULL | |
| location | varchar(50) | YES | | NULL | |
| ipv6address | varchar(50) | YES | | NULL | |
| time | timestamp | NO | | CURRENT_TIMESTAMP | |
+­­­­­­­­­­­­­+­­­­­­­­­­­­­+­­­­­­+­­­­­+­­­­­­­­­­­­­­­­­­­+­­­­­­­+
6 rows in set (0.05 sec)
It was then decided that since this database was the first database created, it would be used as the
community database. There was debate amongst course members about running the community
database on nightmare but this seemed to be disadvantageous as it would require giving out one of
the group member's nightmare database password in order to access the data, thereby compromising
user security. Users were given select and insert permissions on the database only. Since no
transactional history can be stored it is unnecessary to allocate each user unique usernames and
passwords in order to track access.
Interpreting the data:
The data was collected over a period of 11 days at 30 minute intervals per sensor. This gave us quite
a lot of data to play with, but at the same time this data has inconsistencies where the motes
crashed. Corrupted or invalid data was then removed from the database.
The data is displayed in a web page allowing one to view the temperature and sensor data in a
graphical manner. This was accomplished by the use of MySQL, Apache, PHP, jQuery, Flot
(graphic library), HTML and CSS.
Below is a display of the sample output one receives by visiting the project URL:
people.cs.uct.ac.za./~tmullins
Illustration 1: Screenshot of group webpage displaying data
The top left hand side menu allows one to toggle various values on the graph. Clicking on the temp,
light and humidity buttons change the graph by showing or hiding the particular graph.
The humidity data is not real at all and is simply modified light data. This is due to the fact that we
were unable to get the humidity sensors working even with the sample code and instructions
provided by Zolertia. It is shown here simply for demonstrative purposes
Other features included are being able to drag the timeline, zooming into particular measurements
via the middle button as well as double clicking to zoom. Clicking on the community page link will
take you to the community page.
We found this a far more intuitive than creating buttons and drop down selectors to select a time
span or specific graph to view.
Community Page
This page is arguably the most important page of the assignment as it allows us to demonstrate the
power of collaborative computing. What we decided to do was display an environment heat map
displaying intensity values of temperature and lighting. Humidity was not shown since only one
group using Contiki was able to achieve this.
This displays an animated time sequence which shows the temperature and light values changing.
Once the sequence has gone through all the data in the database it loops to the beginning and starts
all from over.
The sequences are animated using a combination of jQuery and the Raphael javascript framework
which allows the user to perform complex SVG animations. This is a really helpful tool as it allows
users it interact with SVG elements in the web space as objects. This is way easier to manage v.s.
performing the same task with an HTML 5 canvas.
Illustration 2: Map displaying heat maps relative to position in lab. Blue dot indicates a higher
floor
Shortcomings
The biggest problem that we ran into when displaying this data in the heat map was that standard
intervals were not used by all the groups. This prevented us from adding a decay to the heat map in
a manner timeous to the delivery of the assignment. This would have allowed us to, over time,
slowly fade nodes that no longer have any data in the database.
This means that when changing from light to temperature animation the old light artefacts still
remain until their temperature values are read in the time sequence and thus overwrite the old data.
This also means that when switching back from temperature to light, group 3 only read temperature
and humidity, resulted in a stale animation staying on the screen indefinitely.
A lack of proper understanding of the assignment by all participants meant that an inordinate
amount of time was spent getting the members up to speed with what needed to be done. This is
also what lead to some members reading in sensor values every second for a period of two days.
These types of iterations really mess up the animations and cause some nasty artefacts to creep into
the jQuery animations.
SVG has limited support on modern browsers. We found that the best implementation of SVG in a
browser is done with Mozilla Firefox. Chrome enjoyed limited success but graphics were not
displayed correctly and some tearing was noticed.