First experiences with the TED 5000

This past weekend I became the proud owner of a TED 5000 home energy monitor. I thought it might be useful to detail some initial experiences for the Renewable Energy and Island Sustainability Project and for our own subproject on From Smart Grids to Smart Consumers.

Overview of the TED 5000
The TED-5000 consists of four components.

MTU:  The "MTU" (for Measurement Transmitting Unit) goes inside your electric panel and monitors the power being consumed by your house.

Gateway: The "Gateway" is a small unit that plugs into a wall outlet and connects to your router (in my case, an Airport) using an ethernet cable. The Gateway receives current power consumption data from the MTU every few seconds via a proprietary powerline network protocol. 

Display Unit:  The "Display Unit" is a small handheld device (like an iPod) that communicates wirelessly with the Gateway using Zigbee and can show you (among other things) a near real-time display of your power usage.

Footprints:  Finally, "Footprints" is a web application that runs on the Gateway. You use Footprints to configure your TED, display various graphs and charts, and install Firmware updates.

Installation: 
Installing the TED 5000 involves: (1) opening the electric panel and connecting the MTU; (2) plugging in the Gateway and attaching an ethernet cable from it to my Airport; and (3) accessing the Footprints web application and setting some configuration values.

I found that connecting the MTU was pretty straightforward, basically because I had two electrically-akamai friends (Robert Brewer and Tony Querubin) helping and thus my personal involvement was limited to showing them where my electrical panel was located, holding a flashlight, and serving them Apple Huguenot torte when they finished.  The TED installation video provides a good approximation to what's involved, though there are some minor changes from the TED 1000 to the TED 5000.

Installation Glitch #1: No http://TED5000
The installation manual says that after hooking up the MTU and Gateway, you can access the Footprints web application using: http://TED5000.  That fails for non-Windows systems.  Fortunately, Robert was already aware of the problem and how to work around it. First, he looked up my Mac's IP address (10.0.1.3) and invoked "ping 10.0.1.255" to find out all of the devices on the 10.0.1.* subnet. Three devices responded: my Airport (10.0.1.1), my computer (10.0.1.3), and a third "mystery" device at 10.0.1.2.  Bingo: the URL to the footprints software on my computer is: http://10.0.1.2/Footprints.html.

You might think that providing a URL that only works on Windows systems (and not even stating that in the installation guide) is pretty lame.  But wait, it gets worse:

Installation Glitch #2:  No HST.
The Display Unit provides the current time, and to do so, it needs to know the time zone.  Part of the configuration process in Footprints involves specifying the time zone, for which it provides a drop down menu with exactly four choices: EST, CST, MST, and PST.  No HST for those of us in Hawaii; no AKST for those of us in Alaska.   I am hoping the TED programmers get a clue in the near future and issue a firmware update that fixes this problem; in the interim, my Display Unit is laboring under the illusion that it lives in California.

Initial results
Having real-time display of power usage reminds me a great deal of when we first got our Prius: all of a sudden you're getting a whole new dimension of interesting data about your environment.  From a safety perspective, the TED has it all over the Prius, since it does not tempt you to monitor whether you're running exclusively on battery power while driving down the Pali Highway at rush hour.

Instead, from the sedentary position of my kitchen table, I can now inform you that our baseline power usage is around 400 Watts.  Each of our ceiling fans use about 50 W.  Turning on the microwave increases our power usage by about 1000 W.  I am too horrified to confess how much power our tiny, "Energy Star", 5000 BTU window air conditioner uses on startup, but it dwarfs every other appliance we own by a mile.

I am sure that we are similar to every other new TED user, in that we tend to run over to the Display Unit whenever we do anything (turn on/off the TV, turn on/off the stove, etc.) to see what effect it has on our power consumption.  Similarly, if we're in the vicinity of the Display Unit and our power usage is significantly different from 400W, we start wondering what's going on.

It's also cool to empirically test various things you've heard in the news.  For example, Joanne read some place that you should unplug your toaster oven when you're not using it because it uses up power.  That seemed suspect to me, so I took the Display Unit over to our toaster oven, unplugged it, and waited for a drop in power consumption.  Nada.

Behavioral change, or Is This Just a $250 toy?
The real question is whether the TED 5000 is anything more than an expensive toy, and the answer to that depends upon whether we actually change (i.e. reduce) our energy consumption now that we know what we're doing.

The jury is still out on that question, though of course the jury has only had about 36 hours to deliberate.  What I can say at this point is the following:

(1) Our espresso maker is an energy hog.  I was surprised to see that it uses over 1000W, and this is significant because we tend to turn it on first thing in the morning and leave it on for a couple of hours until we have finished making all our morning espressos.  Given its energy consumption, we should turn it off between uses even though that means we need to wait for it to heat up again.

(2) Our TV/DVR's standby power consumption is fairly low. We have heard horror stories about LCDs TVs that  consume many watts even when "off", and we were happy to discover that our TV uses only 1-2W when in standby.  The DVR uses about 20-22W in standby.  That's not too bad, although that 25W does account for about 6% of our "baseline" 400 W.

(3) We need to replace our remaining incandescent lightbulbs with CFLs without delay.  When your baseline is 400W, and you turn on the kitchen lights and it jumps by 25%, you just feel stupid.

I intend to do a bit more detective work on our baseline usage, and perhaps we can cut that down.  Come to think of it, we should not make any changes to our behavior for a week so that we can establish a decent baseline dataset of our current-but-soon-to-be-history energetically profligate lifestyle.

For another new TED 5000 user's experience, see here.

Pretty printing code with google-code-prettify

There are many ways to pretty print code in blogs, as a Google search will show you, and all the methods involve a certain amount of hassle. After some fooling around today, I have come across the following approach which is pretty simple and has the advantage that you don't have to preprocess your code to escape certain characters (such as angle brackets).

My currently preferred approach uses google-code-prettify, which I suspect is the package used to perform syntax highlighting in google project hosting. Integrating this package in Blogger requires three steps:

1. Update the <head> section of your Blogger template

Insert the following lines of code:

<link href="http://google-code-prettify.googlecode.com/svn/trunk/src/prettify/prettify.css"
rel="stylesheet" type="text/css"/>
<script src="http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js"
type="text/javascript" />

2. Update the <body> element tag of your Blogger template

Change it to:

<body onload="prettyPrint()">

Save these changes to your template.

3. Insert your code using <code class="prettyprint lang-java">

You must be in "Edit Html" mode, not "Compose" mode, when you do this. Here is an example of the results:

/**
* Creates a new CD, provided its title, group, and song list.
* @param title The title.
* @param group The group.
* @param tracks The song titles.
*/
public CompactDisc(String title, String group, String... tracks) {
this.title = title;
this.group = group;
this.tracks = Arrays.asList(tracks);
// Since CompactDiscs are immutable, the hash value will never change for an instance.
this.hashvalue = (new String(title + group)).hashCode();
}

OK, if you have followed me so far, and if your Blog template has a light background, then the code should be formatted nicely. However, if your Blogger template has a black background like mine, then the results are terrible, because the default colors in prettify.css are designed to look good against a white background, not a black background.

The reason why my code sample looks relatively reasonable is because I use a custom version of prettify.css where I have changed the colors to those that contrast well with a black background. This file is available to you at:

http://ics-software-engineering.googlecode.com/svn/trunk/prettify/prettify.css

So, use this URL in the <link> element that you inserted into the <head> element of your Blogger template, and you should be fine.

If you don't like my choice of colors (or google's), you can create your own prettify.css, place it somewhere on the web, and reference it to get your own coloring scheme.

There is a bug in Blogger that you should be aware of:  if you switch back and forth between "Compose" and "Edit HTML" mode while doing this, at some point Blogger eliminates all indentation in your code.   You can avoid this by not using "Compose", or else by inserting your code as the last step in creating your posting.

Google Summer of Code Midterm Results for Hackystat

I am delighted to announce that all five of the GSoC students working on Hackystat have passed their midterm evaluation and will be continuing with us for the rest of the summer.

Myriam Leggieri is working on the use of RDF to facilitate integration of Hackystat data with other kinds of knowledge sources in the project hackystat-linked-sensor-data.


Rachel Shadoan is working on the integration of social networking with Hackystat data in order to create novel data mining opportunities in the project hackystat-analysis-socnet.


Harvey Weitz is investigating a case-based reasoning approach to management for service-oriented architecture, using Hackystat as his test case, in the project hackystat-service-manager.


Anthony Du is implementing a software engineering educational game in the project hackystat-ui-devcathlon, building upon the initial work done in ICS 414 last spring.

Last but not least, Shaoxuan Zhang is implementing support for Issue sensor data collection and analysis through the hackystat-sensor-ant project.

All of these students have made significant progress on their projects so far, and the summer is only half over. I look forward to see what they have working by September!

Hackystat in a Nutshell

Another screencast, this time a short introduction to Hackystat:

Google Summer of Code 2009

Applications for Google Summer of Code 2009 are coming up soon. I recently gave a short talk on Google Summer of Code to some graduate students at the University of Hawaii. Here is a screencast of that lecture:

How to guarantee you will not be considered for a student internship

Since I founded the Collaborative Software Development Laboratory in 1991, I have provided research positions and internships to students from across the world, including Germany, Italy, India, China, Japan, Australia, Iceland, and Indonesia. Providing these opportunities to students, and learning from their differing cultural backgrounds is one of the great pleasures of being a professor.

Every semester I receive dozens of emails from students around the world who are requesting consideration for a research position of some sort in my lab. Unfortunately, most of them are quite similar to the one I just received this morning:

Dear Prof.,
To introduce myself, I am a 3rd year student of the Department of [Deleted] Majoring in Statistics and Informatics(5 yr.Integrated) at [Deleted], [Deleted]'s premier research organization, looking at the possibility of obtaining a position for Summer Internship, gelling with my academic background. I am aware of the superior quality of research at your institute ,I have decided that your current research work matches my interests to a remarkable degree.

Enclosed please find a copy of my resume. A number of details about my profile appear in the same. Yet no resume can comprehensively spell out everything.If my profile, prima facie matches with your requirements for a Summer Intern, please revert back, so that I could furnish any more relevant information.May I please also enquire whether some funding may be available for this internship in the form of a grant or scholarship?
Looking forward to a reply in the affirmative.

If selected by your consideration I promise to complete my assignments with utmost sincerity.

--
Thanking you
Your Sincerely....

There are, of course, a number of grammatical errors in this email, but since this student is clearly a non-native speaker, those errors would not deter me in the slightest from considering him for a research internship.

What makes this request a non-starter is the fact that this student sent me a form letter: there is not a single detail in this letter that provides evidence that the student has any clue about my research interests. Indeed, this student does not even take the time to address the email to me personally!

So, with the goal of helping other students who might be interested in academic experiences outside of their current environment, here is a simple guideline:

Send 10 personal, carefully written emails to professors whose research interests really do match your own, with concrete details about their research and how it intersects with your academic interests. These 10 emails have higher odds of success than (for example) 1000 generic emails sent to every professor in the country of your choice.

What might a "personal, carefully written email" include? Here are some ideas:

• Include the professor's actual name.
  
• Include the professor's actual laboratory name.
• Include references to at least two recent publications of the professor, with questions and/or comments about the papers that indicate that you have read the papers and reflected on them.
  
• Include some simple, but concrete ideas on how you might contribute to the research. These don't have to be feasible or ground breaking. Just demonstrate that you're trying.
  
• Optionally, include other areas of interest of yours, which might have some interdisciplinary connection.
  

This, of course, takes time: perhaps five or six hours per email.

When I receive this kind of email from a student, I consider it carefully, and even if their interests don't really match mine, I reply out of respect for the energy they clearly put into their request and try to provide pointers to colleagues with better matching interests.

And there you see the key to why this approach is more effective: if you, as a student, devote this kind of energy up front on a small number of letters to a small number of professors, you can enlist our help in the search process. In terms of searching the space of appropriate research institutes, having professors guide your search is significantly more effective than spewing out 1000 generic emails.

Have I ever received such a letter from a student? Yes, several times, and in fact the most recent student who introduced himself this way is arriving in my lab on Monday to start his internship.

Reflections on Google Summer of Code 2008

Background

Back in April, we applied Hackystat to the 2008 Google Summer of Code program. We didn't know too much about it, other than that it provided a chance for students to be funded by Google to work on open source projects for the summer.

With great glee, we learned in March that Hackystat was accepted as one of the 140 projects sponsored by Google. The next step was to solicit student applications, which we did by sending email to the Hackystat discussion lists. We ended up with around 20 applications. There were a few that were totally off the wall from people who had no clue what Hackystat was, and a few others that were disorganized, incomplete, or otherwise indicative of a student who would probably not be successful. But, a good dozen of the 20 applications appeared quite promising and deserving of funding.

Google then posted the number of "slots" for each project--the maximum number of students that they would support. Hackystat got 4 slots. The number of slots is apparently based partially on the number of applications received by the project, and partially on the organization's past track record with GSoC. Hackystat had no prior track record, and couldn't compete with the number of applications for, say, the Apache Foundation. The GSoC Program Administrator answered the anguished pleas of new organizations who got less slots than they wanted by basically saying, "Look, we don't want to give you a zillion slots and then have half a zillion projects fail. Do a good job this year with the slots you were given and reapply next year." Sound advice, actually.

We then started ranking the applications to figure out which four students should be funded. It was difficult and frustrating, because there were many good applications. At the end, we came up with four students who we felt had a combination of interesting project ideas and a good chance of success based on their skills and situations.

We were right. Three out of four of the students successfully completed their projects, and the fourth student had to drop out of the program due to sudden illness, which no one could have foreseen.

GSoC requires each student to have a mentor. This summer, Greg Wilson of the University of Toronto and I each took two students. Greg's students were physically sited at the University of Toronto, so he was able to have face-to-face interactions. My students were in China.

Student support took several forms over the summer. First, there was email and the Hackystat developer mailing lists. At the beginning of the summer, I received a few emails from students that I redirected to the mailing list, so that other project developers could respond, and also because the question asked was of general Hackystat interest. Fairly quickly, the students caught on, and started posting most of their general-interest questions to the list. I think this was one conceptual hurdle for the students to get over: they were not in a relationship just with me or Greg, but also with the entire Hackystat developer and user community. While there were certainly issues pertaining to the GSoC program that they discussed privately with their mentors, they were also "real" Hackystat developers and needed to learn how to interact with the wider community. All of the students acclimated to their new role.

We also requested that the students maintain a blog and post an entry at least once a week that would summarize what they'd been working on, what problems they'd run into, and what they were planning to do next. This was also pretty successful. You can see Shaoxuan's, Eva's, and Matthew's blogs for details. Interestingly, the Chinese students found they could not access their (U.S. created) blogs once they were in China, and so had to use Wiki pages.

Finally, I also set up weekly teleconferences via Skype with the two students I was mentoring in China. This was a miserable failure, probably due to my own lameness. Despite the fact that I live in a timezone (HST) shared by very few of my software engineering colleagues, and thus have lots of experience with multi-timezone teleconferencing, the Hawaii-China difference just totally threw me. The international dateline did not help matters. At any rate, we simply fell back to asynchronous communication via blogs and email and that worked fine.

For source code and documentation hosting, we used two mechanisms. The Hackystat project uses Google Project Hosting, and so the students I mentored used this service. Greg is the force behind Dr. Project, and so the students he mentored used that service. As part of the wrapup activities, his students ported their work to Google Project Hosting to conform to the Hackystat conventions.

Results

So, what did they actually accomplish? Matthew Bassett created a sensor for Microsoft Team Foundation server. Here's a screen shot of one page where the user can customize the events the sensor collects:

The sensor itself is available at: http://code.google.com/p/hackystat-sensor-tfs/.

Eva Wong worked on a data visualization system for Hackystat based on Flare.

Her project is available at: http://code.google.com/p/hackystat-ui-sensordatavisualizer/.

Finally, Shaoxuan Zhang worked on multi-project analysis mechanisms for Hackystat using Wicket. Here is a screen shot of the Portfolio page:

His project is available at: http://code.google.com/p/hackystat-ui-wicket/.

Reflections

So, what makes for a successful GSoC?

First, and most obviously, it's important to have good students. "Good", with respect to GSoC, seems to boil down to two essential attributes: a passion for the problem, and the ability to be self-starting. (As long as the student "starts", the mentors and other developers can help them "finish"). It was delightful to read Matthew's blog entries about Team Foundation Server: he obviously likes the technology and enjoyed digging into its internals. At one point in the summer, Shaoxuan sent me an email in which he apologized that he had not been working much for the past week because he just got married, but he'd work extra hard the next week to catch up! We clearly had passionate students.

It also helps to have good mentors. In the Hackystat project, we have an embarrassment of riches on this front, since the project includes a large number of academics who mentor as part of their day jobs. In the end, we only needed two active mentors for the four students, but we easily had mentoring capacity for a couple dozen students.

Establishing effective communication systems is critical. Part of this is technological. We found that email and blogs worked well. Skype did not work well for me, but that was probably operator error on my part. Greg had the additional opportunity to use face-to-face communication, which is certainly helpful but not at all necessary to success. The other part is social. Most of our students needed to learn over the summer to: (a) request help quickly when they ran into problems, and (b) direct their question to the appropriate forum: either the Hackystat developer mailing list or privately to a mentor via email. This wasn't particularly difficult or anything, it was just a part of the process of understanding the Hackystat project culture.

I think I would have more insightful "lessons learned" had any of the student projects crashed and burned, but fortunately for the students (and unfortunately for this blog posting), that simply didn't happen.

For the Hackystat project, participation in GSoC this summer has had many benefits. Clearly, we'll benefit from the code that the students have created and which now is publically visible in the Hackystat Component Directory. We are crossing our fingers that the students will continue to remain active members of the Hackystat community.

GSoC has also helped to create a new "center" of Hackystat expertise at the University of Toronto. We hope to build upon that in the future.

GSoC also catalyzed a number of discussions within the Hackystat developer community about the direction of the project and how students could most effectively participate. These insights will have long term value to the project.

I believe we are now significantly more skillful at mentoring students. I hope we get a chance to participate in GSoC 2009, and that we can build upon our experiences this summer next year.