Uploaded image for project: 'OASIS Energy Interoperation TC'
  1. OASIS Energy Interoperation TC
  2. ENERGYINTEROP-515 Collector for OpenADR Alliance Comments EI PR02
  3. ENERGYINTEROP-513

The eiCreateAvailPayload has one confusing issue: It is our understanding that the VEN would specify the behavior characteristic (Force, etc) but behavior does not appear in the create payload.

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: No Action
    • Affects Version/s: wd27
    • Fix Version/s: wd32
    • Component/s: model, schema
    • Labels:
      None
    • Environment:

      OpenADR

    • Proposal:
      Hide

      No action required.

      Show
      No action required.

      Description

      The eiCreateAvailPayload has one confusing issue: It is our understanding that the VEN would specify the behavior characteristic (Force, etc) but behavior does not appear in the create payload. Oddly it does get returned in eiCreatedAvailPayload. It doesn't seem to make sense that the OpenADR Alliance Comments on EI v1.0, July 8, 2011 Page | 3 VTN would dictate how events get mapped to the VENs availability schedule. More description is needed.

      NOTE 20111002: Per ENERGYINTEROP-512 "Force" has been removed from the enumeration.

      NOTE 20111025: The EiAvailBehaviorType is in EiAvailType, and is sent by the VEN to the VTN. This appears to address the issue. The response (EiCreatedAvail) returns an AvailID.

        Attachments

          Activity

          Hide
          william.cox William Cox (Inactive) added a comment - - edited

          ENERGYINTEROP-512 as applied eliminates Force from the enumeration.

          This behavior may be defined in the program, which would suggest in the StandardTerms for the marketContext, or it may be done by the VEN as needed. The behavior needs to be unambiguous.

          Show
          william.cox William Cox (Inactive) added a comment - - edited ENERGYINTEROP-512 as applied eliminates Force from the enumeration. This behavior may be defined in the program, which would suggest in the StandardTerms for the marketContext, or it may be done by the VEN as needed. The behavior needs to be unambiguous.
          Hide
          gghatikar Girish Ghatikar (Inactive) added a comment -

          The need for the action for "FORCE" or others such as "ACCEPT, REJECT, or RESTRICT" came from OpenADR 1.0 program constraints, which as mapped into others in EI as Avail, etc. The idea behind force is to make sure the VEN makes the intention clear that it would force the set of restrictions that are pre-configured (that's part of EI) are respected and it can only participate only outside of those conditions. From my perspective, I think it's an important requirements for the VEN, unless I am missing something.

          I think the question originated more from the fact that such VEN behavior characteristic exist only in the EiCreatedAvailPayload and not the the EiCreateAvailPayload and not if this or a set of actions are needed or not. The resolution would be to simply add it.

          Show
          gghatikar Girish Ghatikar (Inactive) added a comment - The need for the action for "FORCE" or others such as "ACCEPT, REJECT, or RESTRICT" came from OpenADR 1.0 program constraints, which as mapped into others in EI as Avail, etc. The idea behind force is to make sure the VEN makes the intention clear that it would force the set of restrictions that are pre-configured (that's part of EI) are respected and it can only participate only outside of those conditions. From my perspective, I think it's an important requirements for the VEN, unless I am missing something. I think the question originated more from the fact that such VEN behavior characteristic exist only in the EiCreatedAvailPayload and not the the EiCreateAvailPayload and not if this or a set of actions are needed or not. The resolution would be to simply add it.
          Hide
          william.cox William Cox (Inactive) added a comment -

          Closed at EITC meeting 20111026.

          Show
          william.cox William Cox (Inactive) added a comment - Closed at EITC meeting 20111026.
          Hide
          william.cox William Cox (Inactive) added a comment -

          Closed at EITC meeting 20111026.

          Show
          william.cox William Cox (Inactive) added a comment - Closed at EITC meeting 20111026.

            People

            • Assignee:
              william.cox William Cox (Inactive)
              Reporter:
              toby.considine Toby Considine (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: