TED5000-C Install

This post has nothing to do with software development, but I wanted a place to record my experience installing a TED5000-C from "The Energy Detective". My TED5000 just arrived the other day and I spent a couple hours on Saturday getting it all setup.

The first thing you'll notice is the box. The hand holding the wireless display doesn't look very comfortable.

When you open this up, you are greeted with smaller boxes for the three main modules and a set of installation instructions:

Unless you are pretty comfortable with the electrical system in your house, the included installation instructions won't be very helpful. The paperwork suggests you refer to the more detailed instructions on the included CD. That's probably a good idea.

Just don't stick that mini-CD in any slot-loading CD-ROM drives. You might not get it back.

The MTU

The first module, the "MTU" is the device that you install directly into your power panel. It detects your power usage and transmits that data using Power Line Communication (sending network data using power lines) throughout your home.

According to the manual, the TED5000-C MTU is designed to support "two-phase" power systems. I guess this is supposed to imply that it is designed for typical North American homes. Unfortunately, the guys at The Energy Detective seem to have fallen into a common error. While many people refer to North American power as two-phase, they are wrong. No homes in North America use two-phase power. What we actually use is a three-wire, single-phase, mid-point neutral system. You can read more about home power systems at Wikipedia.

You'll need to open up your power panel to install the MTU. Here's what my panel looks like.

To install the MTU you'll need a good flat-head insulated screw-driver. I also recommend removing all jewellery (including rings), wearing good rubber-soled shoes, and if you have them, a pair of good rubber gloves. There is a lot of juice flowing in your panel and you don't want anything going wrong here.

If you aren't absolutely confident you can do this safely, DON'T. Call an electrician.

First, turn off the main breaker to cut power to your entire house. Now grab your screw driver and take the cover(s) off your panel.

First you'll want to hook up the power harness for the MTU. This is a wiring bundle with a red, black and white wire. Find a circuit breaker that isn't driving a lot of electronics equipment (hallway lights, bathrooms, etc) and screw down the black to black, and red to red, on that breaker. It is critical you get this right.

In a split-phase system, the black wires are one 120V line, and the red wires are a second 120V line, running in opposite phases. You need to connect the MTU to one wire of each phase, ensuring it has a 240V supply. Finally, connect the white wire to the neutral bus in your panel.

Here is what mine looks like.

Now you've got a power supply for the MTU. The next step is to install the sensors around your mains. These are the two main power leads coming into your box. In my home the come up from the bottom of the box. While in others they down from the top.

The MTU comes with a wiring harness that has two round clamps on the end. Each clamp can be opened with a simple squeeze. You'll need to arrange one clamp around each main in your box. You'll notice a small red dot on each clamp. It is critical that both clamps have their dots pointed the same way with regards to the flow of current; either both pointed "in" or both pointed "out". These clamps will hang loose around each main. They do not need to be tight, but you should make sure they are going to stay put.

Be very careful when attaching these clamps. Even though you have turned the primary breaker off, the main lines are still live and touching the ends of them may be a lot more excitement that you are ready for.

Here's what my clamps look like.

Now that you've got the wiring harnesses in place, you need to connect them to the MTU and then find a good spot to place it. I just left mine sitting in the bottom of my box.

Here it is, all hooked up.

Don't put the covers back on just yet. You'll want to ensure everything is working first. To do that, you will need to turn the main circuit-breaker back on.

If you've hooked everything up correctly, the MTU should quickly blink green a few times then settle into a slower pattern, blinking only when it is transmitting data. If you don't get the proper lights, it's time to check the trouble-shooting manual. Chances are good that you didn't get your power-supply connected right.

If you need to go in and make any changes, don't forget to turn off the main circuit-breaker first.

Now that you have the MTU installed, the next step is the Gateway.

The Gateway

Now that the MTU is measuring your power use and transmitting that data across your power lines, the next step is to receive those results and do something useful with them. That's what the Gateway is for.

The gateway is a singularly uninteresting device on the outside. You plug it into the wall somewhere and then run a cable from the top of the device to your Ethernet router. That's it. But in those few steps a remarkable number of things are happening.

First, the gateway is detecting the Power Line Communication (PLC) from the MTU in your power box. Every few seconds it reads the new data and stores it in a history log.

Second, the gateway is running a tiny web-server. It gets an IP address from your router and begins server up the data from your MTU in beautifully organized graphs and charts.

Third, the gateway is running a small ZigBee transmitter that sends detailed power usage data to the TED 5000-C wireless display (see below).

Fourth, the gateway communicates over the Internet to Google's Power Meter service and records your household power consumption online so you can view it anywhere.

All that in a unit that looks just like the power-adapter for your telephone.

At this point you could stop if you wanted to. You now have power being measured at your power box, and being received and displayed on your local network. To see the results, just point your web browser at the IP address assigned to the TED gateway (TED includes a small program that helps you find this address if you don't know it.)

There are even a number of iPhone applications that can display this information on your iPhone or iTouch device.

If you've ordered the TED 5000-C, you have one more box left to open.

The Display

The last piece is a small, battery powered display that receives the ZigBee transmissions from the Gateway. This unit shows all the data available on the TED web browser, but in a small wireless counter-top device.

A few years ago this device would have looked incredibly high-tech. But these days with all the iPhone and iTouch devices around, the TED display looks pretty boring. But boring or not, it does contain all the information you would want and it's very easy to read.

Pressing the big button on the front rotates through various displays showing your real-time usage, daily power cost, monthly cost, predicted monthly bill and a few other options.

The web interface on the TED gateway gives you a set of tools for configuring the options shows on the Display unit, and it's pretty easy to use.

Summary

Setting this whole thing up took me just under two hours. It was pretty straight-forward though the provided instructions could have been a bit better. The results are pretty impressive though.

Do I have any complaints? Certainly. My biggest complaint is the power line communications used by the MTU and Gateway. Because of the way it works, the communications between these two devices happens best when the Gateway is kept far away from electronics devices with switching power supplies. This basically means that you cannot connect the Gateway to a plug anywhere near your computer, monitors, fax machines, UPS devices, etc. You also cannot connect it to a power-bar or power filter.

The problem comes when you realize that you still need to plug the Gateway into your Internet router. I don't know about you, but I tend to keep my router pretty close to my computer. Finding a power plug that meets the Gateway's requirements, but is still within reach of your Internet router could be a huge challenge.

My only other gripe is with the portable Display unit. Mine doesn't work. Or rather, mine stopped working. When I first set everything up I had no problems. But at some point during the day, the device stopped receiving data from the Gateway. Now it just reports zero values for everything.

I've followed all the trouble-shooting instructions from The Energy Detective and have arrived at a step that suggests I call their technical support department. Hopefully that resolves the problem. For now, I'll just stick with an iPhone application and the web interface.

Will the TED 5000-C change our power consumption? That remains to be seen. My plan is to take the portable Display around the house and teach my children how much power the various lights and utilities in the house truly use. My hope is that information will make them smarter and help them remember to turn out lights and devices when they aren't using them. If that works, I'm sure we can shave at least 10% off our monthly bill. If we get that far, the TED will have paid for itself in the first year alone.

I'll let you know how it goes.

Leading Software - a book in progress

I am writing a book.

This book is about being an effective Software Development Manager. It’s not about how to follow a particular process. It’s not about how to build great teams. It’s not about how to estimate and schedule better. It’s not even about being a good Team Lead. There are already great books about those things and I’m happy to let them be. Instead, this book is about the hundreds of tiny things that make success in the role of a Software Development Manager so unique.

I am writing this book online, and you can follow my progress, provide feedback, and suggest ideas. Please visit the Leading Software blog to get involved.

What's wrong with Enterprise Customers

I've been thinking about Tim Bray's recent article on what's wrong with enterprise software development. Tim compares the world of agile, iterative, rapid Web 2.0 development to the slow, document-heavy, front-end weighted world of enterprise software. The examples he gives are things like FaceBook, Twitter and a host of other Web 2.0 applications could never have been created if their authors tried to follow an enterprise model.

I couldn't agree more.

However, I don't think the problem is with the enterprise software development groups. These people, by and large, know that the process they are following doesn't work. They're not stupid. So why do they keep doing it?

I blame the customers.

I work for a company that makes enterprise software, and we do our very best to be agile, iterative, and light-weight in our processes. In general we are quite successful. However, we have one massive handicap that no amount of process can seem to overcome. Unlike Web 2.0 products, where customers begin using the product right away and give you valuable feedback as you go along, our customers tell us everything they want up-front and aren't usually interested in seeing the product until it is "done". With customers like that, the successes of Web 2.0 simply cannot be replicated.

Personally, I don't think we need to re-train the software development community. I think they're more than willing to adopt the techniques that have made Web 2.0 successful.

I think we need to retrain enterprise customers. They need to learn the value of working with iterative software. They need to be willing to use things that are partially incomplete, and work with developers to complete them.

Until enterprise customers change their approach and expectations around software, no amount of fancy process or evangelizing of enterprise developers will help.

Perhaps the biggest question isn't "what's wrong with enterprise software development?" but rather, "what's wrong with enterprise software customers?" If we can fix that problem, I predict that the massive successes of Web 2.0 projects and techniques will be mirrored to explosive affect inside the enterprise.

Getting Groovy

I bought a new book just before Christmas: "Grails. A quick-start guide" by Dave Klein. It's only a basic introduction to Grails development, but it covers enough material to give you a good idea of what Grails is all about.

I started with the book just in time for shiny new versions of Groovy and Grails to be released. It's always great to use the latest and greatest - unless your book is primed for the previous version :-) Fortunately, not too much has changed in the core of the tools, so following along with the book was still pretty straightforward.

The book is a great start if you've never used either Groovy or Grails. It assumes you have a basic understanding of web-app development and are comfortable in Java-land (though non-Java programmers wouldn't find it too difficult either).

The "plot" of the book is to develop a single, usable, web-application to handle the creation and management of community-based technical conferences. The book is broken down into iterations (chapters) where each iteration builds on the one before it. In true agile fashion, some iterations re-work material from the iterations before and each chapter leaves you with working code and a sense of accomplishment.

Following along with the book takes about one or two hours per chapter, so it's a pretty quick undertaking. There are a few bugs in the book's code (maybe "half implemented features" might be a better term). If you are like me, those things will drive you batty. For example, in chapter seven I spent nearly four hours tracking down a bug that caused a blank header to be displayed in one of the views. In the end the effort was worthwhile because it taught me a lot more about the life-cycle and relationship between Grails controllers, views and model objects than the book itself. But it was a bit frustrating to see loose ends in the code examples.

Overall I've really enjoyed the adventure so far. Groovy is a terrific language and Grails looks like an incredibly fast way to put real-world web apps into production. Having done my fair share of old-school Servlet/JSP development, Grails is an incredible leap forward in productivity.

If you're looking for a quick introduction to Grails, I can happily recommend the book. If the author is looking for ways to improve the next version, I'd recommend some tips on logging and debugging (had to find my own way around these issues). Also, a caution is in order about the example code: if you are using the latest versions of Groovy (1.7) and Grails (1.2) some of the example code doesn't seem to work. Perhaps there is an easy fix, but being a total Groovy/Grails noobie, I haven't taken the time to find the solution yet.

Stick your IT in the cloud!

In addition to managing the software development team at GenoLogics, I am also the manager for IT. When I accepted that responsibility, I knew I wasn't going to be able to do things the "traditional" way in IT. There was simply no time for it. I created a vision document for how IT should work at GenoLogics and called it "The Outsource Solution." The top of that document had a simple manifesto:

GenoLogics has no specific desire or reason to make IT a core-competency. In fact, the less effort we focus on IT skills the more effort we can direct elsewhere. What could we do if we chose to push as many of our IT needs as possible into the cloud?

We have been following this manifesto doggedly for the last eight months and the results have been everything I had hoped for. I need to indicate right here, that GLS is not a typical company. Everyone at GLS can manage their own computer well enough to deal with basic issues. We don't have complete computer noobies who don't even know where their USB connectors are. And for this reason, we can take a slightly different IT path than some organizations. However, as computer use becomes increasingly common with everyone, I don't think our situation will be that unique. Ten years from now and we'll be absolutely ordinary.

First, some background. I have worked in IT before. I know how fun, complicated, and rewarding a great IT infrastructure can be. I also know how self-serving and top-down it can easily become. I had no desires to repeat that scenario here at GLS.

So, what did we do? I could (and probably will) write lots of blog posts about it in the coming weeks. But as a simple overview of what we've done so far is:

1. Migrate away from MS Exchange to Google Apps.
2. Adopt a self-serve policy as much as possible for IT issues, backed up with good internal documentation.
3. Migrate away from a grab-bag of MS Server file shares and scattered NAS devices to a single, very large, NAS server in the center of our network.
4. Get rid of as much Cisco networking as we could and switch to Sonicwall, which is easier to configure and manage.
5. Switch our VPN from Cisco to Sonicwall.
6. Combine all our various WiFi access points into a single WiFi fabric controlled by Sonicwall.
7. Migrate all other required services from MS Server to Linux (DNS, LDAP, etc).
8. Ditch using MS Server to manage our printers and have people print to them directly.
9. Migrate our in-house Atlassian software suite to the externally hosted Jira Studio service.
10. Convert dozens of QA and build machines to a small cluster of powerful VM servers.

The next couple steps will be:

1. Take all machines out of our MS Domain and shutdown the MS Servers entirely.
2. Integrate authentication between Google, Jira Studio, and our internal LDAP server.

This plan probably looks like heresy to many IT pros. How can I possibly control what is done and how machines are managed? The answer is, often I can't. I don't want to.

It's my opinion that unless you work in a strongly regulated environment (like a pharmaceutical company) the only reason IT needs tight control over individual desktops is to keep people from breaking their own machines and becoming ineffective. However, as soon as everything is in the cloud, there's nothing left to break. Ergo: no need for central IT control.

When new employees start at GLS now, we give them a laptop that has been configured with a stock OS (Win7 Basic, or MacOS is just fine), a web browser, and instructions on how to login to the VPN and install Anti-virus software.

That's it. Everything else can be done from the cloud.

For employees that must have extra software, like MS Office, we order a copy for them and give them instructions on how to download the installer from the network.

We don't keep images of machine's hard drives. We don't have "standard installations". If a machine gets messed up we just re-install the OS and start over from scratch. It's quicker to re-do a machine from scratch than it is to keep an inventory of disk images up to date.

In short, as more and more data and services move into the cloud, the traditional desktop computer looks more and more like a really smart terminal. It's a commodity. And when it's a commodity, IT should be putting as little effort into it as possible.

There are some things IT may never pass off to someone else, but I'm not sure if anything has to fall into that category. But so much of what traditional IP pros try and make their responsibility could more easily be done away with. Let someone else handle the minor details. Let your hard-earned IT dollars be spent on something that generates more value than just creating disk images.

Why Zope won't Zip

I really wanted to like Zope. So much, in fact, that I had one of my developers spend nearly three weeks preparing a case for why it was the proper platform for a new product we are creating. Imagine my dissapointment when three weeks later, this developer told me his recommendation was to not use Zope for our project.

No. That's not what I asked for. But I learned a long time ago to trust the people I've hired, and I wasn't going to start changing that now. But I did ask a lot of questions.

No surprise - since we hire such smart cookies - this developer had lots of great answers. In the end, it came down to two primary reasons. The first was ZODB. I realize that Zope really isn't all that much without ZODB, and that very fact is what nixed it for me.

We create Enterprise software. This means that we need clearly defined install, backup, migration, and validation steps for our software and data. We also need lots of our data in a tool that supports easy reporting: typically a SQL database. As soon as we have some of our data in ZODB (because Zope won't let you store certain things anywhere else) and some of our data in SQL, things have just gotten ugly.

Strike one.

The other major problem is the CPython GIL (Global Interpreter Lock) problem. In a nutshell, the typical Python interpreter only allows a single python thread to execute in the interpreter at any time. There are lots of pro-Python sites that will show you examples of how single-threaded execution is hyper-fast and that the GIL isn't a problem. However, on an eight-core server that is running multiple simultaneous web-sessions, having a single-thread of execution is like using only one-eighth of your expensive server. Sure it's not truly that bad because of I/O locks and other things that release the GIL, but it's nowhere close to what it should be.

In short, the traditional Python interpreter is a terrible implementation for multi-core servers. Given that this now includes pretty much every server out there, there is no way to justify using the current Python interpreter to create a server process like Zope. It's just wrong. Before long, a typical server will have 16 or even 32 cores. Pretty soon, people depending on Zope are going to start asking a lot of questions about why their killer new server doesn't seem very fast.

Stikes two and three. (Just not at the same time on two different cores.)

So, in a nutshell, three weeks of developer research uncovered two critical elements of Zope that have dashed any hopes of using it as the platform for a new server application. That's too bad, because at a high-level Zope has all the components we really needed.

So what have we decided to use? We're pretty sure it's going to involve Groovy. And quite possibly Grails. We've got another two-week spike planned for first thing in January. I'll update things here once that research is complete.

Prepping goodies for employees

Posted via email from Cliff's posterous site

Oh man is this ever freaky.

via tweetie

Posted via web from Cliff's posterous site