Hello,
maybe I missunderstood this suggestion with the transformation service.
If I implement a transformation service between the link from (for example) the total-gross-channel to the total-gross-item. Will the bestprice thing work with this “transfomed” values?
If yes, this would be a solution.
Transformations work on Things level, in my understanding before the value reaches the item. And as far as I get it it is within the scope of the binding to define whether transformations may be used and where they step in. Hence I would guess that it is possible to have the bestprice thing worked on the result of the transformation.
@tl-photography You are right, I know at least Tibber, aWATTar and Entso-E. Entso-E is the most flexible one as it supports all european pricing zones. Downside is that you need to create an account at Entso-E platform to request an API key, so it is not that easy to use compared to e.g. aWATTar which uses the open aWATTar API. But on the long run I think it would be a good idea to separate between price providers and usage-optimizing functions. The latter could then also provide even smarter functionalities, coordinating energy demands of different consumer devices with different priorities and daily usage profiles.
But Tibber and Entso-E don’t have the funktion with the bestprice-thing. If you want to seperate the functions, it would also be okay, to use another source for the bestprice-thing.
Yes, I second that - knowing I can’t contribute, as I’m no developer… 
As I started my journey I used the aWATTar-Binding as a Tibber customer. Simply because of the “bestprice”-Things i could add. The Tibber binding “only” does its magic with presenting dynamic prices. now I wrote a bunch of rules to reach my (personal) goal of orchestrating EV charging, whirlpool heating, dishwasher and washingmachine, etc. in combination with solar forecasting. From what I see, you could try to either write a rule templates for the marketplace or a seperate binding for “optimizing” the use of electricity. Both with the chance to combine dynamic pricing and own solar production.
But as the latest contributions here tend to point everything in a more complex environment. I think in Europe alone there’s more combinations of base tariffs with dynamic elements, than you can think of. I’m not only speaking of dynamic “Netzentgelte” (netwok fees?) in Germany, but also of the switch for shorter intervals (15min coming perhaps as soon as March this year?)… and so on. Would be a big task to have all of that combined, I guess…
In principle, the ENTSO-E binding if the way to go for fetching data for the energy price. All the other dynamic price suppliers will be based on these prices, with their fees and overheads applied.
Secondly, the pricing for the network operator has to be applied. I was not aware that this will also now be flexible. In Austria we don’t have this, afaik.
Then the optimisations and calculations should happen.
My idea of a better way of dealing with this would be to let a “Price Provider” (eg. ENTSO-E binding) fetch the data and have an simple optimisation binding, an “Optimizer”, do some calculations (as the aWATTar binding is doing it now).
In-between the operator fees can be applied, either by the by the “Price Provider” or the “Optimizer”.
I’m not sure if I can deal with such a task, I’m pretty time limited, but basically we could cave out the Optimizer from aWATTar and place it into another binding that would work for both, aWATTar itself or the ENTSO-E binding.
this would be a good and flexible solution I think.
I’d second that, if it wasn’t for the gross price coming from the respective API already. I’d expect to have Tibber, aWATTar et al having the respective gross prices per interval in their personalized APIs included. And I’d expect to have dynamic fees also included in that. Which would then made the “Optimizer” part obsolete and I’d argue, that’s the most complex one having to deal with all those parts - including the somewhat different price communication in each country. In Austria there’s mostly the spot price part in pricelists, wheras in Germany there’s the whole dynamic price (gross) per kWh on the lists. And on both you have to add the monthly non-dynamic parts of the basic fee…
You could also argue, to use only the net spot prices for calculations. That way you should have nearly most use cases in the equation as dynamic fees are usually (!) based on spot prices… but sometimes you’ll need to use the gross price “al-inkl” you’d pay per kWh. And if it’s for persistence only and graphical uses.
Some months ago I already stumbled over an article from @Kai , fortunately I found it again now: Energy management/calculations · Issue #3478 · openhab/openhab-core · GitHub. The topics we discuss (and which were already discussed in other threads in the last months, even years) all cover parts of a Energy Management Service, Can we join forces and try to start working on such an approach in which components like price providers, forecast services and energy consumers can be plugged together? Otherwise separate bindings will always only solve parts of the puzzle, but we will have similar functionality more or less duplicated at different places.
To get the prices is the one part. And what to do with this data is the other part. For this we need the Optimizer, like at the moment the “best-price-thing”.
If we can carve the “best-prize-logic” out and have it working with basically any items, yes. I misunderstood the “Optimizer” part as implementing personalized surplus on spot prizes only.
If I could wish for, I’d make it a tad more complex (sic!) as one regular requirement would be to add in some kind of variables like dynamic time lengths for achieving a goal.
use cases would be:
in the aWATTar binding currently you can “only” add a static time period. Back when I used that, I added multple periods and roughly calculated my use cases and used one or the other static periods best-price.
My idea behind the “optimizer” is that the use cases often compete for the same energy sourc(es), and some of them are bound to certain availability times. So PV delivers cheap energy, but only within a limited amount of time and with varying (expected) production. The grid delivers energy of varying costs, but with (practically) unlimited capacity. The battery has limited capacity and some loss when storing energy and consuming it afterwards, but is usually cheaper than the grid. Some consumers are available the whole day, others only at certain times. Sometimes I get money for delivering power to the grid, sometimes I will not. The charging rate for both cars and batteries is somehow limited. The house has a continuous basic energy consumption plus some unpredictable consumers, So optimization means to distribute the load of the controllable consumers over the day in a way that fits best to the expected production and the energy pricing.
And as I am a very visual person, I would like to be able to see the result of the optimization in some kind of graph, so that I can verify that the system behaves the way I expect it to, and potentially allow for corrections.
(Ok, some dreaming included 
)
That would be indeed a very thorough and thus very effective way to distribute energy, if it is not only reliant on one source, but multiple. In coming years, there’s certainly even V2H joining the equation!
but not to say it wouldn’t be a goal, but I think it’s a very complex task to even configure all the sources you mentioned and combine that with all that consumers. In my rules I tried to achieve that with some kind of priorisation and the maximum delivery of battery and PV, but soon enough I just left it. Because even if I knew the consumption curves of let’s say a dish washer, it could differ, if for some reason I changed the program. And most of the times even if dish washer and washing machine start simultaneously the curves just so are shifted, that nearly never they’ll top of with their maximum at the same time. Which means basically I’m fine with some “fuzzy” consumption patterns and sometimes having to buy from the grid for a few Wh, instead of flatten it out. Yes, my inner Monk also rebells against having to buy and an hour later I’ll feed in PV power to the grid, because no major device is running!
tl;>dr:
If the “optimizer” part would not only calculate the “best (quarter) hours” seperately for each device, but would also distribute them, that would be super nice. Which would mean, there has to be not strict static inputs like today, but dynamic ones. Meaning, you have to “register” or “activate” a consumer for a certain period and a certain expected energy consumption (e.g. a running dish washer: 3hours for 1,5kWh) and perhaps a priorisation (e.g. washing machine is less critical as a heating pump), and have the inputs change (e.g. the heating pump runs for 5h a day in winter depending on outside temperature and nearly none in summer)…
From my point of view I see:
So the first thing would be to define the objects we deal with and their attributes (what @Kai started already in his post).
The real fun then goes into the optimizer algorithm. No idea how to approach that
I believe I mentioned this somewhere: Vectron energy, who is a manufacturer of Energy Storage Systems (i.e. PV inverters and battery inverters) have implemented something that they call “Dynamic ESS” which is supposed to have an algorithm that take energy prices, weather forecast and usage patterns into account when trying to achieve minimal grid cost. Not trying to promote this in any way, but to my knowledge they have also published a Node-RED flow with the optimization algorithm which might help to point things in the right direction.
Oh, it’s complex all-over, consumers are very much different all along. Heatpumps differ from EVs differ from white goods in terms of interruptability, predictability of runtimes and amount of future consumption, controllability etc.
Some things you just cannot compute, for example heat pumps you just cannot know how much they’re going to consume the day.
Don’t expect to find the Holy Grail of algorithms anytime soon. I’ve built a commercially available energy management system based on openHAB so I know what I’m talking about.
On the algorithm part, check out this thread, has Control a water heater and ground source heat pump based on cheap hours of spot priced electricity
Hi all,
This optimizer already has quite flexible algorithms. It is agnostic to the price providers and weather forecast providers, I.e. you can use the Binding of your choice as long as they persist the data as a proper Timeseries using the Forecast persistence strategy.
The load balancing stuff / distributing different devices to run at different times are also included. Interruptions / consecutive run times have their own algorithms as well. And there is a capability to select the time window when the device needs to be on. And results can be visualized using openHAB charts.
I dont have PV or battery myself so optimizations around solar forecasts and actuals need to be developed.
Full documentation:
Community thread fir discussions:
Cheers,
Markus
P.s. this is the same solution that evolved from the thread that @mstormi linked in his message above
My main point here is that bindings like aWATTar, tibber and ENTSO-E are mainly delivering input for a separate “Optimizer”.
Other bindings, let’s say for a EV or a heat pump, deliver input parameters like SoC, demand periods and power demand(s). But thy also accept setpoints.
The “Optimizer” should be a separate binding, taking inputs and sending optimized setpoint(s). Attention, this is very very simplified.
In order to combine force and keep overhead low, this should be a community effort to bring such kind of binding in OH.
There are already solutions, as mentioned here before, but the are spread out into different approaches and are developed individually.
Until OH comes up with a solution to this, it will stay that way. I’m sorry to say that, but it lies in the hands of the maintainers to steer this into a more unified direction.
For my part, I can extend the aWATTar binding with certain features and would be available for a unified approach, but I can’t make and will, due to time limitations, not take further actions on this.
Hi, can anybody say if this would work? This could be the first little step.
Thanks
I completely agree with this. And weather forecast bindings can be added to that list because it is critical input for optimizing the heating and different weather forecast providers are more accurate on other regions than the others and the user must have the freedom to choose their provider. Just like the user needs to have freedom to choose their price provider because different regions may have very different pricing schemes.
This is exactly the reason why I de-coupled the openHAB Spot Price Optimizer from the price and weather forecast fetching logic now that Entso-E binding and multiple weather forecast bindings have timeseries support.
Again I agree completely with this. Obviously the optimizations need also other input parameters, which can easily be implemented as Items already now.
I don’t know if the optimizer need to be a Binding or what it should be, but it definitely should be de-coupled from the input providers exactly like you suggest. And I also completely agree with the community effort to have an unified approach for this.
Markus
Yes, de-coupling those requirements from the data providers seems like the best way to go forward. Perhaps the configuration within the Optimizer could be done via configuring existing items for various inputs. I’m thinking of how widgets work. So for each energy provider (grid, PV, battery,…) there must be a bunch of items, which are used within the Optimizer.
or, if that doesn’t work for some reason, the Optimizer can come with its own set of items, and you simply point your existing items to that (e.g. via “follow” profiles?).
I also can’t contribute code (no dev skills), but I can contribute concepts or can test stuff certainly.