an attempt at fixing the 15m vs 1h resolutions (for now)

[wonko]

• made the timedelta dependant on the returned value
• added some basic tests

This should fix the missing data for now. This needs further tuning if there's ever a non-4-step-15m-interval. I might add that later this week, no time today ...

[wonko]

also

➜ ./bin/python -m unittest -v
test_be_60m (test.test_api_client.TestDocumentParsing.test_be_60m) ... ok
test_be_60m_15m_mix (test.test_api_client.TestDocumentParsing.test_be_60m_15m_mix) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.002s

OK

[Roeland54]

Here the german special case is not handled. They have 2 sets of data one 15min and one 60min. The 60min set is the one that needs to be parsed. That is why we ignored everything besides 60min before.

entsoe
or try this api call: https://web-api.tp.entsoe.eu/api?documentType=A44&securityToken=<SECRET>&periodStart=202410060000&periodEnd=202410071300&in_domain=10Y1001A1001A82H&out_domain=10Y1001A1001A82H

[wonko]

what's the preferred outcome in this case?

The code currently only deals with 1h intervals, so ...

• anything besides the 1h interval could be silently discarded?
• should the full-hour-value of the 60M take precedence over the 15M value? Or the other way around?

It seems there's no relation between the value for a certain point, an the hour-points in the 15m resolution (no average of either all hour-points, or some sliding window around the hour-mark) so a choice needs to be made.

Given the DE example above, there's

         <Period>
            <timeInterval>
              <start>2024-10-05T22:00Z</start>
              <end>2024-10-06T22:00Z</end>
            </timeInterval>
            <resolution>PT60M</resolution>
              <Point>
                <position>1</position>
                 <price.amount>67.04</price.amount>
              </Point>
              <Point>
                <position>2</position>
                 <price.amount>63.97</price.amount>
              </Point>
...

and

          <Period>
            <timeInterval>
              <start>2024-10-05T22:00Z</start>
              <end>2024-10-06T22:00Z</end>
            </timeInterval>
            <resolution>PT15M</resolution>
              <Point>
                <position>1</position>
                 <price.amount>98.1</price.amount>
              </Point>
              <Point>
                <position>2</position>
                 <price.amount>89.5</price.amount>
              </Point>
              <Point>
                <position>3</position>
                 <price.amount>77.21</price.amount>
              </Point>
              <Point>
                <position>4</position>
                 <price.amount>40.09</price.amount>
              </Point>
              <Point>
                <position>5</position>
                 <price.amount>87.2</price.amount>
              </Point>
              <Point>
                <position>6</position>
                 <price.amount>80.1</price.amount>
              </Point>
              <Point>
                <position>7</position>
                 <price.amount>75.3</price.amount>
              </Point>
              <Point>
                <position>8</position>
                 <price.amount>51.34</price.amount>
              </Point>
              <Point>
                <position>9</position>
                 <price.amount>76.8</price.amount>
              </Point>

There's no way to get the 63,97 value of 23:00 by using the datapoints in the 15m set (or I made some serious mistake).

[Roeland54]

anything besides the 1h interval could be silently discarded in the German case. The 15min data is some price from another electricity product. No idea what it really means. Except that we do not want it. ' day-ahead prices of the separate 10:15 auction of EXAA are also published under the filter “resolution=PT15M"

[wonko]

addressed that, prefers the 60M data, but takes 15M data if no 60M data is available (which keeps the oddball BE "bug" situation working).

Added the DE example as a test for this situation