jlaur
commented
3 weeks ago I'm marking this ready for review now, even though it's only the "middle" step/baseline. Tariff definitions are now in YAML, but periodization is not yet supported.
It's a bit more complicated than I initially thought. For example, when a console command requests persistence of period 01.01.2024-31.01.2024 and the tariff filter is changed per 16.01.2024, we need to calculate intersecting periods and handle them individually:
- 01.01.2024-15.01.2024
- 16.01.2024-31.01.2024
This needs to be rewritten: https://github.com/openhab/openhab-addons/blob/f37f39c03d0a65c174b05665f1c4ebe56f11e8c5/bundles/org.openhab.binding.energidataservice/src/main/java/org/openhab/binding/energidataservice/internal/handler/EnergiDataServiceHandler.java#L483-L498
And this also needs to be more sophisticated: https://github.com/openhab/openhab-addons/blob/f37f39c03d0a65c174b05665f1c4ebe56f11e8c5/bundles/org.openhab.binding.energidataservice/src/main/java/org/openhab/binding/energidataservice/internal/provider/ElectricityPriceProvider.java#L302-L316
All in all, it requires more work and testing.
I still think using YAML even without periodization is an improvement in its own right.
lsiepel
This should make grid tariff filters more readable and therefore easier to maintain.
The current draft is a baseline providing only the same functionality as with the filters provided by code. The next step is to add support for periodization.
With the introduction of #16656, historic tariffs can be persisted. When grid company make changes to the way they publish tariffs, filters need to be adapted. This can include moving a cutoff date and querying new charge code types and notes. Without periodization of the filters, it's not possible to persist historic tariffs. Additionally, it's not possible to take into account upcoming filter changes.