First run with the WattsUp .NET
I received my WattsUp .NET a week or two ago and fiddled around with it a bit using its basic logging features. I’m happy to see that it reports 0.1W precision (compared with 1W on the Kill-a-Watt). Overall, the WattsUp seems like a nice device although it is a little tricky to use. Complaints:
- I have found the USB port to be flaky
- The two-button interface is a bit cryptic (e.g., “SELECT” and “MODE” sound like the same button to me… I can’t remember which does what).
- On at least one instance, it took the think several minutes to boot… but thankfully that isn’t happening anymore.
- Data log size is way too small… for thinks like a refrigerator, you really need a week or more of logs and with just basic data the WattsUp fills up in 10 hours.
- The WattsUp web interface doesn’t send a timestamp with the data which means it can get out of order if the data packet gets lost in transit. Some jitter may occur in the logged results. I’ll eventually look at putting the data logging on a local server to reduce this jitter.
Complaints aside, I now have it functioning as a web-enabled logger, and I’m happy to report that it is much easier than anticipated. After checking out various user forums on the WattsUp website and looking at their communications protocol document, I expected that getting the web-based logging going on this device would be very difficult. But, as it turns out, the protocol is quite simple.
I don’t know the technical terminology for it, but the WattsUp reports data to any website and server side processing script (php, Perl, etc) using a webform POST style format. For example, I can tell it to talk to www.theshrollys.com and point it to /cgi-bin/wattsup.pl, and it will send a message with a format like this:
http://www.theshrollys.com/cgi-bin/wattsup.pl?id=1&w=0&v=1199&a=381&wh=0&pcy=0&frq=599&va=458&rnc=0&sr=20
It will only send the parameters that you have programmed it to send (using the USB software interface). The default data push period is one sample every 20sec, but you can modify that by having your server side script respond with a new update rate. What’s more, if you are interested, your server script can actually power cycle the load! To tell the WattsUp to send data ever 1sec, you respond with this:
Content-type: text/html
[0!1]
The “!1″ tells the WattsUp to update the data send rate to 1Hz. The ’0′ says “leave power on”.
As a trial run last night, I set up Katie’s Macbook Pro to transcode our O Brother Where Art Thou DVD to an M4V (H.264) format using Handbrake, and checked the results when I woke. Very nice! Included in the plot is both the handbrake encode (~37W on average) and a long period of idle (~13W). Just for fun, I’m going to have to run the same DVD encode on my HP 8510W and compare.
Macbook Pro DVD Encode
If you’re interested, here is my wattsup.pl Perl script for handling the data. Not very sophisticated right now, but good enough and enhancements are in the works as I have time.
Finally, one thing I was concerned about was lost data (packet loss or general internet slowness). Unfortunately, the data sent to the server does not include a timestamp, so I must timestamp it locally. This means there is some jitter in the results. If my server is slow, it could apply the wrong timestamp. If packets are lost, timestamps get skewed. And so on. I took a look at the distribution of time in between samples as a function of my server side timestamp. Overall, it is pretty reliable, but there are some bad outliers.
WattsUp Time Between Samples Distribution