-
-
Notifications
You must be signed in to change notification settings - Fork 678
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
Entsoe error for Belgium: PT60M slots no longer available #16519
Comments
I can confirm I have exactly the same issue today. |
Api issue, not evcc. |
Yes It is an API error, but why does EVCC not remember the values? |
Because its usually not required. |
can we get more specific on the issue here so I can contact entsoe support? |
I like to reopen the issue, as entsoe has made changes for Belgian users. See the issue here: |
Can you please share an API request (or config) and response for Belgium? Given evcc works in 60m slots right now the next question is how we should handle 15m slots: just take the first? use the average? or the maximum? |
I will check tonight. But there are no 15M slots in Belgium, and I have not read anywhere that this will implemented in the near future. So we could use the first one (or average) for the time being. |
I don't think it's limited to Belgium users. For Germany I also do have problems to get the prices, although with a different error message. To my understanding EVCC requires an update because of entsoe API changes within the last week. As a workaround I just switched to Fraunhofer. |
This is an example request and response with some 15M data entries:
Notice that the 15M time intervals only give an update every 4 blocks, which actually results in "hourly" updates. The API states that if a certain point isn't supplied with CurveType A3, the previous block value is repeated for the missing block. Hope this helps. |
Repost:dear all, entsoe-py maintainer dropping in. Sorry to hear you had to build your own implementation due to pandas issue. for the future it is important to note that the SDAC will go to 15 min resolution somewhere Q1 or Q2 2025. This means that you will need the 15 min parser eventually since ALL countries will swap their day ahead prices to that resolution at the same time. |
So the belgian data is a bug. But the api response format from entso-e has changed with an update last friday. So a fix to parse the new format is still needed to get it back up and running for other countries. A few differences with the old format:
This is a valid response for Portugal: <Publication_MarketDocument xmlns="urn:iec62325.351:tc57wg16:451-3:publicationdocument:7:3">
<mRID>df5f07320f074c369d60428641fed537</mRID>
<revisionNumber>1</revisionNumber>
<type>A44</type>
<sender_MarketParticipant.mRID codingScheme="A01">10X1001A1001A450</sender_MarketParticipant.mRID>
<sender_MarketParticipant.marketRole.type>A32</sender_MarketParticipant.marketRole.type>
<receiver_MarketParticipant.mRID codingScheme="A01">10X1001A1001A450</receiver_MarketParticipant.mRID>
<receiver_MarketParticipant.marketRole.type>A33</receiver_MarketParticipant.marketRole.type>
<createdDateTime>2024-10-07T16:18:12Z</createdDateTime>
<period.timeInterval>
<start>2024-10-06T22:00Z</start>
<end>2024-10-07T22:00Z</end>
</period.timeInterval>
<TimeSeries>
<mRID>1</mRID>
<auction.type>A01</auction.type>
<businessType>A62</businessType>
<in_Domain.mRID codingScheme="A01">10YPT-REN------W</in_Domain.mRID>
<out_Domain.mRID codingScheme="A01">10YPT-REN------W</out_Domain.mRID>
<contract_MarketAgreement.type>A01</contract_MarketAgreement.type>
<currency_Unit.name>EUR</currency_Unit.name>
<price_Measure_Unit.name>MWH</price_Measure_Unit.name>
<curveType>A03</curveType>
<Period>
<timeInterval>
<start>2024-10-06T22:00Z</start>
<end>2024-10-07T22:00Z</end>
</timeInterval>
<resolution>PT60M</resolution>
<Point>
<position>1</position>
<price.amount>65.08</price.amount>
</Point>
<Point>
<position>2</position>
<price.amount>46.34</price.amount>
</Point>
<Point>
<position>3</position>
<price.amount>40</price.amount>
</Point>
<Point>
<position>4</position>
<price.amount>30.1</price.amount>
</Point>
<Point>
<position>5</position>
<price.amount>29.97</price.amount>
</Point>
<Point>
<position>6</position>
<price.amount>30.1</price.amount>
</Point>
<Point>
<position>7</position>
<price.amount>52.02</price.amount>
</Point>
<Point>
<position>8</position>
<price.amount>84.5</price.amount>
</Point>
<Point>
<position>9</position>
<price.amount>108.32</price.amount>
</Point>
<Point>
<position>10</position>
<price.amount>91.75</price.amount>
</Point>
<Point>
<position>11</position>
<price.amount>65.98</price.amount>
</Point>
<Point>
<position>12</position>
<price.amount>56.01</price.amount>
</Point>
<Point>
<position>13</position>
<price.amount>44.71</price.amount>
</Point>
<Point>
<position>14</position>
<price.amount>30.1</price.amount>
</Point>
<Point>
<position>15</position>
<price.amount>27.08</price.amount>
</Point>
<Point>
<position>16</position>
<price.amount>26.83</price.amount>
</Point>
<Point>
<position>17</position>
<price.amount>30.25</price.amount>
</Point>
<Point>
<position>18</position>
<price.amount>50.24</price.amount>
</Point>
<Point>
<position>19</position>
<price.amount>68</price.amount>
</Point>
<Point>
<position>20</position>
<price.amount>73.61</price.amount>
</Point>
<Point>
<position>21</position>
<price.amount>85.01</price.amount>
</Point>
<Point>
<position>22</position>
<price.amount>67.73</price.amount>
</Point>
<Point>
<position>23</position>
<price.amount>65.8</price.amount>
</Point>
<Point>
<position>24</position>
<price.amount>61.39</price.amount>
</Point>
</Period>
<Period>
<timeInterval>
<start>2024-10-07T22:00Z</start>
<end>2024-10-08T22:00Z</end>
</timeInterval>
<resolution>PT60M</resolution>
<Point>
<position>1</position>
<price.amount>33.1</price.amount>
</Point>
<Point>
<position>2</position>
<price.amount>24.35</price.amount>
</Point>
<Point>
<position>3</position>
<price.amount>19.57</price.amount>
</Point>
<Point>
<position>4</position>
<price.amount>7</price.amount>
</Point>
<Point>
<position>5</position>
<price.amount>4.9</price.amount>
</Point>
<Point>
<position>6</position>
<price.amount>21.54</price.amount>
</Point>
<Point>
<position>7</position>
<price.amount>39.58</price.amount>
</Point>
<Point>
<position>8</position>
<price.amount>52.98</price.amount>
</Point>
<Point>
<position>9</position>
<price.amount>77.71</price.amount>
</Point>
<Point>
<position>10</position>
<price.amount>48.38</price.amount>
</Point>
<Point>
<position>11</position>
<price.amount>30.1</price.amount>
</Point>
<Point>
<position>12</position>
<price.amount>3.32</price.amount>
</Point>
<Point>
<position>14</position>
<price.amount>0.97</price.amount>
</Point>
<Point>
<position>15</position>
<price.amount>0.01</price.amount>
</Point>
<Point>
<position>16</position>
<price.amount>0</price.amount>
</Point>
<Point>
<position>17</position>
<price.amount>0.51</price.amount>
</Point>
<Point>
<position>18</position>
<price.amount>5</price.amount>
</Point>
<Point>
<position>19</position>
<price.amount>48.38</price.amount>
</Point>
<Point>
<position>20</position>
<price.amount>79.9</price.amount>
</Point>
<Point>
<position>21</position>
<price.amount>90</price.amount>
</Point>
<Point>
<position>22</position>
<price.amount>83.19</price.amount>
</Point>
<Point>
<position>23</position>
<price.amount>46.08</price.amount>
</Point>
<Point>
<position>24</position>
<price.amount>33.1</price.amount>
</Point>
</Period>
</TimeSeries>
</Publication_MarketDocument> |
Since the linked document s from 2022- is this change documented anywhere? |
Maybe this helps: "All XML exports".... |
Did a quick test. BE is broken as per Ensoe's docs. PT works fine afaikt. So... what's the issue? |
For Germany zone, I just switched back to entsoe, restarted the docker container and checked the GUI. This is the entsoe response in trace log. Is maybe the splitting into 2 periods new, as @Roeland54 mentioned?
|
This is the only official info on the changes which is quite useless because it is lacking an explanation the xml format changes. But the response is definitely changed. |
BZN|DE scheint nur für heute Daten zu haben, auch im XML. Für mich ist kein Fehler erkennbar. |
Before the change to the ENTSO-E interface last week, the Day-Ahead prices [12.1.D] were delivered with curveType A01. These contained exactly one Period element per TimerSeries element, although the XML schema already allowed a list of Period elements per TimeSeries for curve type A01 as well. With the change to curveType A03, the interface now supplies several Period elements per TimeSeries element. As this is not reflected in the entsoe model, only the last Period in a TimeSeries is read out by evcc. As @Roeland54 already pointed out, curveType A03 only contains Points where price.amount has changed compared to the previous Point, whereas A01 contains all Points even in case the price.amount remains unchanged (see pdf chapter 4.3 page 14). |
I don‘t think so. |
At least this somehow makes sense with a 24h data period shown/assigned to the wrong (later) day. I also would expect And in the response it's weird that |
As far as I remember, the interface was already behaving somewhat strangely in this respect before the change. |
For Germany, A3 curve today has 24 data points. Nothing missing.
I have not seen this error. Please open new issue. |
You need to validate this code against a entsoe response when the price for tomorrow is known. Before 13u00 the price of tomorrow will not be in the response. |
Works just fine |
Although... it seems to be missing 4 hours. I'll double-check. |
Today morning I switched back to entsoe and the shown prices where correct for BZN|DE. But now when prices for tomorrow where published, evcc again shows today prices for tomorrow: 33ct just isn't correct for tomorrow 20:00. That's todays price. It's supposed to be 31.9ct. Looks like again todays prices where applied to tomorrow. So I restartet the container. Like shown above there is one timeseries with 2 periods. And for some reason additionally the PT15M resolution, which isn't allways included. Response from 15:00 local time. |
Describe the bug
`site ] WARN 2024/10/06 08:26:28 planner: tariff not available: cannot create tariff type 'entsoe': no data for resolution: PT60M’
I got this error last night and the tariffs are blank in the planner.
I assume it is an entsoe api error, as my Home Assistant entsoe is also not working, but in the afternoon it was working.
Question: Entsoe updates the tariffs around 14.00 LT, does EVCC save this values in the database?
Is it possible to save the latest values and use them when the api is offline? (Instead of marking as unavailable)
Steps to reproduce
...
Configuration details
/
Log details
What type of operating system are you running?
Linux
Nightly build
Version
0.130.13
The text was updated successfully, but these errors were encountered: