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.