Correct VAT was very easy an that works fine. For SUM I will have a look at that rule! Thx for the hint!
@jmelhus: Thx for providing the fix. I can confirm that everything is now working as expected. Great job! 
@laursen: Also thx for pointing out the rule to update the prices. Works perfect and was actually easy at the end.
As reference for the others here is my solution. I now have tree items:
- Energy_Price_EpexSpotAt
- Energy_Fee_Spot
- Energy_Price_Spot
The Energy_Price_EpexSpotAt is linked to the spot-price channel of the binding. The item is configured with the VAT profile (VAT profile is only available when installing an additional transformation addon).
The Energy_Fee_Spot is a simple numeric item that holds my current (static) fee that i need to pay in addition for each kWh.
I do have one script (JS based) that updates the Energy_Price_Spot item as followed:
// We need to wait a few seconds until the new data is written into influx
console.log("New spot prices received from EntsoE binding.")
console.log("Waiting for persistence...");
java.lang.Thread.sleep(10000);
var timeSeries = new items.TimeSeries('REPLACE');
var start = time.LocalDate.now().atStartOfDay().atZone(time.ZoneId.systemDefault());
var spotPrices = items.Energy_Price_EpexSpotAt.persistence.getAllStatesBetween(start, start.plusDays(2),'influxdb');
console.log("Calculating total energy price.")
console.log("-------");
for (var spotPrice of spotPrices) {
var spotFee = items.Energy_Fee_Spot.persistence.persistedState(spotPrice.timestamp,'influxdb');
if(!spotFee) {
spotFee = items.Energy_Fee_Spot;
}
var totalPrice = spotPrice.quantityState.add(spotFee.quantityState);
timeSeries.add(spotPrice.timestamp, totalPrice);
console.log("Time: ", spotPrice.timestamp)
console.log("EpexSpotAt: ", spotPrice.quantityState);
console.log("Fee: ", spotFee.quantityState);
console.log("Total: ", totalPrice);
console.log("");
}
console.log("-------");
items.Energy_Price_Spot.persistence.persist(timeSeries,'influxdb');
The script is executed by a new rule, that gets triggered when the prices-received channel of the binding is notified.
My refresh issue persists. No update was requested today. Having a look at the code and the response from the API i know what is happening:
The binding is taking all TimeSeries values that the API provides. In my case there are a total of 4 time-series tags in the response with different resolutions (PT60M, PT15M). One TimeSeries entry per day and per resolution. That causes too many data that the binding processes and stores. Because of that it assumes that i does not need to fetch new data as it has data for the next 4 days 
The binding may only consider the entries for PT60M resolution. Attached is the response that i get from the API endpoint.
@jmelhus: Can you check that?
Should i provide a fix?
response.xml (25.9 KB)
Thanks for troubleshooting and finding the cause. I will implement a fix for that together with some other review comments on the pull request. Hope to have a version for test later today…
So the dataset you provided contains both 15 minute and 60 minute intervals for the same period.
Are only 60 minute intervals relevant, or are you able to get charged of prices per 15 minutes from your electricity provider? If so we should have it customizable in the binding.
I have implemented functionality in the binding to use 15 minutes if needed, i just need to add it as an option in the binding. Meanwhile I hardcoded the use of 60 minute intervals. You can get it from here: https://github.com/user-attachments/files/17179809/org.openhab.binding.entsoe-4.3.0-SNAPSHOT.jar.zip
1 Like
For me the 60 minutes interval is perfectly fine. I do not have any use-case for lower resolutions. Data looks great for now. Will report back tomorrow if the update is now working.
Thx again for providing a new version that quick!
I believe 15 minutes granularity for the day-ahead market is planned for Q1/2025. I guess I should be looking into that for Energi Data Service as well sometime soon. 
One small improvement you could make: Instead of this Thread.sleep, which will block the thread for 10 seconds, you could surround your code by this:
setTimeout(() => {
// Your code here
}, 10000);
1 Like
Can we install the latest version from the (Community) Marketplace?
I still have a very old version running. Or do I need to grab the seperate jar?
Update after two days of usage: Binding is now working fine for me and updating the prices as expected. 
1 Like
The version from the marketplace is outdated. You can use the JAR linked to the GitHub pull-request: [entsoe] Initial contribution by jmelhus · Pull Request #17416 · openhab/openhab-addons · GitHub
There have been a lot of changes in the binding. Be sure to read the documentation: openhab-addons/bundles/org.openhab.binding.entsoe/README.md at 4a4d64e4878e5da6a9d11cff57f6a330050af831 · openhab/openhab-addons · GitHub
Hey there,
one dumb question, looks like that the binding is working properly.
2024-10-02 10:10:59.273 [INFO ] [openhab.event.ItemTimeSeriesEvent ] - Item 'SpotPrice' shall process timeseries [Entry[timestamp=2024-10-01T22:00:00Z, state=0.08544], Entry[timestamp=2024-10-01T23:00:00Z, state=0.08088], Entry[timestamp=2024-10-02T00:00:00Z, state=0.07709], Entry[timestamp=2024-10-02T01:00:00Z, state=0.07493], Entry[timestamp=2024-10-02T02:00:00Z, state=0.07714], Entry[timestamp=2024-10-02T03:00:00Z, state=0.0811], Entry[timestamp=2024-10-02T04:00:00Z, state=0.09653], Entry[timestamp=2024-10-02T05:00:00Z, state=0.11883], Entry[timestamp=2024-10-02T06:00:00Z, state=0.1357], Entry[timestamp=2024-10-02T07:00:00Z, state=0.11759], Entry[timestamp=2024-10-02T08:00:00Z, state=0.10321], Entry[timestamp=2024-10-02T09:00:00Z, state=0.09652], Entry[timestamp=2024-10-02T10:00:00Z, state=0.09045], Entry[timestamp=2024-10-02T11:00:00Z, state=0.08644], Entry[timestamp=2024-10-02T12:00:00Z, state=0.07887], Entry[timestamp=2024-10-02T13:00:00Z, state=0.08207], Entry[timestamp=2024-10-02T14:00:00Z, state=0.08151], Entry[timestamp=2024-10-02T15:00:00Z, state=0.1001], Entry[timestamp=2024-10-02T16:00:00Z, state=0.11701], Entry[timestamp=2024-10-02T17:00:00Z, state=0.13007], Entry[timestamp=2024-10-02T18:00:00Z, state=0.11437], Entry[timestamp=2024-10-02T19:00:00Z, state=0.09654], Entry[timestamp=2024-10-02T20:00:00Z, state=0.0933], Entry[timestamp=2024-10-02T21:00:00Z, state=0.085]]
2024-10-02 10:10:59.283 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'SpotPrice' updated timeseries [Entry[timestamp=2024-10-01T22:00:00Z, state=0.08544 DEF/kWh], Entry[timestamp=2024-10-01T23:00:00Z, state=0.08088 DEF/kWh], Entry[timestamp=2024-10-02T00:00:00Z, state=0.07709 DEF/kWh], Entry[timestamp=2024-10-02T01:00:00Z, state=0.07493 DEF/kWh], Entry[timestamp=2024-10-02T02:00:00Z, state=0.07714 DEF/kWh], Entry[timestamp=2024-10-02T03:00:00Z, state=0.0811 DEF/kWh], Entry[timestamp=2024-10-02T04:00:00Z, state=0.09653 DEF/kWh], Entry[timestamp=2024-10-02T05:00:00Z, state=0.11883 DEF/kWh], Entry[timestamp=2024-10-02T06:00:00Z, state=0.1357 DEF/kWh], Entry[timestamp=2024-10-02T07:00:00Z, state=0.11759 DEF/kWh], Entry[timestamp=2024-10-02T08:00:00Z, state=0.10321 DEF/kWh], Entry[timestamp=2024-10-02T09:00:00Z, state=0.09652 DEF/kWh], Entry[timestamp=2024-10-02T10:00:00Z, state=0.09045 DEF/kWh], Entry[timestamp=2024-10-02T11:00:00Z, state=0.08644 DEF/kWh], Entry[timestamp=2024-10-02T12:00:00Z, state=0.07887 DEF/kWh], Entry[timestamp=2024-10-02T13:00:00Z, state=0.08207 DEF/kWh], Entry[timestamp=2024-10-02T14:00:00Z, state=0.08151 DEF/kWh], Entry[timestamp=2024-10-02T15:00:00Z, state=0.1001 DEF/kWh], Entry[timestamp=2024-10-02T16:00:00Z, state=0.11701 DEF/kWh], Entry[timestamp=2024-10-02T17:00:00Z, state=0.13007 DEF/kWh], Entry[timestamp=2024-10-02T18:00:00Z, state=0.11437 DEF/kWh], Entry[timestamp=2024-10-02T19:00:00Z, state=0.09654 DEF/kWh], Entry[timestamp=2024-10-02T20:00:00Z, state=0.0933 DEF/kWh], Entry[timestamp=2024-10-02T21:00:00Z, state=0.085 DEF/kWh]]
2024-10-02 10:10:59.283 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SpotPrice' changed from NULL to 0.10321 DEF/kWh
and with the timeseries, should following rule work? because it doesn’t.
var price = SpotPrice.historicState(now.plusHours(5)).state
logInfo("Spot price two hours from now", price.toString)
2024-10-02 10:45:52.462 [INFO ] [script.Spot price two hours from now] - 0.10321 EUR/kWh
Doesn’t matter if plusHours is 1,2,3,…10… log output is only showing spotPrice (now).
I work with this binding version
on OH4.1.3
Yes IMHO that looks ok and should work. Not sure why this delivers the wrong values.
fyi Entso E has changed format ?
Entso-e did some changes the last couple of days. There is a new platform address: https://newtransparency.entsoe.eu/
See this communication: Upgrade to 0.5.1 faulty · Issue #184 · JaccoR/hass-entso-e · GitHub
I tested on my system and it correctly reports historic data for different hours (different values). Did you configure persistence like InfluxDB on your system? And do you persist for this item?
Sidenote, I see the binding reports DEF as your currency, I would recommend setting a default currency in unit settings if you haven’t already, and if you need values in other currency than EUR add a binding like FreeCurrency to exchange values to your currency.
Seems to be related to SFTP and a new web endpoint, and not the web api yet? Web api still refers to the 4.2.10. Day Ahead Prices [12.1.D], with no changes to data structure as what i can see. Tried to do a quick search, could not find any information about changes to the web api regarding this. Do you have some other links/resources also?
@mstormi, data structure is the same i think, some markets now have both 15 minutes and 60 minutes resolution, that is why it returns several timeseries i think.
web api: Static Content
@jmelhus What I observed a couple of days ago was the difference in the API response when multiple days worth of data is returned.
Previously, the Entso-E API behaved so that when multiple days was requested, the response structure was like below. There was a TimeSeries element for each day and the TimeSeries contained one Period element. So like this.
<Publication_MarketDocument>
<TimeSeries>
<Period>
// Data for day 1
</Period>
</TimeSeries>
<TimeSeries>
<Period>
// Data for day 2
</Period>
</TimeSeries>
</Publication_MarketDocument>
Now, the response structure looks like like below. There is only one TimeSeries element, but that now contains multiple Period elements, one for each day. So like this.
<Publication_MarketDocument>
<TimeSeries>
<Period>
// Data for day 1
</Period>
<Period>
// Data for day 2
</Period>
</TimeSeries>
</Publication_MarketDocument>
Like I mentioned in the other discussion @mstormi referred to, I have reached out to Entso-E to ask if this change is intentional or are they planning to revert the change.
Obviously there is no impact if you only get one day worth of data because it will be one TimeSeries with one Period.
Cheers,
Markus
@jmelhus thanks for your reply.
Did you configure persistence like InfluxDB on your system? And do you persist for this item?
not explicit. I use mapDB as default persistence, but InfluxDB for selected items.
okay, just for clarification:
I have to enable InfluxDB (or any other timeseries persistence service) for the spot-price item, and than I can use
SpotPrice.historicState(now.plusHours(5)).state
to get the price in the “future” (next 24h, yes I know, updated every day at ~1300CEST)?
E.g. Got the Update at 1300CEST, now it’s 1500CEST, with the example above (+5h) I get the price for 2000CEST.
Is that correct?
Sorry for my noob questions about timeseries.
I get this message in the logs responseMap is empty
this is the only info I can find: Transparency Platform
But eg on the evcc project, I also don’t get any more data from entso-e, like many others.