-
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
Multiple missing values from mandatory fields served by AEMO APIs #597
Comments
This issue is something we have also ran into over the last few weeks which has led to some design choices to relax data validation for specific attributes, which is not ideal. It would be great to have better guidance on the standards for Open Energy and how they have been implemented by the different agents. I would only suggest that the 2nd proposal of dummy output also contains some other identifying attribute to ignore the invalid values. |
Thank you for advising us of the missing distributionLossFactor fields. Regarding the missing DER commissioningDate values, our analysis has indicated that these are only missing where there is no DER present (which is in approximately 80% of NMIs/SPs) and therefore no commissioning. AEMO has been operating under #526 which addressed the handling of these instances, since November 2022. |
The issue regarding
Based on the information we have, there does not seem to be any changes required to the standards. But if more information is provided, the issue can be revisited. |
As recently as today we continue to observe invalid payloads from AEMO, notably a set of To be clear the AEMO payload is neither complying with the Standards ( Again, we request a change to make this field optional as it appears to impact a vast majority of records (80%+) and is causing ongoing operational issues for which AEMO does not appear to be providing relief. We are caught between receiving invalid data from the Market Operator yet having an obligation to pass compliant responses to Data Recipients. |
Thank you for the notification. An issue has been identified with the DER Register API. The team are currently working on remediation at the moment. We will update this thread once the fix has been applied. |
Hi @Justin-AEMO. Just checking in on whether there is a target date for remediation? Thanks. |
Planned fix for DER register API to be applied 20 August 2023. |
Great. Thanks for your prompt response @Justin-AEMO. |
Issue has been closed |
Description
The AEMO APIs are serving payloads which are non-compliant with respect to the Data Standards. This results in validation errors as the response is passed from AEMO side to the Recipient side resulting in a holder either:
a) Responding to the Recipient with an Unexpected Error with
isSecondaryDataHolder
set totrue
b) The Holder presenting a schema invalid payload because the SDH provided an incorrect one
When requesting a solution from AEMO the response has been to request the Retailer request the upstream provider (i.e. the metering provider) to update the requested data. This is neither scalable nor sustainable and ultimately is placing unreasonable pressure on the entire CDR workflow because a mandated holder is failing to deliver schema validated payloads.
Area Affected
We have identified at least the following fields which have this issue:
EnergyServicePointDetail.distributionLossFactor
EnergyElectricityACConnectionV1.commissioningDate
Change Proposed
A few solutions:
The text was updated successfully, but these errors were encountered: