[aWATTar] Schedule API update more than once per day

[tl-photography]

Shedules the API update more than once per day.

[lsiepel]

LGTM, would be nice if @Wolfgang1966 can confirm.

[jlaur]

@tl-photography - after reading the issue you are trying to solve, I have a few questions: Is it correct that the service provided some false values? And to resolve that you want to call more frequently? Besides this I would assume that prices are usually fixed once received?

[tl-photography]

The price that got retrieved at 1500 where correct at this time. But approximately 10 minutes later, new prices had been announced.

It seems it 99% of the time ok to check only once a day. I only fix the other 1%. :)

[jlaur]

The price that got retrieved at 1500 where correct at this time. But approximately 10 minutes later, new prices had been announced.

So it's not that prices were wrong, but expected day-ahead prices were missing? If this is the case, perhaps the binding should keep polling only when prices are missing?

I don't know the details of the binding, but I know the domain from working on the Energi Data Service binding.

[tl-photography]

The price where not missing, the API did return data that was available at the time.

The issue is that the price data then was updated and the plugin would not contact the API again.

In fact, the schedule of the plugin is to contact the API once a day at 1500. Data was available then and also shown in OpenHAB. At 1508, the prices got updated and the plugin would not schedule an update of it, since it already had data available.

[jlaur]

In fact, the schedule of the plugin is to contact the API once a day at 1500. Data was available then and also shown in OpenHAB. At 1508, the prices got updated and the plugin would not schedule an update of it, since it already had data available.

So going back to one of my first questions again:

Besides this I would assume that prices are usually fixed once received?

Why were the prices updated, are they not supposed to be fixed once published?

[tl-photography]

Why were the prices updated, are they not supposed to be fixed once published?

You're probably asking the wrong guy here. I'm not working for the EPEX. The only thing I know, they did change.

Besides, what are we discussing here? Is there anything wrong with checking three times instead of once?

[tl-photography]

I tried to find the historical data, but it seems they are not publicly available for longer than 3 days.

But judging from the page https://www.epexspot.com/en/market-data delays in the published data or updates to them are not uncommon.

Looking back to the issues they had, I could imagine that the data got published and then updated later on.

This then probably got reflected in the awattar API as well.

Since the API allows up to 100 updates per day, I would say checking the API 3 times is reasonable and would always have the correct data ready for the next day.

[jlaur]

Besides, what are we discussing here? Is there anything wrong with checking three times instead of once?

I'm only asking some questions trying to obtain information that can possibly help me understand the problem being solved, because I think it is hard to assess a fix without really understanding the underlying problem.

The point I'm unsuccessfully trying to make is that auctioned day-ahead electricity prices should be fixed (by contract), so they won't (should not) change. That's the point of the whole system. There might be changes in currency exchange rates, so if the obtained prices are not in EUR, there could be small adjustments, depending on how the service works.

I fail to see how additional calls at arbitrary times will fix anything. And in that case, why only every three hours, and why stop at midnight? I guess the prices could still change?

To summarize, you have stated:

• Prices were not missing.
• Prices were not wrong.

Yet they were updated. How much did they change? If the changes were small, could currency exchange explain such small differences?

[J-N-K]

IMO they were wrong, at least on 26/06/24. I guess that happened because EPEX didn't provide proper prices (due to their technical problem). If there are 100 free calls per day, why don't we call every hour? The result is cached anyway, so we can compare the newly retrieved data with the cached data and only refresh the child things when the data changed.

[jlaur]

IMO they were wrong, at least on 26/06/24. I guess that happened because EPEX didn't provide proper prices (due to their technical problem).

OK, in that case I guess there is an assumption that prices are more likely to be correct the later they are published? Because otherwise fetching them more frequently could also lead to prices going from correct to wrong? If this assumption is indeed plausible, then I agree it will help to call more often, although it's a work-around for a broken service publishing wrong prices. 😕

[tl-photography]

The prices should indeed be agreed by 1230 CEST and awattar states the prices would be available "after 1400". They do not state a clear termination. Delays seem to happen more frequently von the EPEX, as can be seen in the link I posted, but are usually within the 1230 to 1400 window.

The more recent prices are more "correct" since they are the agreed ones by the market.

Too summarize: there is a termination, but it can be violated by the EPEX and therefore updates to the API data might happen.

I guess we could also just retrieve the data once at 2300 and get the always the correct one, but as I already said, I think it's reasonable to poll the API three times after 1500. So we get the data as fast as possible and also would get the latest data, if updates did occur.

[tl-photography]

although it's a work-around for a broken service publishing wrong prices.

Just to be clear, I did check the data during that day, when it was still available, and the service was not broken. It did reflect the prices that where announced by the EPEX at the time. Unfortunately, I did not make any screenshots. But in the linked issue there are two attached.

[J-N-K]

The question is: what prices do they use when there is no price from EPEX? Or did EPEX provide a price and changed that one later?

[tl-photography]

How much did they change? If the changes were small, could currency exchange explain such small differences?

Unfortunately, the price difference was enormous. The usual price would be 0.15€/kWh, the updated prices, due to the software fault at the EPEX, where up to 2€/kWh.

[tl-photography]

The question is: what prices do they use when there is no price from EPEX? Or did EPEX provide a price and changed that one later?

The EPEX did provide a price before 1500 and it got updated later, afaik.

[Wolfgang1966]

Hi @tl-photography , first of all a great THANK YOU for addressing that issue. I noticed it when I was made aware of the very high hourly prices in the morning of that day and saw that the binding did not provide the correct values. But I did not dig deeper into the details. So, @jlaur , I can confirm that there indeed was a problem and the PR addresses it. I don't know the exact root cause why the aWATTar API provided wrong prices first, but I agree with @tl-photography that the EPEX spot system problem at that special day might have had something to do with it.

About @J-N-K s idea to refresh every hour: I am also thinking about something like that now, but in the meantime I also started thinking about the binding from the API providers perspective. Currently there are hopefully only a few users of that binding, so the request peak every afternoon is acceptable hopefully. But the more users the binding gets, the higher the peak will become as clocks are synchronized very well nowadays. So from my point of view the price refresh should run at "random" times and decoupled from the thing refreshes, so that the load at the aWATTar API gets distributed over times and does not hit them in a sharp peak every hour.

That goes beyond the scope of your change, but as you are currently dealing with the refresh anyway, how about addressing this potential problem also? An idea could be to refresh once with binding start and then compute a next refresh time as a random time between one and two hours in the future? And only if prices are not available after 14:00, compute a more frequent retry, but also only every few minutes?

If you don't want to do this then it is also ok for me. In this case I may add this later after your PR is finalized and merged.

One more remark: We should mention this more frequent price updates somewhere in the binding description as changed prices might lead to unforseeable changes in the BestPrice Thing calculations. Especially it might be that consecutive Things are not consecutive anymore after a recalculation, and non-consecutive things do not exactly stick to the configured timing.

[lsiepel]

That goes beyond the scope of your change, but as you are currently dealing with the refresh anyway, how about addressing this potential problem also? An idea could be to refresh once with binding start and then compute a next refresh time as a random time between one and two hours in the future? And only if prices are not available after 14:00, compute a more frequent retry, but also only every few minutes?

This sounds like premature optimizations. Any provider of such API is (or should be) aware of these foreseeable spikes in traffic and take measures accordingly.
An option is also to define three update moments like suggested, but also make those user configurable. With a default of 15 / 18 and 21 hour. Mark the config as advanced and anyone can choose whatever they want.

[jlaur]

So, @jlaur , I can confirm that there indeed was a problem and the PR addresses it. I don't know the exact root cause why the aWATTar API provided wrong prices first, but I agree with @tl-photography that the EPEX spot system problem at that special day might have had something to do with it.

Sure! For the avoidance of doubt: My concerns have been addressed, since in fact the published prices were wrong, and the likelihood of correct prices increases over time:

If this assumption is indeed plausible, then I agree it will help to call more often

[jlaur]

This sounds like premature optimizations. Any provider of such API is (or should be) aware of these foreseeable spikes in traffic and take measures accordingly.

I'm not sure I agree here. If exact time of availability is not known and it's not critical for the binding to get the prices at any specific moment, then I don't see any harm in adding some jitter so all clients don't call at exactly the same time. Even distribution over a few minutes can help. Most likely openHAB traffic is minimal so in reality it probably won't matter much, but I think in general it's a good courtesy and design to do this.

Example from Energi Data Service with just one minute of call distribution:

openhab-addons/bundles/org.openhab.binding.energidataservice/src/main/java/org/openhab/binding/energidataservice/internal/retry/RetryPolicyFactory.java

Lines 65 to 74 in 12a1f76

	/**
	* Determine {@link RetryStrategy} for next expected data publishing.
	*
	* @param localTime the time of daily data request in local time-zone
	* @param zoneId the local time-zone
	* @return retry strategy
	*/
	public static RetryStrategy atFixedTime(LocalTime localTime, ZoneId zoneId) {
	return new FixedTime(localTime, Clock.system(zoneId)).withJitter(1);
	}

A few other used strategies (just for sharing):
https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.energidataservice/src/main/java/org/openhab/binding/energidataservice/internal/retry/RetryPolicyFactory.java

Anyway, it's definitely outside the scope of this PR.

[tl-photography]

For the optimisation part I would say that some minimal jitter around the hours should be ok.

We could add a random delay between 0-5 minutes on the timestamp, should be easy to implement I guess...

Any provider of such API is (or should be) aware of these foreseeable spikes in traffic and take measures accordingly.

I do see your point here, but from my knowledge of services like these, people behind such APIs are indeed happy of a little randomisation. Scaling the system for such peak loads is a pain in the ass, especially when you then have almost no traffic at the remaining time.

I can add this to the code, I will just need a little time since I'll be not available for a week or two.

We could also just merge this now and optimise it later.

[J-N-K]

@tl-photography Did you see my comment?

[tl-photography]

But as written before: All of this are really edge cases and it could be that they never happen in reality in the next years. So beware of overengineering.

I think the prices would usually already stable at 1500. There is a very very small change they would change until 1800 and nearly impossible at 2100. So this is really just to cover that one edge case.

I agree that there might be a chance of broken schedules when a consecutive range is already running and is scheduled to run longer than the update.

I also think it should not turn it off, as @J-N-K mentioned.

This should be addressed at some point, but I'm not sure if we can fix that quickly.

[J-N-K]

@tl-photography Can you address the only remaining comment by @Wolfgang1966 and add a note about the more frequent refreshes and the slight chance there might be discontinuities in the best price thing to the docs? I would like to see this merged so I can progress with the TimeSeries support (I would prefer to reduce merge conflicts).

[tl-photography]

Sure, will update the PR in the evening!

[tl-photography]

update the docs with a short comment on this.
I'll check what i can do on another PR later to include the suggested changes.

[J-N-K]

Always start a new sentence on a new line.

[J-N-K]

Suggested change

	Note: The Thing will schedule updates of the aWATTar API at 15:00, 18:00 and 21:00. If late updates occur, e.g. after 2100, there is a chance that consecutive best prices will be rescheduled. As a consequence, a time schedule spanning over an update slot might be interrupted and rescheduled.
	Note: The Thing will schedule updates of the aWATTar API at 15:00, 18:00 and 21:00. If late updates occur, e.g. after 21:00, there is a chance that consecutive best prices will be rescheduled.
	As a consequence, a time schedule spanning over an update slot might be interrupted and rescheduled.

[tl-photography]

was that the reason for the failed build? o_O

[J-N-K]

@Wolfgang1966 Any objections? Otherwise I'll merge.

[J-N-K]

What changed in the last push? If you force push we can't track changes.

[tl-photography]

I accidentially synced my branch with the main repo, resulting in a merge from github. I rebased it again, getting rid of the merge. Code is the same as before.

i actually wanted to sync my main branch.

sorry for that.

[Wolfgang1966]

LGTM. Thanks @tl-photography

[tl-photography]

This is just a fyi:

Today's market seems to be in risk of being decoupled again, as there seems to be some technical issues.

At the time I'm writing this, there are still no prices published by the aWATTar API.

[Wolfgang1966]

Just checked ENTSO-E: Prices for tomorrow are available there now:

https://transparency.entsoe.eu/transmission-domain/r2/dayAheadPrices/show?name=&defaultValue=false&viewType=GRAPH&areaType=BZN&atch=false&dateTime.dateTime=25.07.2024+00:00|CET|DAY&biddingZone.values=CTY|10Y1001A1001A83F!BZN|10Y1001A1001A82H&resolution.values=PT15M&resolution.values=PT30M&resolution.values=PT60M&dateTime.timezone=CET_CEST&dateTime.timezone_input=CET+(UTC+1)+/+CEST+(UTC+2)

And now awattar.de has them also

[tl-photography]

Yes, aWATTar DE and AT do now have prices. The issue seemed to be resolved in time.