My view is that relative price is still price so belongs in
EMIX.
Program level and grid condition indicators are not price.
Do they travel alongside price? I think it is better that these signals
are independent. Consumers should be able to subscribe to the signals
that they’re interested in, having them parse a bucket of info has
several problems:
·
They have to parse much more info than they need.
·
The multiple data sets in the payloads change at different times
·
The structure of the payload will change much more frequently potentially
forcing redeployment of the services
Sean
From: Bruce Bartell
[mailto:]
Sent: Thursday, November 04, 2010 8:09 AM
To: ; Girish Ghatikar; Crimmins, Sean
Cc: ; ; Chiu,
Albert K
Subject: RE: [energyinterop] RE: [emix] Prices Absolute, Relative, and
Programmed...
If the only issue is that these requirements are considered totally
DR and hence, EI requirements, then I concur.
We will have to make sure they are included in the EI somewhere. I
have not had a chance to look into the items listed in detail and do not expect
to be on today’s call. Can we put this into the EI hopper for next week?
Bruce Bartell
Xtensible Solutions
Mobile: +1.321.258.6500
">
| www.xtensible.net
From: Toby Considine
[mailto:] On Behalf Of Toby Considine
Sent: Wednesday, November 03, 2010 1:32 PM
To: 'Girish Ghatikar'; 'Crimmins, Sean'
Cc: ; ;
'Chiu, Albert K'
Subject: RE: [energyinterop] RE: [emix] Prices Absolute, Relative, and
Programmed...
OK – but I need actionable information.
Questions (1)
1)
Is this a proposal that EMIX lose the Program level?
2)
Is this a proposal that EMIX lose the relative price?
Question (2)
So how do we communicate these things that are event
related…
3)
Do we create shadow objects to travel alongside EMIX
that communicate schedules for program information?
4)
Do we create shadow objects to travel alongside EMIX
that communicate schedules for relative price information?
For each of the above, we could use WS-Calendar exactly as
EMIX does.
It would be straightforward to vote “YES” on all
four. Doing so would push the shadow objects into EI and out of EMIX, which
could be a good thing.
We are at the point in these standards where editors need
clean and clear direction…
tc
"If something is not worth doing, it`s not worth doing
well" - Peter Drucker
Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of
Standards and Tech. Smart Grid Architecture Committee
Email:
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com
From: Girish Ghatikar [mailto:]
Sent: Wednesday, November 03, 2010 1:12 PM
To: Crimmins, Sean
Cc: ; ;
; Chiu, Albert K
Subject: Re: [energyinterop] RE: [emix] Prices Absolute, Relative, and
Programmed...
I second Sean.
-Rish
On Wed, Nov 3, 2010 at 9:15 AM, Crimmins, Sean <> wrote:
I would prefer EMIX stay focused on price and
product. If DR needs other types of messages, which it will, it can
design those. Program level and grid condition indicator are indexes
that are not always related to a price, they could be used to reduce demand
for reliability or in other cases where no price exists.
From: Toby
Considine [mailto:]
On Behalf Of Toby Considine
Sent: Wednesday, November 03, 2010 8:28 AM
To: ;
Cc: 'Chiu, Albert K'
Subject: [emix] Prices Absolute, Relative, and Programmed...
While
personally I would like pure economic signals and TEMIX as the model, the
OpenSG group provide *strong* guidance on two different approaches to DR in
the short term at least.. These are:
(1)
Price Relative. Price from 2-3 this afternoon is at 1.75 times the [well
known base price] [which may be different for different customers]
(2)
Program level. Appears in OpenADR 1.0 as High / Medium / Low. May need to
support “Real High” and “Real Low” as well.
Presents
two issues: (1) Where to communicate (EMIX or EI) and (2) How to communicate
Where
to communicate.
a)
As We may need to communicate a series of program levels and relative prices
varying over time, it must be EMIX.
b)
We need a suite of services to communicate context (Levels are based on a
scale of 1-7), (Base Price is $0.30/kWH) . The context service should be in
EI. EMIX may need to add context definitions.
(b)
How
to communicate “Market Calibration”. When I go down to Home Depot
and pick up my Home DRmation, I take it home, ask it to discover my house, it
asks me (energy provider, customer ID, …) and it queries the Energy
Provider / VTN” Tell me my context.
Price:
Perhaps
it looks like the standard info in the financials page:
Current
Price/ 30 day high, 30 day low, normal daily high, normal daily low
Relative
Price
GetBasePrice/SetBasePrice…
Program
Levels:
HowManyLevels,
NormalLevel, EmergencyCommandLevel (3,2,null) or (5,17,16)
(a)
In
WD13 of EMIX, price looks like:
<!-- 8.5 Price -->
<xs:complexType name="type-price">
<xs:choice>
<xs:element name="absolutePrice" type="xs:decimal"/>
<xs:element name="relativePrice" type="xs:float"/>
</xs:choice>
</xs:complexType>
It
could easily look like:
<!-- 8.5 Price -->
<xs:complexType name="type-price">
<xs:choice>
<xs:element name="absolutePrice" type="xs:decimal"/>
<xs:element name="relativePrice" type="xs:float"/>
<xs:element name="programLevel" type="xs:int"/>
</xs:choice>
</xs:complexType>
Alternately,
we could create
<!-- 8.5a ProgramSignal -->
<xs:complexType name="type-programSignal">
<xs:sequence>
<xs:element name="programLevel" type="xs:int"/>
<xs:element name="programMax" type="xs:int"/>
</xs:sequence>
</xs:complexType>
And
then send fuller information to the customer as in:
<!-- 8.5 Price -->
<xs:complexType name="type-price">
<xs:sequence
maxOccurrs="1">
<xs:choice>
<xs:element name="absolutePrice" type="xs:decimal"/>
<xs:element name="relativePrice" type="xs:float"/>
</xs:choice>
<xs:element name="programLevel" type="emix:xemix:type-programSignal" />
</xs:complexType>
Clearly
that last XML is not valid, but it is sent as a conversation starter. By
defining this as price in this way, it fits into all existing EMIX products.
WEQ quadrants can then conform some of these away.
Discuss….
tc
“It
is difficult to get a man to understand something, when his salary depends
upon his not understanding it” -- Upton Sinclair.
Toby Considine
TC9, Inc
OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart
Grid Architecture Committee
Email:
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com
*********************************************************************************************
The foregoing electronic message, together with any attachments thereto, is
confidential and may be legally privileged against disclosure other than to
the intended recipient. It is intended solely for the addressee(s) and access
to the message by anyone else is unauthorized. If you are not the intended
recipient of this electronic message, you are hereby notified that any
dissemination, distribution, or any action taken or omitted to be taken in
reliance on it is strictly prohibited and may be unlawful. If you have
received this electronic message in error, please delete and immediately
notify the sender of this error.
*********************************************************************************************
--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
| +1 510.486.6768 | +1
510.486.4089 [fax]
This email is intended for the addressee only and may contain confidential
information and should not be copied without permission. If you are not the
intended recipient, please contact the sender as soon as possible and delete
the email from computer[s].
*********************************************************************************************
The foregoing electronic message, together with any attachments thereto, is confidential and may be legally privileged against disclosure other than to the intended recipient. It is intended solely for the addressee(s) and access to the message by anyone else is unauthorized. If you are not the intended recipient of this electronic message, you are hereby notified that any dissemination, distribution, or any action taken or omitted to be taken in reliance on it is strictly prohibited and may be unlawful. If you have received this electronic message in error, please delete and immediately notify the sender of this error.
*********************************************************************************************
