OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [energyinterop] RE: Error Condition Re: Re: [energyinterop] Observations from the Appliance workshop


David,

 

Great discussion.

 

Let's go back to the last point in your initial email:

"Appliance manufacturers want to hear what it is worth to the grid. I can give you 5kW for 15 min, 2kW for an hour, 1 kW for 8 hours. What’s it worth to you? The appliance manufacturers haven’t gotten this data yet. "

Appliance manufacturers may not yet think of it this way, but the simplest and only way to convey this information is in terms of the current and forward prices of electric energy. This tells the appliance exactly what it will cost to run the appliance for any scenario.

And as Sec. Steven Chu said, "the simplest way to communicate consumer preferences is a green button and a red button on the thermostat, dryer, etc."  The red button says I am willing to pay a lot for comfort / convenience and  the green button says I will give up comfort to save money.

Given the current and forward prices of power a very simple device can figure out how much is saved by extending the drying cycle  to get a lower price later or letting the air temperature rise above or below the air conditioner set point based on the differences between current and forward prices.  Based on which button is set, (red or green ) the device can decide how to operate.

The  actual set point on the thermostat can based on manual setting, occupancy, iphone control, etc. independent of price.  The prices and the consumer preference button will determine the variability in room temperature about the set point.

Using prices it is clear in most cases that there is no customer economic benefit to coordinating the use of appliances at least in the US residential markets where there is no demand charge.

Note that the prices can reflect both transmission and distribution system limits and overall energy costs on the grid..

And the prices can change as system conditions change and such changes broadcast or transmitted to all of the devices.

Prices will be communicated to devices as a vector of prices.  Some devices will only use the current price, other devices will use the current price and the price 5 min from now or an hour from now and other more intelligent devices such as air conditioners with ice storage or electric vehicles may look a vector of prices over several hours

Such price vectors can be determined by tariffs, supply or demand or can be reliability prices ( critical peak prices) imposed over short periods during emergencies or peak demand response.

 

Comments welcome.

Ed

 

Edward G. Cazalet, Ph.D.

101 First Street, Suite 552

Los Altos, CA 94022

650-949-5274

cell: 408-621-2772

ed@cazalet.com

www.cazalet.com

 

From: Michel Kohanim [mailto:michel@universal-devices.com]
Sent: Friday, October 30, 2009 12:54 PM
To: b2g_interop@nist.gov; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] RE: Error Condition Re: Re: [energyinterop] Observations from the Appliance workshop

 

Hi David,

 

I think what’s missing from your argument is the pivotal role of customer comfort and his/her preferences. If we remove the customer from the equations/use cases, then you are 100% correct: some preliminary configurations on the device and that’s it.

 

Now, if you add alternative sources of energy in addition to customer comfort/preferences, then you will either have to have smart devices that can communicate with one another and with other sources of energy and then decide what to do OR you could have a higher level of intelligence (ESI) that implements/orchestrates these scenarios.

 

In short, I posit that it all depends on how much importance is given to customers’ comfort and preferences.

 

With kind regards,

 

********************************

Michel Kohanim, C.E.O

Universal Devices, Inc.

 

(p) 818.631.0333

(f)  818.436.0702

http://www.universal-devices.com

********************************

 

From: Holmberg, David [mailto:david.holmberg@nist.gov]
Sent: Friday, October 30, 2009 12:43 PM
To: b2g_interop@nist.gov; 'energyinterop@lists.oasis-open.org'
Subject: [energyinterop] RE: Error Condition Re: Re: [energyinterop] Observations from the Appliance workshop

 

All,

 

I am thinking of EISA and their interest in collaboration among appliances, versus EMS central control, versus independent appliance operation. The Whirlpool rep at the workshop mentioned the need for the washer to talk with the dryer, and expressed some concern for collaboration between appliances to limit demand peaks inside the house (although I don’t see why that matters in the US residential market now, yes for Europe, yes for commercial). From the grid perspective—who cares what the peak is in your house since it all gets averaged out over a thousand homes? So, what is the business imperative that would support all the effort needed to get some distributed mesh appliance collaboration standard? For EISA, I guess it’s the commercial market.

 

Thanks Larry for the observations. Let me comment on that.

·         The cake must finish cooking. The oven will not shut off if the price goes up, unless I tell it it’s worth it to me in general to turn off the oven in the case of very high prices. But a smart oven will know that a peak is coming and recommend waiting and give you the option to save money or turn on the oven now.

·         I must get the clothes dry. So, the dryer defaults to smart saver mode and would normally delay load start or ask if it can delay. I say NO, or hit the start button TWICE to tell it I mean NOW.

·         I’ll take a cold shower. So, take one. The smart water heater could learn your normal usage patterns. We even discussed pre-heating of hot water tanks with safety features to prevent scald. Maybe even Daikin in doing this already.

·         The house should be cool when I get home. So, I program the thermostat. And I have some app on my iPhone that can allow updating it from work if I’m early/late, if I’m nerdy enough.

·         Seems to me that pool pumps are like the defrost on the fridge—run it off peak anyway, always.

 

In each case, the interface is at the appliance, or default built into the appliance. EISA sees a reason for collaboration among appliances, but I don’t see it really. I see the need for appliances to get power use off peak, either by shed or shift.

 

But what does the EMS bring to the table? A single interface to collect general home preferences maybe. Also, the potential for requiring less smarts in the individual appliances. But my contention is that removing smarts from the appliance depends on developing energy profiles for different appliance classes that somehow communicates all the nuances of how that appliance could shed or shift or store energy by different amounts in different combinations for different future price curves. Am I missing something? I guess EISA members are focused more on the commercial market and have given significant thought to the sweet spot for energy profiles (amount of detail). I look forward to getting more details on that. This gets to John’s input below (sorry—John Who (?) since it bounced, and apparently on energyinterop list as well).

 

Thanks,
David

 

From: b2g_interop@nist.gov [mailto:b2g_interop@nist.gov]
Sent: Friday, October 30, 2009 8:47 AM
To: Holmberg, David
Cc: Holmberg, David
Subject: Error Condition Re: Re: [energyinterop] Observations from the Appliance workshop

 

Hi,

 

If I may I would like to add a few comments to this thread. If we make the assumption that all of these "smart, communicating devices" are thrown into the application (our homes) without any preparation for response models then I agree it would be daunting to achieve the use case that started this thread. But here is where standards could greatly contribute. 

 

If we develop a model for typical "smart grid event types' (that list would not be that long) and a model for logical actions that devices should take in response to events they may be informed of, (which would be defined by the equipment mfg based on their knowledge of their equipment and an understanding of the events) we can create the kind of orchestrated response described. 

 

All that would need to be communicated to the devices would be event types or "scenarios" that group events together. Devices would not have to be in direct peer to peer communication with each other (although they could be), and the user would not have to be involved in complex configuration or programming. As an example, when the dryer was installed a simple menu would be used to select the responses (a short list) that it should make in response to a defined list of smart grid events. This could include pricing, or more likely pricing would be abstracted into levels of response communicated by the defined events.

 

With this type of a model defined, the communications could be very compressed binary format capable of being consumed by simple devices with limited CPU power and using limited bandwidth on low energy networks. Equipment mfg could implement this model in their devices without ever having to be aware of the details of any specific end installation.

 

John

On Fri, Oct 30, 2009 at 2:05 AM, Michel Kohanim <michel@universal-devices.com> wrote:

Larry,

 

I am in total agreement with you. Further to your point, how would you configure all these isolated devices to do what you want? Would you go to each individual device and set them up individually? What if you are not home? Does this then mean that each device/appliance should have a user interface? Should all be schedule aware? Should they be able to communicate amongst one another? If so, what is the minimum set of communications constructs?

 

When EISA talks about Zero Net, one has to also consider alternate sources of energy and thus it would be quite a daunting task to have independent devices act in unison (and based on customer preferences) to achieve such goals.

 

With kind regards,

 

********************************

Michel Kohanim, C.E.O

Universal Devices, Inc.

 

(p) 818.631.0333

(f)  818.436.0702

http://www.universal-devices.com

********************************

 

From: Larry Lackey [mailto:llackey@tibco.com]
Sent: Thursday, October 29, 2009 3:57 PM
To: Holmberg, David; b2g_interop@nist.gov; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Observations from the Appliance workshop

 

David,

 

Thanks for the observations. For fun, let’s suppose you have several of the items mentioned below: AC, pool pump, dryer, hot water, and oven, and some friends are coming over for dinner. You might say:

  • The cake must finish cooking.
  • I must get my clothes dry in time
  • I’ll take a cold shower
  • The house should be cool when they arrive
  • And nobody will be swimming

 

Seems to me hard for any automated system to do, let alone an isolated appliance with limited computational abilities.

 

But if I had a home EMS, I could tell the EMS provided the appliances used U-SNAP or another method of communication to the EMS to receive instructions rather acting in ignorance.

 

Thoughts?

 

Thanks,

 

 

Larry

 


From: Holmberg, David [mailto:david.holmberg@nist.gov]
Sent: Thursday, October 29, 2009 3:35 PM
To: b2g_interop@nist.gov; 'energyinterop@lists.oasis-open.org'
Subject: [energyinterop] Observations from the Appliance workshop

 

All,

 

I attended the EPRI “DR-Ready Appliance Workshop” yesterday in Knoxville, and the discussion ranged around appliance communications and action for demand response.

 

Basic agreement on what “smart grid ready” means:

·         Can shed

·         Can shift

·         Can communicate

·         Can understand SEP (or, as I observed, some standard data syntax and semantics and transport)—EPRI and U-SNAP are pushing for a standard connector that would allow plugging in an external comms chip. But you still need the app layer.

·         Security

 

Other observations:

·         Of course, how you accomplish the above for specific device classes (in different regions, see below) might need some definition when it comes time to do compliance testing. And what kind of signal are you going to feed an appliance to prove it can shed/shift, and how much? Maybe you need a standard forward price curve representative of different kinds of typical peaks. Maybe you need a standard forward mode signal, similar to what the DRAS feeds to the Simple Client in OpenADR.

·         Another model that was advocated (not by the appliance manufacturers nor by me) is having more/most of the intelligence at some EMS and passing a simpler signal to the appliance. To me, this requires communications from the appliance to the EMS (at least a standard energy profile) plus it requires a standard EMS.

·         I realized that there are perhaps limits on how universal appliances can be. DR programs have very real differences in different utility territories due to very real weather and regulatory differences. AC is all that matters in Phoenix (besides turning off pool pumps)—hot water is not an issue because water comes into the house hot. That won’t be the case in some other places. This came up relative to the question of whether appliance loads really matter. But a dryer and oven draw more power than the AC. And a refrigerator only draws 70W on average, but I have 3 and they run 24/7. So, how much does the regionality issue affect energy management algorithms for appliances? A rep from Daikin says they ship products that can go anywhere, just need the right software update to get tuned control algorithms.

·         Appliance manufacturers want to hear what it is worth to the grid. I can give you 5kW for 15 min, 2kW for an hour, 1 kW for 8 hours. What’s it worth to you? The appliance manufacturers haven’t gotten this data yet.

 

David Holmberg

NIST Building and Fire Research Lab

301-975-6450

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]