Closed MarcinKonowalczyk closed 4 months ago
Hi @MarcinKonowalczyk,
Firstly, let's just consider the records from the file that you uploaded that affect settlement period 13 (06:00-06:30). Note that I've also removed a couple of irrelevant fields for simplicity:
{
"timeReceived": "2024-03-14T05:02:18.901Z",
"records": [
{
"timeFrom": "2024-03-14T05:02:00.000Z",
"timeTo": "2024-03-14T06:30:00.000Z",
"levelFrom": 9,
"levelTo": 9,
"notificationTime": "2024-03-14T05:00:37.000Z",
"notificationSequence": 119982506,
}
]
},
{
"timeReceived": "2024-03-14T05:02:18.927Z",
"records": [
{
"timeFrom": "2024-03-14T06:00:00.000Z",
"timeTo": "2024-03-14T06:30:00.000Z",
"levelFrom": 8,
"levelTo": 8,
"notificationTime": "2024-03-14T03:23:31.000Z",
"notificationSequence": 119979425,
}
]
},
May I ask:
2__BBPGM001_MELS.json
) come from? Is this perhaps data from your IRIS client?timeReceived
the time that your client received that data from IRIS?timeReceived
to determine which of the records should be used in the final output of "stitched" data?The reason I ask is because it looks like the two files which each contained one of the above two records were sent out over IRIS in a potentially misleading order. The second record above (sequence 119979425) was delivered over IRIS seven seconds before the first record (sequence 119982506). However, the order in which files are sent over IRIS is not guaranteed to be the same as the order of precedence. In the case of MILS and MELS, the NotificationSequence
field should be used to determine precedence, so because 119982506 > 119979425, the level value for settlement period 13 should be 9, not 8.
Following issue #21, here is another case where i seem to be unable to reproduce the MELS data as published on the website. I submit this as another issue as I believe the cause might be different.
The unit of interest here is 2BBPGM001 between the times 14/03/2024 04:30 -> 07:30. The data from the website can be seen [here](https://bmrs.elexon.co.uk/balancing-mechanism-bmu-view?bmuId=2BBPGM001&activeTab=Physical&startDate=2024-03-14T04%3A30%3A00.000Z&endDate=2024-03-14T07%3A30%3A00.000Z) and in the screenshot below.
As opposed to issue #21 where I don't understand how the instruction in question translates into the "stitched" data, here the instruction in question appears to have been delivered arrive late and it therefore improperly contributes to the overall MELS.
screenshots
MELS on elexon website:
MELS put together from the messages
records
2__BBPGM001_MELS.json