Hohm and Powermeter

The last week has been an interesting one for online energy monitoring. Not content with deprecating Powermeter a few weeks ago, Google decided to properly kill it off. And then, as if to say ‘us too!’ (as they did with the initial launch), Microsoft killed Hohm.

Both these efforts were unsuccessful because the companies that put them out weren’t serious about them. There is a place for experimentation, but if you’re a massive company, even your small experiments seem larger than other people’s entire companies. By half-heartedly grabbing the attention around energy monitoring, these experiments crowded out the people who are building a business around this, like Currentcost, Enio, Pachube and many more.

The fact is that online energy monitoring is not dead - the demise of these services will simply provide more room for other companies to innovate without being stepped on. Neither Powermeter or Hohm were doing anything particularly innovative that hadn’t been done many times before anyway! Powermeter also suffered from being a silo of data, not a hub. You could put data in, but not get it out, which is a bit pointless. A truly useful service in this space needs to act as an aggregator, letting data flow through it so that other innovations can cluster around it, like the Social Meter project, for instance.

Innovation needs openness, and by smothering a potentially innovative space with their distinctly non-innovative services, MS and Google did nobody any favours. We are better off without them.

Publishing CurrentCost data to the world

A while ago, I started hacking around with a CurrentCost real-time energy monitor. This is a very nice little device that measures your electricity use, but more importantly has a serial output on the bottom so you can get data out of it.

Well, eventually I decided that while being able to get data off the meter was nice, it would be better if I could publish it somewhere. So, I wrote a program in Ruby to do exactly that. It reads data from the meter, and sticks it on the web. I’ll go into a bit more detail in a minute, but first, you can download it (and get the source code) from github.

The program operates as a system daemon, which runs in the background on your Linux box (Mac should work as well) and uploads to various places. Adding new publishers is dead easy, so if you want to publish your data somewhere else, you can easily add it.

The Carbon Diet

First up, my own site, The Carbon Diet. This uploads your daily usage history from the meter into your carbon diet account so that you don’t have to take so many meter readings to get an accurate graph. This is still pretty experimental and needs more work, but it’s pretty useful already. You can see how it looks on my profile.

AMEE

Next, what I think of as the important one. AMEE, if you’re not aware, AMEE is a neutral aggregation platform for sharing energy data and carbon calculations (disclaimer: I work for them these days). Think OpenID for your energy identity. Anyway, we have a nice “smart meter” demo which uses my currentcost app as the data source. Every minute, it uploads into an AMEE profile, and then another app makes a nice graph of the CO2 produced. In theory, the Carbon Diet could pull that data from AMEE instead of me publishing it directly, but that’s still to come.

Pachube

Another energy data sharing service is Pachube (pronounced “patch bay”). As far as I can tell, this is more geared at art and design than rigorous data, but it’s fun to play with. They’ve done a bunch of stuff with the CurrentCost, and now my app joins the throng. My pachube feed updates every 6 seconds - every time the meter sends data out.

Twitter

Finally, what would be the point of a web energy publisher if it couldn’t tweet? If you really want to, you can see my minute-by-minute energy usage on Twitter by visiting @james_energy.

CurrentCost data live on Pachube

So, the other day I got a nice little tray icon working for my CurrentCost power monitor. That’s great, but data is only really gets fun when it’s mashable, so the next step was to get it online somehow.

Pachube is a site which aggregates data feeds from real-world (and virtual-world) devices, shows them on a map, makes graphs, things like that, so it seemed like a good first attempt at putting my power data online. My first thought was to get my app to post data at regular intervals to the service, but unfortunately Pachube doesn’t work like that. Instead, it acts more like a news reader, not a publishing platform - Google Reader instead of Blogger, if that makes sense. So, I had to publish my feed live on the web and point Pachube at the URL.

First step: EEML. This is an XML-based format which Pachube reads which can contain not only multiple data feeds, but tags and other metadata. So (as seems to be the fashion), I wrapped it up in a Ruby gem, available from GitHub as ever. The gem simply provides utility classes to build an EEML feed and convert it to the XML-based format for delivery over the web.

Then, the final step was to publish the data on the web. For that, we need a web server. However, having a full web server for just one feed seemed overkill, and I didn’t want to publish to yet another intermediate server, so we need to serve the data directly. Ruby to the rescue once again. WEBrick is a simple web server which is part of the core Ruby libraries. You create a server, write simple servlet classes, and mount them at particular locations. For instance:

# Create WEBrick server s = WEBrick::HTTPServer.new( :Port => 50000 ) # A simple "hello world" servlet class HelloServlet

Now, http://localhost:50000/ will say “hello world”. From here it’s a simple modification to publish the EEML feed. EEML-Ruby includes a simple EEML server script as an example. So, after building this into the tray app, now whenever my CurrentCost is connected and the app is running, it serves up EEML data to the web. You can see the data feed (fairly intermittent, as obviously the meter isn’t always connected to my PC at the moment) live on Pachube.