-
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
Modify Energy Plans structure to allow Time of Use based Controlled Load rates #472
Comments
Please find below the response on proposed structure.
Thanks, |
If a site has two separate controlled load meter, there can be two different controlled load rates. As this controlled load section is not an array, we can specify only one controlled load rate. Can you please assess the proposed structure to allow us specifying rate for more than one controlled load (i.e Controlled Load 1 & Controlled Load 2). Thanks, |
@Kingson-EA thank you for your feedback.
We can include the start and end date as optional attributes.
As mentioned in the previous MI call, we will raise a separate CR to consult for consistent representation of ENUM values for 'days' across sectors and within energy endpoints
This is good feedback. Is it also worth considering including an optional meterId attribute to specify which meter the controlled load rates apply to? Alternatively, the meter information can be captured in a description attribute. |
Below is the updated controlloedLoad schema incorporating feedback received throughout maintenance iteration 10. The DSB recommends the change to adopted. {
"controlledLoad": [ //controlledLoad is an array
{
"displayName": "string",
"rateBlockUType": [ "singleRate | timeOfUseRates" ], //Attribute to specify rate type
"startDate": "DateString", //optional
"endDate": "DateString", //optional
"singleRate": {
"displayName": "string",
"description": "string",
"dailySupplyCharge": "AmountString",
"period": "string", //Formatted according to ISO 8601 Durations (excludes recurrence syntax)
"rates": [
{
"unitPrice": "AmountString",
"measureUnit": [ "KWH | KVA | KVAR| KVARH | KW | DAYS | METER | MONTH" ],
"volume": "number"
}
]
},
"timeOfUseRates": [ //Object to capture Time of Use based Controlled Load rates
{
"displayName": "string",
"description": "string",
"dailySupplyCharge": "AmountString",
"rates": [
{
"unitPrice": "AmountString",
"measureUnit": [ "KWH | KVA | KVAR| KVARH | KW | DAYS | METER | MONTH" ],
"volume": "number"
}
],
"timeOfUse": [
{
"days": ["SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, BUSINESS_DAYS"],
"startTime": "string", //Start of the period in HHMM format using 24 hour clock format
"endTime": "string" //End of the period in HHMM format using 24 hour clock format
}
],
// I don't believe that SHOULDER is available in the market, but I've included it for consistency with EnergyPlanTariffPeriod
"type": [ "PEAK | OFF_PEAK | SHOULDER" ]
}
]
}
]
} |
This proposal seeks to force the adoption of a non-standard time format beyond the "existing data sources" and inherits a lack of precision in the process. A number of justifications for this were given from the call:
Further AER doesn't supply this specific addition (ie. it isn't existing data), the parsing of this value requires not only industry specific knowledge (eg. is this UTC? Is it location based? How does one actually use it) but also the specification of the data format and specification supplied to AER by retailers doesn't seem to be easily accessible (where is it actually published? Does someone know?). As per the call, my opinion (and the general opinion of Biza.io and possibly any sane engineer who has ever had to do time math) would be to align, wherever possible, with CDR Data Types. These Data Types were specifically defined, hard fought, in many cases to the chagrin of purists who said "Use Native Types" (Me included). Not defaulting to these in essence diminishes the value produced by being divergent from natives in the first place and instead creates an implied The only reasonable justification to do otherwise seems to be a like for like transform from an existing data source - this has tacit acceptance although no defined Standards principle (literally nothing in the principles explicitly supports this pathway). More broadly speaking this justification should be assessed as, with multiple industries in multiple formats, the implementation of defining endlessly variant ways of time, dates, decimals, currencies etc. with variable levels of precision introduces a significant technical debt problem for implementers of CDR itself and will inevitably result in transformation issues between participants. Finally, on Principles, here's a list that seems to not be aligned:
|
Thank you for the feedback @perlboy. There a couple of points worth reiterating/clarifying:
Uplifting time of use to be better while still being consistent across the payloads is an important discussion. As a result, and as mentioned during the MI call, the DSB will raise a CR to consult separately on how time is represented within EnergyPlanSchema. For this CR, however, we believe that the current proposed solution is more appropriate and will be recommending this to Chair for incorporation into 1.17.0. |
Ok then I misunderstood what was stated on the call. This would suggest the original payloads did not provide coverage for the AER data to begin with. Since it is apparent the Generic Plans APIs may be deficient for presentation of existing AER data it's worthwhile evaluating the examples more deeply.
Great.
Sure although the proposed solution doesn't seem to cover all the use cases.... |
Given the feedback from @perlboy, we suggest the following two options to progress this CR: Option 1 - Resolve this CR in current MI10 incorporating the solution recommended as per this comment in v1.17.0 of the standards. This could give a baseline to anyone already implementing this specific component. The baseline can be further refined (e.g. include more ENUM values) with separate CRs in future MIs to cater for any remaining use cases. Option 2 - Carry over and resolve this CR in the next MI (which starts next week on 27th April) to discuss and address the above feedback. Any feedback on the above two options would be appreciated. We can table this as part of the grooming session at the start of MI11. |
So, I went digging into EME and there seems to be quite a few more things worth investigating. These are noteworthy particularly in the context of "existing data sources" but also in the handling of time, dates, days and currency for Energy endpoints. I've provided links to the individual JSONs used for this info. These all matter because beyond AER data Retailers are now expected to present contract data in response to Energy Account Details. Maybe this is the feeder for other items but I'll put it here for now because it does relate to the original change request on time of use tariffs and matching those to AER data.
By way of examples, here is some info from the sources provided below:
Sourceshttps://api.energymadeeasy.gov.au/plans/dpids/RED207686MRE4 |
The EME team in collaboration with the DSB provided the initial design for the ToU Controlled Load proposal, however, @perlboy has quite rightly highlighted the need for further consultation on this design to ensure that retailer products can be adequately represented by the Standards. Acknowledging @perlboy's investigative efforts into the EME API, it's worth noting that this endpoint is specifically designed to service the EME UI, only exposes a limited amount of data for that purpose, and that this data should in no way be interpreted as the AER's CDR PRD. The AER is building CDR PRD endpoints that will expose EME and Victorian Energy Compare (VEC) product data transformed to conform with the Standards. Some of @perlboy's insights from his investigation do warrant further discussion, but not here. I will tackle them in separate proposals. |
Thanks Joe and totally agree. To clarify our primary interest in this analysis actually relates to the Account Detail components that reuse the Product Data payloads in those payloads primarily because there is a data transform component related to things like "Business Days" (which week by week is challenging). As per a previous reply:
I would have preferred to use the input format supplied by retailers to AER when analysing this but it didn't seem to be available - is that something you could provide a link to? |
Unfortunately Stuart, the EME data specification document is only available to authorised energy retailers. |
That's interesting because I would have thought as a Government agency unless there was some national security or confidentiality requirement such a document would be in the public interest especially since the justification for adoption of certain data types within the Standards is on the basis of existing data formats. |
Below points summarise the above feedback that was discussed in today's MI11 call:
|
The DSB would like to propose the following changes to address point 1 and 2 in the above comment:
The combination of change 2 and 3 should allow specifying controlled load plans where details of time of use are not known and contain description such as:
Below is the revised controlloedLoad schema: {
"controlledLoad": [ //controlledLoad is an array
{
"displayName": "string",
"rateBlockUType": ["singleRate","timeOfUseRates"], //Attribute to specify rate type
"startDate": "DateString", //optional
"endDate": "DateString", //optional
"singleRate": {
"displayName": "string",
"description": "string",
"dailySupplyCharge": "AmountString",
"period": "string", //Formatted according to ISO 8601 Durations (excludes recurrence syntax)
"rates": [
{
"unitPrice": "AmountString",
"measureUnit": ["KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH" ],
"volume": "number"
}
]
},
"timeOfUseRates": [ //Object to capture Time of Use based Controlled Load rates
{
"displayName": "string",
"description": "string",
"dailySupplyCharge": "AmountString",
"rates": [
{
"unitPrice": "AmountString",
"measureUnit": ["KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH" ],
"volume": "number"
}
],
"timeOfUse": [
{
"days": ["SUNDAY", "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY", "SATURDAY", "BUSINESS_DAYS"], //Make attribute optional. NOTE: The ENUM values will be aligned to agreed decision in CR 502
"startTime": "string", //Make attribute optional. NOTE: The type of this attribute will be aligned to agreed decision in CR 505
"endTime": "string", //Make attribute optional. NOTE: The type of this attribute will be aligned to agreed decision in CR 505
"additionalInfo" : "string", //Optional free text attribute to describe controlled load availability if specific day/time is not known
"additionalInfoUri" : "string" //Optional attribute to provide link to web page with additional information
}
],
"type": [ "PEAK | OFF_PEAK | SHOULDER | SOLAR_SPONGE" ] // added SOLAR_SPONGE
}
]
}
]
} Feedback is welcome on the above recommended changes. |
Following feedback received during Energy MI call on 14th June, the DSB discussed the structure internally and notes that the Below is the updated structure: {
"controlledLoad": [ //controlledLoad is an array
{
"displayName": "string",
"rateBlockUType": ["singleRate","timeOfUseRates"], //Attribute to specify rate type
"startDate": "DateString", //optional
"endDate": "DateString", //optional
"singleRate": {
"displayName": "string",
"description": "string",
"dailySupplyCharge": "AmountString",
"rates": [
{
"unitPrice": "AmountString",
"measureUnit": ["KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH" ],
"volume": "number"
}
]
},
"timeOfUseRates": [ //Object to capture Time of Use based Controlled Load rates
{
"displayName": "string",
"description": "string",
"dailySupplyCharge": "AmountString",
"rates": [
{
"unitPrice": "AmountString",
"measureUnit": ["KWH", "KVA", "KVAR", "KVARH", "KW", "DAYS", "METER", "MONTH" ],
"volume": "number"
}
],
"timeOfUse": [
{
"days": ["SUNDAY", "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY", "SATURDAY", "BUSINESS_DAYS"], //Make attribute optional. NOTE: The ENUM values will be aligned to agreed decision in CR 502
"startTime": "string", //Make attribute optional. NOTE: The type of this attribute will be aligned to agreed decision in CR 505
"endTime": "string", //Make attribute optional. NOTE: The type of this attribute will be aligned to agreed decision in CR 505
"additionalInfo" : "string", //Optional free text attribute to describe controlled load availability if specific day/time is not known
"additionalInfoUri" : "string" //Optional attribute to provide link to web page with additional information
}
],
"type": [ "PEAK | OFF_PEAK | SHOULDER | SOLAR_SPONGE" ] // added SOLAR_SPONGE
}
]
}
]
} If no further feedback is received, the DSB will recommend the above change to the Chair for approval. Note: The ENUM values of |
This issue has been staged and can be reviewed here - ConsumerDataStandardsAustralia/standards-staging@release/1.18.0...maintenance/472 |
This change was incorporated into release v1.18.0. Refer to Decision 249 for further details. |
Description
Controlled Load rates can be fixed or based on time of use (e.g. different controlled load rates for peak vs off-peak). This change request is being created to modify the structure to cater for Controlled load Time of Use rates as current controlledLoad object does not cater it.
Area Affected
Following Energy APIs are affected
Change Proposed
The following change is proposed to the controlledLoad object to cater for TOU based controlled load rates:
The text was updated successfully, but these errors were encountered: