Monday, December 15, 2014

Something better...

Last week, I left a "teaser" for this week's posting.  We finished up with a mention that Residential "Demand response" has traditionally been Direct Load Control, so let's talk about that, and see whether we can't com up with a better way.

Under Direct load Control, in exchange for some incentive from the Utility, the Customer allows the Utility to:
  • Dispatch a truck to their residence.
  • Have a technician install a remotely-controlled relay in the power line to some major load (usually pool pumps or air conditioning).
  • From time to time, turn that device off.
Of course, from time to time, equipment needs to be serviced or diagnostics run. Which means that the customer calls out another technician, who will, more likely than not, bypass the relay that the Utility's technician put in.  It's isn't part of the equipment that the Customer's technician knows about, or how to service, and "foreign" equipment is the first thing you eliminate when you're trying to figure out what's wrong.

Needless to say, Direct Load Control doesn't represent a big chunk of Residential load nationwide.
  • It's expensive for the Utility to put in.
  • It has limited popularity with customers.
Direct Load Control as a technology dates back to when appliances were mostly controlled by timers, mercury switches, bimetallic strips, cogs and cams.  That isn't true today.  In even the most basic of appliances, those have been replaced by logic, processors and buses.  Appliances are increasingly intelligent, and intelligent appliances are increasing in their penetration of the residential market.

What is needed is a way for those intelligent appliances to easily, cheaply, get information from utility grid systems, so that they can respond to that information, under customer control.  Many appliance vendors have developed the logic and proprietary communication platforms to do just that, if you want to buy all your appliances from the same manufacturer, and if your utility wants to sign up with that appliance manufacturer to pass on control signals the the appliances.  Those are two pretty big ifs.

Proprietary systems don't cut it.  What is needed is a way for the Utility not to care what brand of appliances are in the home, and the appliance manufacturer to not care what Utility is feeding power to the appliance.  This isn't a new idea, either.  A paper published in 2007 outlined the potential, and suggested that a non-proprietary solution be developed.

Here's the kicker: it exists.

OK, to be completely up front.  The standard behind that link is a product of the USNAP Alliance, where yours truly is the Executive Director.  To be honest, I'm not doing that work (or writing this Blog) because it's making me a ton of money.

I'm doing it because it is a kick-@$$ solution to a real problem.  It's a solution that is starting to gain traction, which is exciting to see.

So, if you'll be at the Consumer Electronics Show, or Distributech, or the AHR Expo, and want to talk about what CEA-2045 can do, drop me a note at chris AT

Monday, December 8, 2014

OPEC's changed strategy

Okay, I understand that this is Smart Grid Realities, and that this interrupts my discussion of Net Metering, and that what OPEC is doing might seem a bit out of my usual area of discussion, but I think there is a connection between the larger efforts of which Smart Grid is a key component and what is happening in oil prices, and having put this down in writing, it seemed appropriate to fling it out into the ether for comment.

That follow-up I promised...

A few weeks about a month ago, I "guest-blogged" over at the Smart Grid Library blog about some of the problems with Net Metering, promising to do a follow-up post here in a week offering some ideas for resolving those problems.

The best laid plans of mice and men are approximately equal.

Between increased client work (not comaplining) and a little emergency home-remodeling (I would love to have a few strong words with the guys who put up the bathroom tile in this house when it was built) the blog entry never got published.

So here (better late than never) is the follow-up to that November 3rd blog entry...