Step One – Parsing the data

This was the easy part; AndySC had already put together a perl script for reading the serial port and doing the necessary parsing.

Step Two – Publishing the data

Again, not much for me to do here as Andy’s script already publishes the data to a set of topics over MQTT.

Step Three – Logging the data

Finally, something for me to do. A couple years ago, I would have joined Andy’s perl script with one of my own, but python is more my thing these days. I already had a piece of python that subscribes to the appropriate topics and posts the temperature values to twitter. It didn’t take much to get the same script to subscribe to the power data and dump it into a MySQL database on the local machine.

The table in the database is a very simple one at the moment; logging the power along with a timestamp. An entry is added to the table for every reading from the meter and having been running for 3 days there are just over 11,000 of them. I’ll have to keep an eye on this to make sure it doesn’t run away with my free disk space.

Step Four – Graphing the data

Roo showed me some stuff he’s been playing with using the Google Chart API. Whilst I generally prefer to roll my own (aka, reinvent the wheel), I couldn’t ignore just how easy it is to produce pretty graphs this way.

Before delving into the API, I needed to decide just what I wanted to produce. As there is such a range of chart types available, there are plenty of interesting things that could be done. Initially, however, I decided to stick with the traditional “power-usage-in-the-last-24-hours” chart.

The API has a limit on the amount of data that can be passed to it. So I needed to find a meaningful way to reduce the 4200 data points generated in 24 hours to around 100 at most. I soon settled on using the average value for each 10 minute period. This loses some resolution in the data, but it still shows the trends.

Generating the averages is a simple question of the right query on the database. With some trial and error, I eventually got to:

select concat(substring(substring(`when`,1,11),9,4),'0'), truncate(avg(`power`),3) from currentcost where `when` > SUBDATE(NOW(), INTERVAL 1 DAY) group by substring(`when`,1,11) order by `when`;

What next?

Chris has started doing some interesting data analysis to see if he can automatically spot ‘events’ on the graph. Will be interesting to see what can be achieved here.

Andy’s twittering house got some linkage last week from both Earth2Tech and Wired Science. They mention the power orb that was written about last year. I really like the idea of an ambient device for displaying this information – another project for the arduino list.

I’m not able to share the exact perl script I use as it does contain some proprietary code that enables us to share the data we’re producing. I can however give you some simple pointers for rolling your own.

The value for $serial_port will depend on your setup. This code assumes you are on a linux box, and are connected via USB. If you are connecting over serial directly, it is more likely to be something like /dev/ttyS0.

hey nick,
visifire is under GPL, what else can one ask for.
regarding silverlight, microsoft is dieing to make it reach every one. currently silverlight supports win & mac. linux will follow soon ( some thing called moonlight)

I have to say that the fact that Google Charts are basically just spitting out PNGs for display makes them far more flexible across a range of devices anyway. Opera Mini on my BlackBerry can cope with that, for instance 🙂

Been playing with this for almost 2 weeks now. Pushed the data into a MySQL table slightly differently to you though as I set time as a timestamp so its more flexible. I can then convert to unix time and do time calcs that way.