emix — archive

Prices Absolute, Relative, and Programmed...

From: Sean Crimmins <[email protected]>
To: [email protected]
Date: Thu, 04 Nov 2010 17:20:00 -0000















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:[email protected]]

Sent: Thursday, November 04, 2010 8:09 AM

To: [email protected]; Girish Ghatikar; Crimmins, Sean

Cc: [email protected]; [email protected]; 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

[email protected]">[email protected] 
|   www.xtensible.net











From: Toby Considine
[mailto:[email protected]] On Behalf Of Toby Considine

Sent: Wednesday, November 03, 2010 1:32 PM

To: 'Girish Ghatikar'; 'Crimmins, Sean'

Cc: [email protected]; [email protected];
'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: [email protected]

  Phone: (919)619-2104
  http://www.tcnine.com/

  blog: www.NewDaedalus.com
  
 






From: Girish Ghatikar [mailto:[email protected]]

Sent: Wednesday, November 03, 2010 1:12 PM

To: Crimmins, Sean

Cc: [email protected]; [email protected];
[email protected]; 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 <[email protected]> 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:[email protected]]
  On Behalf Of Toby Considine

  Sent: Wednesday, November 03, 2010 8:28 AM

  To: [email protected];
  [email protected]

  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: [email protected]
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

[email protected] | +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.
*********************************************************************************************