[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] Prices Absolute, Relative, and Programmed...
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:tobyconsidine@gmail.com] On Behalf Of Toby Considine 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.
| |||
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]