Tibber binding is already released in openHAB. Several stability issues are reported which are bugging me a lot. There are also flaws e.g. spot-prices are updated every minute which causes 1440 queries per day. Additionally channels are a boquet mixture of spot-prices, live measures and statistics.
I want to start a proposal for OH5 which can introduce some breaking changes. On Marketplacce I’ll a publish a compatible version which shall solve stability errors.
Changelog
Version 0.1-earlybird
usage of jetty http common client to avoid SSL trust certificate errors
Rationale
I just wanted to fix the stability issue reported in the forum. Looking a bit deeper there are several topics which needs to be improved.
Configuration
Config refreshInterval isn’t necessary
Spot prices are udpated once per day and the binding shall evaluate at which hour this update occus instead of polling each minute!
This can be solved without changing cahnnels.
Channels
The current channels are a mixture of spot-prices, live-updates and statistics. My goal for OH5 (where we can introduce some breaking changes!) would be to structure the channels into groups to have some ordering.
I did propose some time ago a kind of “merge” or at least some kind of combination of “dynamic pricing” things. I know, technically the APIs of e.g. Tibber and aWATTar are way different, but so are PV forecasts also, and we have two of them in one binding!
so, I’m not really sure, if this is feasible or not, but perhaps worth a look (the discussion soon went off-rails, but nevertheless):
In the mean time I myself wrote a bunch of rules to manage at least my requirements of letting my wallbox, (pool)heater, disher, … consume, when energy is cheap.
other than that, my thoughts are also having a stable Tibber binding for all kinds of information available from the Tibber API - plus the 15min strategy the spot market will introduce also for end user now in October, so my wishlist is:
stable prices, which correctly change according to the model at exactly on the hour or on 15mins
live consumption with websocket part of the API
statistics maybe configurable on minute basis?
optional:
some kind of pre-build “low price hours” or “high price hours” functionality, which is configurable on the current gross price and in best case is also a configurable time series. So, you type in your intervals (e.g. < 15ct, <25ct, <35ct, >35ct) and get a time series with those intervals to plan your future consumption on that?
(yes, there’s the current_level channel, but let’s be honest, the Tibber logic is not sufficient for a real smarthome?)
or like aWATTar you are able to add some kind of things, which calculate the best time for consumption for that device. But in best case also here I can change the variables for that device, so e.g. based on current SoC or whatever you can chose the period of consumption dynamically. In aWATTar, I have to configure daily static length of consumption and the thing calculates with this static inputs. I’d like to have the calculation dynamically.
Thing is, all those “optional” requirements are kinda fluent and may differ from one smarthome to another? e.g. with my, as I have both PV forecast and Tibber prices to calculate with and come up with the best way to postpone consumptions based on both PV and grid prices…
