[energidataservice] Suggest to provide actions as core base class

[weymann]

Proposal
The binding provides Thing Actions in order to calculate best prices for a dynamic tariff. In principle every binding providing such data shall have the same calculations too. E.g. Tibber, aWATTar, Entso-E, ...
In order not every binding developer is doing his own calculations a base class would be helpful.

Idea
Just my first thoughts:
Provide BaseTariffActions with the implemented Actions. This base class shall be updated with the latest TimeSeries of spot prices as basis for the calculations.
Honestly I don't like the two seperate lists of duration and power phases so maybe it's possible to combine it in a TreeMap with startingMinute and power. As an additional option a well defined JSON may also fit.

Thinking further
Imagine Things like Shelly Plug which are attached to e.g.. laundry or dishwasher can provide such power curves in actions too. So I can get a common power curve for my device and directly feed it to my dynamic tariff provider.

Feel free to place your comments and thoughts. If you're too busy I'm really interested to design and implement a first version and we can do it together as joint work.

[jlaur]

@weymann - thanks for starting this discussion, for your suggestion and for you willingness to join such an effort. Since this should be solved in core, I'm closing the issue for Energi Data Service here in the addons repository. A few references for you:

• Energy management/calculations openhab-core#3478 - this is where the discussion should be continued. Please read through the whole discussion where Kai already drafted an architecture.
• [aWATTar] Add aWATTar API class #17169 (comment) - a recent discussion (also to be continued in the core issue)
• Just say to say: I agree with the approach even before finally contributing the Energi Data Service binding:

  openhab-addons/bundles/org.openhab.binding.energidataservice/src/main/java/org/openhab/binding/energidataservice/internal/PriceCalculator.java

  Lines 37 to 48 in 6c77b16

  	/**
  	* Provides calculations based on price maps.
  	* This is the current stage of evolution.
  	* Ideally this binding would simply provide data in a well-defined format for
  	* openHAB core. Operations on this data could then be implemented in core.
  	* This way there would be a unified interface from rules, and the calculations
  	* could be reused between different data providers (bindings).
  	*
  	* @author Jacob Laursen - Initial contribution
  	*/
  	@NonNullByDefault
  	public class PriceCalculator {

[weymann]

I agree to close this topic in addons repo.
But ahh no!!! Just reading a glimpse of this thread makes me wonder!
Everybody is seeking for the holy grail of HEMS but I just want to know the best price. No more, no less!

And this should be the seperation of concerns. I don't want to implement an HEMS, just give me the price!