search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

Improved structure for Solar Time Varying Tariffs #624

Closed DannyDuong closed 2 months ago

DannyDuong commented 6 months ago

Description

Time Varying Tariffs for Solar Feed-In Tariffs are relatively new and were introduced as part of EnergyPlanResponseV2. In Victoria, one offer/plan, can have up to 4 solarFeedInTariff objects, to cater for different solar policies: • Premium FiT • Current FiT • Variable FiT – option 1 • Variable FiT – option 2

It’s important for the data standards to facilitate all the items relating to a given Solar FiT policy in the same object.

For reference, in Victoria, the approved Feed-in Tariff structures and rates for 2023–24 are below:

image

Source: Essential Services Commission website, https://www.esc.vic.gov.au/electricity-and-gas/prices-tariffs-and-benchmarks/minimum-feed-tariff/minimum-feed-tariff-review-2023-24, accessed 16 May 2023.

Area Affected

The EnergyPlanResponseV2 response payload for the Get Generic Plan Detail API.

The following are key requirements regarding standards for the Solar Tariff:

  1. Each solarFeedInTariff to be a full tariff, i.e. it covers 24hrs by 7 days for Solar FiT with multiple rates with different time periods.
  2. In addition, all the items relating to this tariff should be kept in the same object – e.g. Overnight, Day and Early evening are different tariffs (timeVaryingTariffs) for the same variable Solar FiT object.

It is important, that the data standards can support an offer having multiple Solar FiT policies, and each Solar FiT policies may have multiple rates with different time periods. The current standard does not support this, and hence the need for this CR.

The work-around using the current standards may be possible, but it would lead to: • be a very confusing and incorrect way to represent timeVaryingTariffs, as they are not nested at the right level • could have a flow-on effect on anyone consuming the CDR offer data • result in duplication of implementation costs to develop with this work-around and then to correct it later

Change Proposed

DEECA propose a CR to change the timeVaryingTariffs from an object to be an array of objects to cater for the three set of timebands and rates. This change will facilitate the data standards to support an offer having multiple Solar FiT policies, and each Solar FiT policies may have multiple rates with different time periods.

In addition, a timeVaryingTariffs.displayName field is required to describe each object in the timeVaryingTariffs array. Note: This is separate from the timeVaryingTariffs.type field which is a generic Peak, Off-Peak and Shoulder

Refer to the following sample payload solarFeedInTariff_example_nested.jsonc

DSB Proposed Solution

The proposed solution can be found through the staging link provided in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/624#issuecomment-2019888328

mattyp commented 5 months ago

+1

I see an original proposal for the timeVaryingTariffs has it as an array, so I am guessing it was accidently converted to a single object somewhere along the implementation journey.

Also doesn't make sense to have a plural name for only a single value 😛

mattyp commented 5 months ago

PS - duplicate of https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/456#issue-1097434652

HemangCDR commented 4 months ago

After the discussion in today's MI call (February 2), I've pulled out the example from the file linked in the original CR comment and labeled it as option 1, making some minor adjustments for clarity. @Dannyduong, please correct are inaccuracies or mistakes I may have made.

I've also noted an alternative option 2 for consideration. Feedback on both these options along with any alternative suggestions are welcome.

Option 1 - Original proposal in CR

Summary:

Option 2 - Leverage existing standards to represent FiT

Summary:

mattyp commented 4 months ago

Option 1 ✅. It’s a shame a bug fix is a breaking change, but best to just fix it up, get it right and move onto the next bug.

Jacqui-AER commented 4 months ago

The AER support option 1.

DannyDuong commented 4 months ago

DEECA proposed and hence support option 1

DannyDuong commented 4 months ago

@HemangCDR I've included a revised file and have pasted the content below - which should replace the Option 1 that you have posted above.

It is largely the same as the initial file that I've shared, but for completeness, I've included the "period" and "volume" fields to ensure that it supports the step tariff linked to this ticket here https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/625

"solarFeedInTariff" : [
    {
        "displayName": "Time-Varying - Option 1",
        "description": "Victorian time-varying FIT",
        "scheme": "Variable FiT",
        "payerType": "GOVERNMENT",
        "tariffUType": "timeVaryingTariffs",
        "period": "string",
        "timeVaryingTariffs": [
        {
            "type": "PEAK", 
            "displayName": "Overnight",
            "rates": [
                {
                    "unitPrice": "0.113",
                    "measureUnit": "KWH",
                    "volume": 0
                }
            ],
            "timeVariations": [
                {
                    "days": ["MON","TUE","WED","THU","FRI","SAT","SUN"],
                    "startTime": "22:00", 
                    "endTime": "07:00" 
                }
            ]
        },
        {
            "type": "OFFPEAK", 
            "displayName": "Day",
            "rates": [
                {
                    "unitPrice": "0.044",
                    "measureUnit": "KWH",
                    "volume": 0
                }
            ],
            "timeVariations": [
                {
                    "days": ["MON","TUE","WED","THU","FRI"],
                    "startTime": "07:00", 
                    "endTime": "15:00"
                },
                {
                    "days": ["MON","TUE","WED","THU","FRI"],
                    "startTime": "21:00",
                    "endTime": "22:00" 
                },
                {
                    "days": ["SAT","SUN"],
                    "startTime": "07:00", 
                    "endTime": "22:00" 
                }
            ]
        },
        {
            "type": "SHOULDER", 
        "displayName": "Early Evenning",
            "rates": [
                {
                    "unitPrice": "0.093",
                    "measureUnit": "KWH",
                    "volume": 0
                }
            ],
            "timeVariations": [
                {
                    "days": ["MON","TUE","WED","THU","FRI"],
                    "startTime": "15:00", 
                    "endTime": "21:00"
                }
            ]
        }
    ]
    }
]

solarFeedInTariff_example - DEECA Feb 2024.jsonc

AGL-CDR commented 3 months ago

Should this item be accepted, we will need at least six months lead time, starting from the date that final standards are published. With that in mind, we propose a FDO of early December.

HemangCDR commented 3 months ago

Noting the feedback recieved thus far, and as per the action noted during the MI call on March 20, below is the proposed solution (i.e. option 1 in this comment) for this CR:

It consists of the following changes:

  1. Convert solarFeedInTariff.timeVaringTariffs into an array to allow representation of multiple feed in tariff for a given plan 2. Incorporate the new tariff types noted in the essential services review by extending the solarFeedInTariff.timeVaryingTariffs.type ENUM.
  2. Add new displayName field as per original proposal. This is based on feedback received during MI call on 3rd April noting that it aligns with other time of use structures and gives DHs the flexibility as the use custom names.
  3. Add new ENUM values VARIABLE and CURRENT to solarFeedInTariff.scheme. Refer to this comment for clarification.
  4. The FDO date of 11/11/2024 is recommended, which is the last obligation date noted in the obligation date schedule. This is in alignment with the FDO of other energy CRs being discussed in this MI.

The changes would appear as below:

"solarFeedInTariff": [
  {
    "displayName": "string",
    "description": "string",
    "startDate": "string",
    "endDate": "string",
    "scheme": ["PREMIUM", "VARIABLE", "CURRENT", "OTHER"] // new VARIABLE and CURRENT ENUM values
    "payerType": "GOVERNMENT",
    "tariffUType": "singleTariff",
    "singleTariff": {
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0
        }
      ]
    },
    "timeVaryingTariffs": [ //converted into array of objects
        {
          "type": ["PEAK", "OFF_PEAK", "SHOULDER"],
          "displayName" : "string", // new mandatory field
          "rates": [
            {
              "unitPrice": "string",
              "measureUnit": "KWH",
              "volume": 0
            }
          ],
          "timeVariations": [
            {
              "days": [
                "SUN"
              ],
              "startTime": "string",
              "endTime": "string"
            }
          ]
        }
    ]
  }
]

Feedback on the above is welcome.

biza-io commented 3 months ago

Biza.io supports the proposal most recently posted proposal by @HemangCDR as we believe it is in the best interests of the ecosystem.

CDR-API-Stream commented 2 months ago

Note the proposed solution has been updated based on feedback received on the MI call held on 3rd April.

Specifically:

If no further feedback is received, it will be recommended to the Chair for review and approval.

CDR-API-Stream commented 2 months ago

The change has been staged and can be reviewed here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.30.0...maintenance/624

Note: The retirement date for the following endpoints impacted as a result of this change has been set to September 8th 2025

DannyDuong commented 2 months ago

Noting the feedback recieved thus far, and as per the action noted during the MI call on March 20, below is the proposed solution (i.e. option 1 in this comment) for this CR:

It consists of the following changes:

  1. Convert solarFeedInTariff.timeVaringTariffs into an array to allow representation of multiple feed in tariff for a given plan ~2. Incorporate the new tariff types noted in the essential services review by extending the solarFeedInTariff.timeVaryingTariffs.type ENUM.~
  2. Add new displayName field as per original proposal. This is based on feedback received during MI call on 3rd April noting that it aligns with other time of use structures and gives DHs the flexibility as the use custom names.
  3. The FDO date of 11/11/2024 is recommended, which is the last obligation date noted in the obligation date schedule. This is in alignment with the FDO of other energy CRs being discussed in this MI.

The changes would appear as below:

"solarFeedInTariff": [
  {
    "displayName": "string",
    "description": "string",
    "startDate": "string",
    "endDate": "string",
    "scheme": "PREMIUM",
    "payerType": "GOVERNMENT",
    "tariffUType": "singleTariff",
    "singleTariff": {
      "rates": [
        {
          "unitPrice": "string",
          "measureUnit": "KWH",
          "volume": 0
        }
      ]
    },
    "timeVaryingTariffs": [ //converted into array of objects
        {
          "type": ["PEAK", "OFF_PEAK", "SHOULDER"],
          "displayName" : "string", // new mandatory field
          "rates": [
            {
              "unitPrice": "string",
              "measureUnit": "KWH",
              "volume": 0
            }
          ],
          "timeVariations": [
            {
              "days": [
                "SUN"
              ],
              "startTime": "string",
              "endTime": "string"
            }
          ]
        }
    ]
  }
]

Feedback on the above is welcome.

@HemangCDR The following are DEECA feedback on this.

  1. "scheme": ["PREMIUM", "OTHER", "CURRENT", "VARIABLE"], // Adding CURRENT and VARIABLE for clarity, otherwise they will be treated as OTHER
  2. "period": "string", // the period field should be added here for completeness, at the same level as tariffUType. This is link to https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/625
  3. I'm assuming that the standards nesting structure support the example "Time-Varying - Option 1" that was provided above
CDR-API-Stream commented 2 months ago

@DannyDuong thank you for your comment. Please note the following response:

  1. "scheme": ["PREMIUM", "OTHER", "CURRENT", "VARIABLE"], // Adding CURRENT and VARIABLE for clarity, otherwise they will be treated as OTHER

This is a good pickup and can be included as part of this change noting that this was implied in the original proposal. The proposed solution has been updated to reflect this.

  1. "period": "string", // the period field should be added here for completeness, at the same level as tariffUType. This is link to Additional field to support Step Tariff calculations #625

This has been already been addressed as part of #625

  1. I'm assuming that the standards nesting structure support the example "Time-Varying - Option 1" that was provided above

That is correct.

The above was discussed in the MI19 call today (17th April) and participants supported introducing the two ENUM values as part of this change and MI18 for Chair approval. The staged changes will be updated to reflect this.

nils-work commented 2 months ago

Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.