I agree that we should not merge Tibber, aWATTar, Entso-E and Energi Data Service into a single binding. I’ll add that I have also been considering implementing a binding for Eloverblik which provides tariff prices as well as metering data.
- Energi Data Service: Provides electricity spot prices as well as Danish tariffs and taxes. There as several other datasets available, including CO2 emissions, gas, production/consumption/transmission lines etc.
- Eloverblik: Provides Danish tariffs, taxes and metering data. Metering data is also provided by the DSMR and SmartMeter bindings. (Note: binding doesn’t exist yet)
- Tibber: Prices/consumption data.
- aWATTar: Prices.
- Entso-E: Prices and a lot more. (Note: binding doesn’t exist yet)
Merging all this into a monolith of a binding would IMHO introduce more problems than it would solve.
However, I agree about joining forces, and I think we could design an architecture making it possible to share code/logic/algorithms/API’s. Or at least - on short-term - perhaps standardize some ways to interact with these bindings. The dynamic things in aWATTar looks interesting, this is something I plan to look closer at.
Energi Data Service is currently ~9500 lines of code in total. ~250 lines for generic price calculations not directly coupled with the API. Actions accounts for ~400 lines of code, which is mostly boiler-plate code for calling the calculator with provided data.
See also: Energy management/calculations · Issue #14181 · openhab/openhab-addons · GitHub
And parallel thread: aWATTar binding: Beta and discussion