That’s a valid point, although we are probably in a gray area here due to the generic nature of such data hubs providing all kinds of different data. I still think one binding could provide everything we would ever need from ENTSO-E.
You could also argue that the Bosch SHC binding is too broad, and we should rather have one binding focusing on lighting and merge this domain with the Hue binding.
IMHO a binding should provide an integration to a specific device or service. In this case we have a few different services that provides similar data. A binding should expose this data from the implemented service, but I’m not sure I agree to which extent it should utilize the data. This can be done outside the binding, for example by rules that can even be shared as templates on the Marketplace. Some parts can possibly be implemented in core if we come up with an API for this.
You could then as a user select:
- Service for obtaining data (prices): install binding.
- Rules for processing this data, for example calculating cheapest timeslots: marketplace/forum.
- Persistence/charts according to needs.
Now you are free to combine all those components as you see fit.
For Energi Data Service most of the work was implementing the infrastructure and API. At this point it would be very easy for me to add data on gas prices, for example. And already it contains tariffs and taxes which are variable in Denmark. So it does not make sense to perform any kind of calculation based only on the spot price.
Depending on your grid company, you will have different net tariffs. For example, in my area the net tariff is more than doubled from 17:00-20:00, and can often account for most of the price (exceeding the spot price). In some areas they have two different expensive periods, 17:00-21:00 and some hours in the morning.
The tax also changes from time to time, so if I’d be programming my dishwasher the night before July 1st 2023, I certainly would like the tax to be included in the “best price” calculation. In other words: We are solving the same problem. But for me, taking only the spot price into consideration is not sufficient.
For reference/comparison: README
Would you consider all of this as a candidate for being merged into the aWATTar binding?
If not, then you haven’t accomplished the goal of avoiding the redundancy you wanted to avoid by merging ENTSO-E and aWATTar. You did it only for those two, but you still have Energi Data Service, Tibber and possibly others. Even though we have different data sources and different data to take into account, we still need the same calculations to be performed on this data.
So you are suggesting to implement a “price optimizer” binding? Definition of a binding: “A binding is an extension to openHAB that integrates an external system like a software service or a hardware device.”
To me this doesn’t meet the definition.