that part is in the much bigger Blockly rule where I process dynamic tariffs into categories. Averaging to hourly values is basically 1 line of code.
Important here is that I store day ahead prices in a time series item. And since this rule can run every moment, I need to determine the full 24h of the next day. So state average between is used with that calculation. This code is ran 24 times, once for each hour. Teller is the hourly teller and needs to start at 00:00 of the next day and than run 24 tiimes.
Teller is a variable and used as a loop-counter wich runs 24 times. The starting point for Teller is hours from now until midnight. So if the rule runs a 14:00, Teller starts at 10, increases every run and runs 24 times.
it appears the timeseries strategy for the 15min data is “replace”. So, everytime there is new data, the old data is gone. Is there any chance to change that strategy to “add”?
I need that for trend calculations which considers historic data.
Duplicate values on the same timestamps are not a problem. I have been working with timeseries before - in user space using JRuby rules - where the “add” strategy was working fine.
Else it would be sufficient to pull the “new” data with some historic data back till midnight (start of day). I asked the same for the OpenMeteo binding which worked out great.
Thanks!
Edit: Never mind, the binding is doing fine. There was/is(?) a data issue at EntsoE side that was causing the issues I saw. It will be addressed over there.
Changes with 15 minute resolution is available in OH5.1 version.
Also clarified with Entso-E support which sequence is relevant for the end customer - it’s sequence 1. Sequence 2 is showing prices for European cross border transmissions which are high likely not relevant for the end customer.
I double checked this with my Tibber spot prices (without tax and additional expenses) and they are matching!
I’m running OH 5.2, there are two time series, both 15 minute resolution and no way to select between them, but you’re right, number 1 is the one supposedly relevant for most users.
Which persistence is connected to the item connected to day-ahead channel? If it’s rrd4j this would explain why no data is displayed because it cannot handle future vaues.
For checking install inmemory persistence and add a new configuration with strategy forecast and add the entsoe item to it.
Disable and enable entsoe thing to force an update and after a while the value will appear.
See this tutorial how to display future / forecast values in a graph.
Yep, OH 5.2 snapshot. This issue was consistent for some time with all the snapshots of 5.2, possibly even earlier on 5.1. I had the items successfully persisted in rrd4j for a long time (only the current value was stored, no forecasts). Somewhen a few weeks(? possibly) ago, it stopped working.
Im using rrd4j as default persistence and in memory for these forecast values, but I only see “NULL” values on the item. These are currently the only forecast values I use. Might be a persistence issue as well, I suspected the ambiguous return data with multiple time series as the entso-e introduced the second time series a while ago. might be coincidence, though.
I added the item to a group “(inmemory)” and have a stragtegie for items "inmemory* : strategy = everyChange, forecast”
EntsoE binding stopped updating the electricity prices yesterday and I have following messages in the log:
2026-09-01 16:29:04.853 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.util.NoSuchElementException
at java.base/java.util.TreeMap.key(TreeMap.java:1637)
at java.base/java.util.TreeMap.firstKey(TreeMap.java:302)
at org.openhab.binding.entsoe.internal.handler.EntsoeHandler.getTimeseries(EntsoeHandler.java:218)
at org.openhab.binding.entsoe.internal.handler.EntsoeHandler.updateChannels(EntsoeHandler.java:163)
at org.openhab.binding.entsoe.internal.handler.EntsoeHandler.refreshPrices(EntsoeHandler.java:151)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Yep, I’m in the same boat. I noticed the same thing today when I arrived at home.
When I logged in to Transparency platform it told me account is suspended until I renew password. After password renewal I renewed the API key, but at least by disabling and re-enabling thing in openhab I still saw only the same HTTP 503 error as thing state.
Something caught my eye while I was in transparency platform:
EntsoE has a new message from today that the migration of their system was not successful and that they are doing a rollback to the previous version. After that they have to clear the API call backlog. No estimate when up and running.
