# Feature Request: TimeOfUse controller: Discharge to grid

**URL:** <https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663>\
**Category:** English Forum\
**Created:** [May 14, 2024, 7:06am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663 "2024-05-14T07:06:53Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![yvesilknievil](https://community.openems.io/letter_avatar_proxy/v4/letter/y/43a26b/32.png) [@yvesilknievil](https://community.openems.io/u/yvesilknievil)\
**Post date:** [May 14, 2024, 7:06am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/1 "2024-05-14T07:06:53Z")

</div>

Hi all

User in Belgium here. I understand German rules are perhaps a bit different.

I have a 50kWh battery pack and have a dynamic energy contract.  
Over the last few weeks, I see quite often some negative prices, which means I end up paying for injecting to the grid.  
I have implemented a “disable feed” so I do not inject to the grid when the prices are negative.

Currently, I wake up with a battery pack at 80% capacity. It quickly fills up and by noon, the battery is full. As of then, I limit the injection to the grid and thus significantly impact my PV yield, as it only covers my consumption.

I have implemented a very basic: If SPOT price is high between midnight and noon, use the crtlFixActivePower to discharge to grid. However, I would like to be able to use the prediction values to actively discharge my battery pack when the prices are high.

Could the TimeOfUse controller handle this too? My java skills are not great - hence this feature request.

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [May 14, 2024, 8:25pm UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/2 "2024-05-14T20:25:00Z")

</div>

Hi,

that’s a very interesting use-case. I was not aware that this is already possible in Belgium. Could you share some more documentation to read up on the details of this? Is your feed-in-tariff directly coupled to day-ahead/spot prices?

I am still heavily working on restructuring the Time-of-Use Tariff Controller to make the features available for different multi-use applications, so I might not yet be ready to accept PRs here. But first step to start your “SELL\_TO\_GRID”-mode would be to add a new mode here → [openems/io.openems.edge.controller.ess.timeofusetariff/src/io/openems/edge/controller/ess/timeofusetariff/StateMachine.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.controller.ess.timeofusetariff/src/io/openems/edge/controller/ess/timeofusetariff/StateMachine.java#L6-L8)

And then check your Eclipse warnings and see where this change requires you to make adaptions. E.g. you will have to adjust the internal cost-function to handle SELL\_TO\_GRID “costs”. → [openems/io.openems.edge.energy/src/io/openems/edge/energy/optimizer/Simulator.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.energy/src/io/openems/edge/energy/optimizer/Simulator.java#L96-L115)

Regards,  
Stefan

---

<div class="post-metadata">

**Author:** ![yvesilknievil](https://community.openems.io/letter_avatar_proxy/v4/letter/y/43a26b/32.png) [@yvesilknievil](https://community.openems.io/u/yvesilknievil)\
**Post date:** [May 15, 2024, 5:45am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/3 "2024-05-15T05:45:00Z")

</div>

Hey Stefan,

Thank you for your reply.

In terms of details; there aren’t any restrictions in Belgium (at least for residential or SME customers).

For residential customers, the only limitation is that your inverter can only output 10kWp. If you want to exceed this, you can ask for a (free) grid study so you can go up to 25kWp (which I did). If you want more, more restrictions apply. Unfortunately all documentation is very regionalised, so it’s only available in Dutch (my area). If you need more, I can translate it for you.

My dynamic tariff used to have a 1 on 1 mapping with the spot prices. Now, my energy provider has introduced a margin for injection: -0,9050 + 0,1000 x ESPOT, which basically means they are taking 0.01 euro per kWh. It means that if I inject when the SPOT price is less than 10 euro per MWh, I end up paying. I guess this has to do with the increased unbalance costs. There are also no grid costs when injecting.

When importing, there are a lot of taxes in BE added (grid costs), and the base formula is 1,1000 + 0,1000 x ESPOT.

I’ll have a look at the places to include this function.

Thanks again

Yves

---

<div class="post-metadata">

**Author:** ![as\_py](https://community.openems.io/letter_avatar_proxy/v4/letter/a/8baadc/32.png) [@as\_py](https://community.openems.io/u/as_py)\
**Post date:** [March 17, 2025, 9:37am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/4 "2025-03-17T09:37:56Z")

</div>

Dear Stefan, dear Yves,

as almost a year passed since the last post, I wanted to ask if there is any update about this. I‘m in a very similar situation as Yves, only in Austria instead of Belgium: Using openEMS to manage a plant with PV and quite large BESS using dynamic prices for both buying from and selling to grid.

Generally ToU works good, thanks for all that work Stefan. However, already now, the BESS often stays above 70% and is fully charged already before noon. Then I have the option of either disabling PV, or selling to grid with very low, or even negative prices.

I also implemented some basic logic to control the grid feed based on variables, but I feel like the best option would be to include this in the ToU algorithm, making it complete for all use cases. Did any preparation for this happen in the last year, or is it maybe already in the make?

Thank for your work and help,

Alex

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [March 17, 2025, 4:54pm UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/5 "2025-03-17T16:54:15Z")

</div>

Hi Alex,

there is no finished version yet, but a lot of ground-work has happend in the Time-of-Use / Energy Scheduler (v2) implementation.

At least here in Germany dynamic-feed-to-grid is not yet as relevant as in Belgium, because it’s only allowed with an external trader (“Direktvermarkter”).

This thread might be interesting for you:

> [@Dependency Problem Google ORTools](https://community.openems.io/t/dependency-problem-google-ortools/5787/10):
>
> Das wäre super, wenn ich mich da einmal per Teams melden könnte, das Angebot nehme ich gerne an! Mein Code ist gerade noch in Bearbeitung sobald ich hier eine Runde Sache habe, würde ich mich nochmal melden. Der Workaround über Python ist nicht optimal und sicher keine dauerhafte Lösung. Gerne arbeite ich hier bei einer reinen OpenEMS-Lösung mit! Angewendet werden soll es sowohl in einer Simulation als auch auf der im Rahmen des Forschungsprojektes [SKALE](https://www.batterietechnikum.kit.edu/Projekte_995.php) aufgebauten Ladestation mit 12 DC-Ladep…

We are currently planning a OpenEMS Networking Friday on Energy Scheduler v2 for developers. It’s scheduled for 4th April 2025 at 2pm.

Regards,  
Stefan

PS: My usual sentence: If you use OpenEMS in production it would be great if you could join OpenEMS Association e.V.; it’s not too expensive and supports the project a lot.

---

<div class="post-metadata">

**Author:** ![as\_py](https://community.openems.io/letter_avatar_proxy/v4/letter/a/8baadc/32.png) [@as\_py](https://community.openems.io/u/as_py)\
**Post date:** [March 18, 2025, 9:00am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/6 "2025-03-18T09:00:15Z")

</div>

Dear Stefan,

first of all, thanks for your detailed answer! I already tried to get more into the changes introduced by EnergySchedulerV2, but still not having the full view.

Do I understand correctly: At the moment, ToU supports the three modes, but it is limited to a single ESS and not making use of any other assets such as EVs or Heat Pumps. With v2, this will change, at least including energy-consuming assets. What other fundamental changes in the usage field that Yves and me are covering are interesting?

Also, to me it seems that the function desired by Yves and Me will not be included therefore. In which way will it get easier to implement this behaviour? I assume, if it’s already common in AT and BE, it will also come to DE earlier or later and it might be nice to already support it from the begin on.

Also thanks for your offer to participate in the Association, will definitely consider that when proceeding further!

Best,

Alex

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [April 1, 2025, 10:29am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/7 "2025-04-01T10:29:29Z")

</div>

FYI: we are organizing a Networking Friday to gather all interesting people:

> **[NetworkingFriday: 4/4 OpenEMS Energy Scheduler v2 & Genetic Algorithms |...](https://www.linkedin.com/events/7312371781917442048/)**
>
> Stefan takes a deep dive into the current development around Energy Scheduler v2, Genetic Algorithms and Time-of-Use-Tariff optimization in OpenEMS. This Networking Friday specifically targets software developers in the OpenEMS Community who want to...

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [May 1, 2025, 6:17pm UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/8 "2025-05-01T18:17:39Z")

</div>

@yvesilknievil, @as_py: I’ve been playing with implementing this feature in Energy Scheduler v2 recently and it looks promising:

 ![grafik](https://community.openems.io/uploads/default/original/2X/0/0cfe499feb1ddc76844920f3064d71431b9e1ab2.jpeg)  
 ![grafik](https://community.openems.io/uploads/default/original/2X/a/acc3969fdf5613d2fe1b9f66f5f7d456aeb732f2.png)

The code is already on `develop` branch. You just have to configure

- `controlMode` to `DISCHARGE_TO_GRID` ([openems/io.openems.edge.controller.ess.timeofusetariff/src/io/openems/edge/controller/ess/timeofusetariff/Config.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.controller.ess.timeofusetariff/src/io/openems/edge/controller/ess/timeofusetariff/Config.java#L26-L27)) and
- `version` to `V2_ENERGY_SCHEDULABLE` in the Energy-Component ([openems/io.openems.edge.energy/src/io/openems/edge/energy/Config.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.energy/src/io/openems/edge/energy/Config.java#L21-L22))

As discussed in networking friday, you can of course also simulate it via the [RunOptimizerApp](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.energy/test/io/openems/edge/energy/optimizer/app/RunOptimizerApp.java).

I am very interested in hearing your feedback!

Regards,  
Stefan

---

<div class="post-metadata">

**Author:** ![as\_py](https://community.openems.io/letter_avatar_proxy/v4/letter/a/8baadc/32.png) [@as\_py](https://community.openems.io/u/as_py)\
**Post date:** [May 2, 2025, 8:34am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/9 "2025-05-02T08:34:13Z")

</div>

Dear Stefan,

wow, thank you a lot for the work! We will definitely test this in near future and come back to you about our experience!

Best, have a nice weekend,

Alex

---

<div class="post-metadata">

**Author:** ![as\_py](https://community.openems.io/letter_avatar_proxy/v4/letter/a/8baadc/32.png) [@as\_py](https://community.openems.io/u/as_py)\
**Post date:** [May 8, 2025, 12:01pm UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/10 "2025-05-08T12:01:57Z")

</div>

Dear Stefan,

we implemented the new controller and Tuesday evening and unfortunately, it didn’t work so far. I did not have time to look into it in detail, will do that beginning of next week, but i still thought it might be nice to share it with you, in case you immediately spot the problem. It is a Sigenergy system with 30kWp and 96kWh.

 ![Bildschirmfoto 2025-05-08 um 13.27.35](https://community.openems.io/uploads/default/original/2X/a/a0c5c8d5c86c18cace7a93f180de2dcd191b40bc.jpeg)  
 ![Bildschirmfoto 2025-05-08 um 13.28.04](https://community.openems.io/uploads/default/original/2X/5/5e1635a01882108d6f4fbd7a623c3367d90d8bc3.png)  
(ignore the missing data in the second plot from 11-12, this is just a dashboard issue)

As you can see, it never fed in, even when the ToU controller said so: At 14:00, 100% SoC was reached and it actually reduced the production, even though the price would have been high enough to feed in.

Then, it gets even weirder: Whenever DISCHARGE\_GRID is active, it completely disables the production and takes all power from the grid, not from the battery. From 18:45-19:00 BALANCING was active, at 19:00 DISCHARGE\_GRID started again and actually used energy from grid to charge from 99% to 100%, which was completely unnecessary at this point.

Do you have any ideas what could cause this? As said before, I will have time to take a closer look at the beginning of next week.

Best and thanks again,

Alex

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [May 12, 2025, 11:37am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/11 "2025-05-12T11:37:16Z")

</div>

@as_py: Thanks for the experience report! I don’t know the Sigenergy implementation - is it open source somewhere?

It would be interesting if a discharge command (i.e. a positive set-point value) was sent to the ESS at all. Can you please plot the Channel `ess0/DebugSetActivePower`?

---

<div class="post-metadata">

**Author:** ![as\_py](https://community.openems.io/letter_avatar_proxy/v4/letter/a/8baadc/32.png) [@as\_py](https://community.openems.io/u/as_py)\
**Post date:** [May 12, 2025, 12:22pm UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/12 "2025-05-12T12:22:07Z")

</div>

Hello Stefan,

thanks again for your reply! Unfortunately, the Sigenergy implementation is not publicly available at the moment, as it is still in development and apparently also not working correctly. I also didn’t implement it myself, but I will talk to the developer about a release.

As desired, I added the channel `ess0/DebugSetActivePower` to the plot:

 ![Bildschirmfoto 2025-05-12 um 14.19.09](https://community.openems.io/uploads/default/original/2X/b/b762e1ed855420e814bdd276c84494eef419127e.png)

So a discharge command was definitely sent to the ESS, but never executed.

Best,

Alex

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [May 13, 2025, 8:58am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/13 "2025-05-13T08:58:22Z")

</div>

Ok, then it’s as expected: DISCHARGE\_TO\_GRID was working, but the ESS implementation did not actually apply the set-point properly. I cannot help much without seeing the code then, sorry. Maybe consider switching to a well-supported FENECON system then… 😉

---

<div class="post-metadata">

**Author:** ![as\_py](https://community.openems.io/letter_avatar_proxy/v4/letter/a/8baadc/32.png) [@as\_py](https://community.openems.io/u/as_py)\
**Post date:** [May 13, 2025, 9:49am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/14 "2025-05-13T09:49:28Z")

</div>

We actually also have a FENECON system running 😉, as well as one from Huawei. We will conduct further tests and come back to you with feedback and/or code. Thanks! Also feel free to ping me at any time in case there is any update or question from your side!

Related question, just to make sure: Do I assume correctly that at the moment, the same price is considered for buying from and selling to grid? Mostly irrelevant at the stage we are right now, but in the future it might be necessary to differentiate (buying: EPEX price + fees + tax + grid costs, selling: EPEX price - fees).

---

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [May 13, 2025, 9:57am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/15 "2025-05-13T09:57:48Z")

</div>

> We actually also have a FENECON system running 😉, as well as one from Huawei. We will conduct further tests and come back to you with feedback and/or code. Thanks! Also feel free to ping me at any time in case there is any update or question from your side!

Thank you. If you can share the code, it would be beneficious for the community and I could surely support better.

> Related question, just to make sure: Do I assume correctly that at the moment, the same price is considered for buying from and selling to grid? Mostly irrelevant at the stage we are right now, but in the future it might be necessary to differentiate (buying: EPEX price + fees + tax + grid costs, selling: EPEX price - fees).

Yes, but the current time-of-use controller logic does not contain a full arbitrage algorithm, i.e. it would never charge from grid just to discharge to grid later. The current logic essentially just evaluates if there is more energy in the battery than is required during the night and discharges accordingly at the highest EPEX price.

---

<div class="post-metadata">

**Author:** ![yvesilknievil](https://community.openems.io/letter_avatar_proxy/v4/letter/y/43a26b/32.png) [@yvesilknievil](https://community.openems.io/u/yvesilknievil)\
**Post date:** [June 2, 2025, 10:20am UTC](https://community.openems.io/t/feature-request-timeofuse-controller-discharge-to-grid/2663/16 "2025-06-02T10:20:16Z")

</div>

Hi @stefan.feilmeier

I installed the latest release today and I’ll be testing it and coming back with feedback!

Thanks for the amazing work
