Info about json format for ancillary costs in timeOfUseTarrif entsoe

sjjh · July 1, 2025, 7:11am

I did find the component Time-Of-Use Tariff ENTSO-E in the UI. I’m wondering how to configure it. It expects as a mandatory field a json string for ancillary costs. I did find below code, where the string seems to get parsed. Unfortunately I fail to understand the format of the expected json string. Could someone give me an example or hint to some documentation, how the json string is expected to look like? Thanks in advance!

github.com/OpenEMS/openems

io.openems.edge.timeofusetariff.entsoe/src/io/openems/edge/timeofusetariff/entsoe/AncillaryCosts.java

0f7119c2c


      
          	/**
          	 * Parses the ancillary cost configuration JSON into a schedule of
          	 * {@link Task}s.
          	 * 
          	 * @param biddingZone    the {@link BiddingZone}
          	 * @param ancillaryCosts the JSON configuration object
          	 * @param logWarn        a {@link Consumer} for a warning message
          	 * @return an {@link ImmutableList} of {@link Task} instances representing the
          	 *         schedule
          	 */
          	public static ImmutableList<Task<Double>> parseToSchedule(BiddingZone biddingZone, String ancillaryCosts,
          			Consumer<String> logWarn) {
          		if (ancillaryCosts == null || ancillaryCosts.isBlank()) {
          			return ImmutableList.of();
          		}
          		try {
          			var j = new JsonObjectPathActual.JsonObjectPathActualNonNull(parseToJsonObject(ancillaryCosts));
          
          			return switch (biddingZone) {
          			case GERMANY //
          				-> parseForGermany(j);

Sn0w3y · July 1, 2025, 12:01pm

It is there.

sjjh · July 1, 2025, 1:13pm

sry, can you elaborate? I don’t find information about the structure of the json file.

stefan.feilmeier · July 1, 2025, 7:44pm

Hi @sjjh,

the feature for ancillary costs is designed (for Germany) to support two different ways of providing the additional costs. In Germany those “zeitvariable Netzentgelte” are provided by the DSOs in “Preisblätter”.

Predefined Costs in the GermanDSO enum → openems/io.openems.edge.timeofusetariff.entsoe/src/io/openems/edge/timeofusetariff/entsoe/GermanDSO.java at develop · OpenEMS/openems · GitHub

This is the preferred way as it avoids errors. Together with the community we plan to hold an updated list of costs of most German DSOs here. By providing them as code we can do some automated validation and tests.

If your DSO is already in the list (and the data is up-to-date), you can simply activate the costs by configuring TimeOfUseTariff.ENTSO-E with:

biddingZone: GERMANY
ancillaryCosts: {"dso":"BAYERNWERK"}

The JUnit test shows this configuration → openems/io.openems.edge.timeofusetariff.entsoe/test/io/openems/edge/timeofusetariff/entsoe/TouEntsoeTest.java at develop · OpenEMS/openems · GitHub

If your DSO is not yet in the list, I’d ask you to add a Pull-Request with the price definition in GermanDSO.java and proceed the same way as above; or:

Define the costs via manual JSON configuration.

This is unfortunately not yet supported. See openems/io.openems.edge.timeofusetariff.entsoe/src/io/openems/edge/timeofusetariff/entsoe/AncillaryCosts.java at develop · OpenEMS/openems · GitHub

Hope this helps. As this is still a quite new feature I am happy to receive feedback.

Regards,
Stefan

(@venu-sagar FYI)

stefan.feilmeier · July 1, 2025, 7:54pm

In German: ein paar Hintergrundinformationen warum wir dieses Feature für FEMS implementiert haben, zeige ich in diesem Video:

sjjh · July 1, 2025, 8:15pm

I did find the Preisblatt of our DSO Netze ODR:

Netze ODR is not yet in the list. The PDF contains different price information. Can you give me a hint which one is the relevant one? I’ll then happily try to provide a PR.
Thanks!

stefan.feilmeier · July 2, 2025, 6:37am

The relevant data for your DSO is on page 4:

You should then convert those dates and prices (“Arbeitspreis Brutto”) to DateRanges in GermanDSO.

sjjh · July 2, 2025, 6:02pm

I wasn’t sure, if I had to add any other prices from other tables to it…

So I created a PR (first on code in this repo), please review: Update GermanDSO.java: added DSO Netze ODR by sjjh · Pull Request #3224 · OpenEMS/openems · GitHub.
Thanks!

sjjh · July 2, 2025, 8:58pm

Thanks for the explanation. Great feature.

I believe, especially if the community gets bigger and more end users (less developers) use it, the two use cases of how to add new DSOs and update (yearly – if I understood correctly) prices could maybe made easier. I could imagine some web form to add these data, either on openems.io or maybe embedded in the OpenEMS UI. The UI should IMHO automatically pull updates if the time frame of the data ends, and maybe a manual refresh via a button/trigger is sensible, e.g., on first initialization, in case a before missing DSO is included, or if the user changes their DSO (moving).

The selection of the DSO could be made easier by offering a drop-down with all available DSOs in the component in the OpenEMS UI. As soon as it is implemented to manually add a json string, the drop-down could include an element otherwhich would enable a free text field (ideally with either a dummy blueprint or some context help)

So far feedback from a first time user.

venu-sagar · July 3, 2025, 11:40am

Dear @sjjh ,

That’s amazing! We were thinking along the same lines and have already started working on this. The implementation is currently in progress, though everything is still local for now. Once it’s ready, I’ll link it to the PR. In the meantime, you can check out the progress through the attached screenshots.

Note: there are still some adjustments here and there, but final version would look something close to this.

Thank you,
Sagar

sjjh · July 4, 2025, 12:16pm

Cool, looks great. I could imagine adding a String name to the DSO enum, to make it look a little bit less technical. E.g., displaying SH Netz instead of SH_NETZ to the user in the drop-down (this could also enable l10n, OTHER → anderer). For the price items, I might be wondering if VAT should be included or not, adding brutto to the label could avoid this question.

Not sure about the logic in the background – if a new entry is added by a user, it obviously would be great to push it upstream and distribute it to other users. I don’t know enough about the domain, but it seems that typically the prices are only valid for a year. Thus I could imagine, that it would be interesting to:

remind users to update their prices at the end of the year
offer an update of prices independently of OpenEMS update

BTW, I think the UI of the drop-downs could be improved in general. In landscape mode adding a max-width (e.g., 80 em) could improve the usability a bit. But that’s unrelated to the entsoe implementation.

Thanks for your work!
Simon

stefan.feilmeier · July 12, 2025, 10:26pm

FYI: the JSON parser for custom ancilliary costs has been merged with

displaying SH Netz instead of SH_NETZ to the user in the drop-down (this could also enable l10n, OTHER → anderer).

This has been implemented as well.