Tibber [OH5]

[mstormi (Markus Storm)]

you need to configure ‘forecast’ as the persistence strategy

[efrankzm]

Top - now it works.
Add. Info I had to change /etc/openhab/services/runtime.cfg, section default persistence.
org.openhab.persistence:default=rrd4j
Without this change I got no values from the other items

[binderth (Thomas Binder)]

@efrankzm

org.openhab.persistence:default=rrd4j

just a heads up: If you set rrd4j as default persistence you won’t have access to timeseries, unless you specified a timeseries-capable persistence in your rules/charts/…
please specify “no value from the other items”: If you only define forecast in your default persistence you should get values - but no “historic” persistence. So if you define both onChange and forecast for your items, you will get what you probably want: charts for historic values and the forecasted future Tibber prices.

[pacive (Anders Alfredsson)]

Depending on which persistence service used, forecast may be enough. I use influxdb for persistence, then the values are inserted from the TimeSeries Item update, and then of course stays in the DB even after. If using inmemory persistence for forecast, you may need everyChange for another persistence service to get historic values as well.

[binderth (Thomas Binder)]

@pacive

and then of course stays in the DB even after.

yes, it does and would be enough for those forecasted items (even though there’s some discussion going on, why “forecasted” aka not fixed vallues should be historically persisted after all: what sense does it make to store weather predictions e.g.), but I think efrankzm has other issues with their persistence confguration.

[pacive (Anders Alfredsson)]

For weather I can agree that it can seem unnecessary, but could be useful if you want to evaluate and optimize your algorithms that use this data. For energy prices OTOH the forecast is the actual price you get, so I think it’s very useful to have this stored as historic values.

On-topic, I think i remember some forum thread where someone had both forecast and everyChange configured which led to duplicate values in the DB (the forecasted value exactly on the hour, and the “changed” value some milliseconds later), so recommending to use both can cause some unwanted side effects. This of course only if you have both for the same persistence service.

[binderth (Thomas Binder)]

@pacive

On-topic, I think i remember some forum thread where someone had both forecast and everyChange configured which led to duplicate values in the DB

That was me, but obviously my report was deleted…?

Timeseries Array (Tibber prices) have double entries with getAllStatesBetween?

They are not so different though. In scenario 1 the Item gets updated by the actual measurement at some point by the binding. That value gets saved to persistence and the predicted value gets removed. In scenario 2, the Item gets updated by what ever updates the Item from persistence when the time comes for that entry to become the current state of the Item. Again, that “new” value gets saved to persistence and the predicted value gets removed. It’s the same action. The only difference is wh…

We weren’t sure if it cam from defining both strategies or from other things…

[weymann (Bernd Weymann)]

@binderth

We weren’t sure if it cam from defining both strategies or from other things…

I agree this is a complex topic and I don’t have the complete overview but I see 4 parties involved. Binding, persistence, user persistence config and maybe core.

1. Binding
   For Tibber binding it’s 100% sure updates of the day ahead prices occurs one time per day! Responsibility to update the item state is persistence. And that’s the reason why items stay NULL if the item isn’t connected to a forecast persistence strategy.
   Other bindings my be different!
2. Persistence
   Please have a look into the predefined persistence strategies.
   As a result mixing forecaststrategy with other strategies is not recommended (exceptrestoreOnStartup).
   Otherwise you’ll have double entries with slightly different timestamps!
3. User persistence config
   Here it gets interesting!
   I’m certain most of the users have a default persistence which is rrd4j, me too!
   Due to the fact it cannot handle future values items stay NULL (see point 1).
   But if you assign this item to a appropriate forecast strategy like influxdb it updates the state, so
   a) rrd4j as default persistence contains all historic updates till now
   b) influxdb contains all historic plus future values
   A rule which queries an item will also have double entries with slightly different timestamps!
4. Core
   As @Mherwege posted this maybe a core issue but from my expertise I don’t see evidence. From my point of view the above points 1), 2) and 3) needs to be analyzed to get a clear view before core functionality is analyzed.

PS:
This isn’t only about Tibber, it’s regarding weather forecast, awattar, solar forecast,…

[weymann (Bernd Weymann)]

Nice to see Marketplace binding can handle price updates: red = hourly prices, green = 15 minutes prices.

[Mherwege (Mark Herwege)]

@weymann

A rule which queries an item will also have double entries with slightly different timestamps!

A rule would only query the default persistence service unless it is instructed to query a specific persistence service. So I don’t see how double entries could happen. If the default is rrd4j it returns data from that db unless an other service is specified in the query. If you specify influxdb, in the query. it returns data from influxdb and not rrd4j.

[binderth (Thomas Binder)]

@Mherwege

If you specify influxdb, in the query. it returns data from influxdb and not rrd4j.

as this is correct, there’s scenarios where one persistence stores double entries. of course there’s no scenario in which a rule would ask two persistences at once (without adding two commands for that…).

[binderth (Thomas Binder)]

I have a question or also an feature request, @weymann …

my use case is, that I define intervals for prices from very cheap to extremely expensive. Those intervals orient themselves on Euro prices and is not correspondent with the level from the Tibber API.

For that I need a trigger, if the binding was able to access the prices for the next day, so I can then calculate those intervals myself via a rule. Best was a binding trigger for the “updated” action?

[weymann (Bernd Weymann)]

@binderth

my use case is, that I define intervals for prices from very cheap to extremely expensive. Those intervals orient themselves on Euro prices and is not correspondent with the level from the Tibber API.

That’s listPrices action where you can define your own earliestStart and latest end time and per default it’s sorted according prices in ascending order.

@binderth

For that I need a trigger, if the binding was able to access the prices for the next day, so I can then calculate those intervals myself via a rule. Best was a binding trigger for the “updated” action?

I personally calculate every time till priceInfoEnd. If you need a trigger you can check if this timestamp changed after item update. But if a separate trigger channel is needed I’ve also no problem.

[binderth (Thomas Binder)]

@weymann

I personally calculate every time till priceInfoEnd. If you need a trigger you can check if this timestamp changed after item update. But if a separate trigger channel is needed I’ve also no problem.

yes, that would be great to only trigger calculations one time a day if the new prices are available.

[mstormi (Markus Storm)]

At times I keep getting this error:

2025-11-03 10:13:22.366 [WARN ] [org.openhab.binding.tibber.internal.action.TibberActions         ] -
Calculation start 2025-11-03T09:13:22.366011531Z is after end 2025-10-31T23:00:00Z

By that time, dis+enabling the Tibber API Thing gave a semi-permanent error, seems API didn’t respond properly.
For a permanent fix though it seems I had to restart the binding.

[binderth (Thomas Binder)]

I upgraded today to 5.0.2 and thus all my marketplace AddOns disappeared (other topic).
But: After re-installing the Tibber [OH5] marketplace version (marketplace:164158), I now do get hourly prices instead of quarter-hourly.
now I’m totally confused as to why that happened!

[DanielMalmgren]

@binderth

I now do get hourly prices instead of quarter-hourly

Doh! I needed to check and you’re right, this is the same for me! Everything back to hourly

And I’ve also wondered why markedplace addons disappears after upgrades. Not all of them for me though, only some. Thought it maybe was supposed to be that way…

[binderth (Thomas Binder)]

@DanielMalmgren

And I’ve also wondered why markedplace addons disappears after upgrades. Not all of them for me though, only some. Thought it maybe was supposed to be that way…

THAT’S by design, I was told. you have to re-install all marketplace AddOns (bindings, widgets, UIs, …), because “otherwise it would imply, all versions of all marketplace installs are compatible with all possible versions of openHAB”. I find it kinda annoying at least for minor versions, but that’s how it is. I wrote a rule, which fires every two hours, which checks if marketplace addons are present and alerts me, if not…

What I did in the meantime: download the JAR linked in the first post and dropped it into the addons-folder. THAT works at least.

[weymann (Bernd Weymann)]

I updated Marketplace binding on sunday regarding day-ahead price trigger but all other changes are also in. Also there’s only one version linked which fits to OH4 & OH5.
Even more curious latest OH5.0.2 update contains the quarter-hourly fix.

[binderth (Thomas Binder)]

@weymann

I updated Marketplace binding on sunday regarding day-ahead price trigger but all other changes are also in.

Perhaps it has to do with the (still present) bug, that randomly 429er or 500er errors pop up while browsing through the marketplace?
I even removed and reinstalled the marketplace version today after I encountered this. I didn’t try the 5.0.2 core version, though…