-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved structure for Solar Time Varying Tariffs #624
Comments
+1 I see an original proposal for the Also doesn't make sense to have a plural name for only a single value 😛 |
PS - duplicate of #456 (comment) |
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 CRSummary:
"solarFeedInTariff" : [
{
"displayName": "Time-Varying - Option 1",
"description": "Victorian time-varying FIT",
"scheme": "Variable FiT",
"payerType": "GOVERNMENT",
"tariffUType": "timeVaryingTariffs",
"timeVaryingTariffs": [ // converted into an array
{
"type": "OFF_PEAK",
"displayName": "Overnight", // new mandatory field
"rates": [
{
"unitPrice": "0.113",
"measureUnit": "KWH"
}
],
"timeVariations": [
{
"days": [
"MON","TUE","WED","THU","FRI","SAT","SUN"
],
"startTime": "22:00",
"endTime": "07:00"
}
]
},
{
"type": "PEAK",
"displayName": "Day", // new mandatory field
"rates": [
{
"unitPrice": "0.044",
"measureUnit": "KWH"
}
],
"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 evening", // new mandatory field
"rates": [
{
"unitPrice": "0.093",
"measureUnit": "KWH"
}
],
"timeVariations": [
{
"days": [
"MON","TUE","WED","THU","FRI"
],
"startTime": "15:00",
"endTime": "21:00"
}
]
}
]
}
] Option 2 - Leverage existing standards to represent FiTSummary:
"solarFeedInTariff" :
[
{
"displayName": "Time-Varying - Option 1 - Day", // FiT rate options described here
"description": "Victorian time-varying FIT",
"scheme": "Variable FiT",
"payerType": "GOVERNMENT",
"tariffUType": "timeVaryingTariffs",
"timeVaryingTariffs":
{
"type": "OFF_PEAK",
"rates": [
{
"unitPrice": "0.113",
"measureUnit": "KWH"
}
],
"timeVariations": [
{
"days": [
"MON","TUE","WED","THU","FRI","SAT","SUN"
],
"startTime": "22:00",
"endTime": "07:00"
}
]
},
},
{
"displayName": "Time-Varying - Option 1 - Overnight", // FiT rate options described here
"description": "Victorian time-varying FIT",
"scheme": "Variable FiT",
"payerType": "GOVERNMENT",
"tariffUType": "timeVaryingTariffs",
"timeVaryingTariffs":
{
"type": "PEAK",
"rates": [
{
"unitPrice": "0.044",
"measureUnit": "KWH"
}
],
"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"
}
]
},
},
{
"displayName": "Time-Varying - Option 1 - Early evening", // FiT rate options described here
"description": "Victorian time-varying FIT",
"scheme": "Variable FiT",
"payerType": "GOVERNMENT",
"tariffUType": "timeVaryingTariffs",
"timeVaryingTariffs":
{
"type": "SHOULDER",
"rates": [
{
"unitPrice": "0.093",
"measureUnit": "KWH"
}
],
"timeVariations": [
{
"days": [
"MON","TUE","WED","THU","FRI"
],
"startTime": "15:00",
"endTime": "21:00"
}
]
},
}
] |
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. |
The AER support option 1. |
DEECA proposed and hence support option 1 |
@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 #625
|
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. |
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:
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 supports the proposal most recently posted proposal by @HemangCDR as we believe it is in the best interests of the ecosystem. |
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. |
The change has been staged and can be reviewed here: ConsumerDataStandardsAustralia/standards-staging@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
|
@HemangCDR The following are DEECA feedback on this.
|
@DannyDuong thank you for your comment. Please note the following response:
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.
This has been already been addressed as part of #625
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. |
Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18. |
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:
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:
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 #624 (comment)
The text was updated successfully, but these errors were encountered: