Regarding the resolutions of the timeseries.
I read through the comments above that at least for the area 10YAT-APG------L EntsoE response contains data with both PT15M and PT60M resolutions. I was not aware that this might happen on some areas because so far I have only seen responses with PT60M resolution. But seeing is believing, the response XML @mheiss shared clearly shows that both resolutions were present in the response.
The reason why I’m posting over here is that I had a very confusing moment yesterday when I tried the snapshot binding. I thought that the configuration option would mean that the binding would transform the timeseries to the configured resolution and store it like that. I tried to set up the configuration option to PT15M but that resulted in an error message that PT15M data is not present and I was totally WTFd about the purpose of the configuration option.
All my optimizations work with PT15M resolution. I’m in the process of refactoring my solution so that the next version would be using this binding so that I would not need to maintain an parallel solution for fetching the prices and so that setting it up would be more openHAB way. Currently I’m “filling the gaps” so that even if the EntsoE response is with PT60M, I fill the gaps and store it with PT15M resolution.
But since the API response can contain different resolutions, I’m not suggesting that the binding would start to do the same, it’s probably asking for trouble. So I need to find an approach to my solution. I see two options:
- Either I write a rule that gets executed right after the binding has fetched the prices from EntsoE, fills the gaps so that we have prices points every 15 minutes (or have another item which is with PT15M resolution and store the data to that).
- Or I re-write the optimization algorightms so that it accepts PT60M as an input but then after reading the prices from persistence, it internally transforms it to PT15M at runtime and then continues with the optimizations like now…
Cheers,
Markus