Force battery discharge during high-price peak spikes

[sincze]

Area of the proposal

Energy management or control strategy

What problem would this solve?

Currently my battery management strategy focus on smooth charging/discharging cycles based on average daily rates or standard consumption. However, dynamic energy tariffs frequently experience extreme, short-duration price spikes (e.g., brief evening peaks). Without an explicit trigger or rule to respond to these sharp spikes, the battery may miss high-value export or self-consumption opportunities that could significantly improve overall ROI over the course of a year.

Proposed solution

Add a feature or automation trigger that allows for forced battery discharging when dynamic energy prices exceed a configurable upper threshold (or during detected peak spike intervals).

• Configurable Price Threshold: Ability to set a trigger price (e.g., $\text{Price} \ge 0.50 \text{ EUR/kWh}$) where the battery is instructed to discharge at maximum safe capacity to either cover home load or export back to the grid.
• Peak Spike Priority: Ensure this action can override normal "hold" or "idle" states when a temporary, high-value opportunity occurs.

Example use case

Taking yesterday evening's price curve as an example:

• Dynamic prices hovered around 0.30 EUR/kWh during the day and dropped near 0.12 EUR/kWh around midday.

• At 19:45, the price spiked sharply to 0.70 EUR/kWh—nearly triple the daily baseline.

• Action: Detecting this sudden peak above the baseline threshold would trigger a forced discharge period, maximizing grid export earnings (or offsetting expensive grid imports) during that exact window before prices normalize again.

Who would benefit from this?

Most Omnibattery users

Alternatives or workarounds

Create a Forced Discharge Automation ?
Via Settings > Automations & Scenes > Create Automation > Edit in YAML

Something like ?

alias: "Marstek Venus: Force Discharge on Peak Price"
description: "Triggers forced discharge on high prices and stops at low price or low SoC."
mode: single

trigger:
  - platform: numeric_state
    entity_id: sensor.YOUR_PRICE_SENSOR
    above: 0.35 # Set your peak price threshold here (e.g., €0.35/kWh)
    id: "start_discharge"
  - platform: numeric_state
    entity_id: sensor.YOUR_PRICE_SENSOR
    below: 0.25 # Set your price floor to stop discharging
    id: "stop_discharge_price"
  - platform: numeric_state
    entity_id: sensor.marstek_venus_battery_state_of_charge
    below: 20 # Minimum safety reserve percentage to stop discharging
    id: "stop_discharge_soc"

condition: []

action:
  - choose:
      # Condition to START forcing discharge
      - conditions:
          - condition: trigger
            id: "start_discharge"
          - condition: numeric_state
            entity_id: sensor.marstek_venus_battery_state_of_charge
            above: 20 # Only discharge if we have remaining energy
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.marstek_venus_discharge_control

      # Condition to STOP forcing discharge
      - conditions:
          - condition: or
            conditions:
              - condition: trigger
                id: "stop_discharge_price"
              - condition: trigger
                id: "stop_discharge_soc"
        sequence:
          - service: switch.turn_off
            target:
              entity_id: switch.marstek_venus_discharge_control

Additional context

Confirmations

• I searched existing discussions and did not find the same proposal.
• This is a general feature idea, not a request to support a new battery brand or model.
• I understand that community interest and technical feasibility influence prioritization, and that no delivery date is guaranteed.
• I removed passwords, tokens, API keys, complete serial numbers, IP addresses, and other sensitive information.

[github-actions[bot]]

Thanks for the suggestion! 🙌

Here's how this works:

• Vote by clicking 👍 on the original post — not in the comments
• The more votes an idea gets, the higher it moves in the priority queue
• I review feature ideas periodically and implement the ones that benefit the most users

If your idea is very specific to your setup, it may not make it into the core integration — I'll try to suggest a workaround in that case.

Feel free to discuss details or alternatives below.

[sincze]

I currently have

But that helps me 'smart' charging' and discharging I think based upon the needs of my home. (at least that is what I understand out of it). The $$$ setting for (forcingly) selling my previous stored kWh I indeed do not see.

[Maumau82]

Where / how do you see this?

[sincze]

It would be nice if we could force discharge when something like this happens )high pricing).

Probably we can create an automation separately but I thought it would be nice if the EMS could help here ;-)

[rrozema]

Sorry, I removed my previous comment as it did not match the feature request.

[onlineous]

Proposed solution

Add a feature or automation trigger that allows for forced battery discharging when dynamic energy prices exceed a configurable upper threshold (or during detected peak spike intervals).

• Configurable Price Threshold: Ability to set a trigger price (e.g.,
  Price
  ≥
  0.50
   EUR/kWh
  ) where the battery is instructed to discharge at maximum safe capacity to either cover home load or export back to the grid.
• Peak Spike Priority: Ensure this action can override normal "hold" or "idle" states when a temporary, high-value opportunity occurs.

Hi fellow dutchie :)

If I understand your proposal correctly I see a problem:

Let's say prices are 51 cents for every kWh for 2 hours. Your battery discharges as much as possible.
The remainder of the night the prices are stuck at 'only' 48 cents for every kWh.

You now need to buy electricity for the remainder of the night. That might not cost you money in 2026, but in 2027 that's definitely costly (if I understand your proposal correctly).

My proposal for this would be:

• Calculate how much energy the house is going to need until the sun will start shining again.
• Add a configurable safety margin to this prediction.
• Configure how quickly the battery is allowed to discharge.
• Find the most expensive 15 minute slots.
• Calculate the optimal strategy to discharge during this period
• Execute this strategy.

Unless I understood your proposal incorrectly, 'natuurlijk' ;)

[onlineous]

You can 'push the solar out' by setting the "Target Grid Power" to the negative amount of the solar produced.

I was actually just looking into that! It can definitely be done, but is a bit more involved, because:

• I need to override my normal time block in Omnibattery and make sure this override is being negated when it's necessary."
• If the amount of power being discharged is low(er) this impedes the Self Consumption mode of the battery.
  Example: solar panels generate 400 watts together. Someone starts cooking and ideally the battery should now discharge 1.5kW instead of the 400 watts.

Both can be done, but need to be done carefully to make sure there are no unintended consequences.

[rrozema]

My feature request for the price of the energy in the battery sensor is #269. My other feature proposal , #237, builds a charge/discharge strategy for dynamic price contracts on top of that. (please place your votes :-)

[rrozema]

• If the amount of power being discharged is low(er) this impedes the Self Consumption mode of the battery.
  Example: solar panels generate 400 watts together. Someone starts cooking and ideally the battery should now discharge 1.5kW instead of the 400 watts.

No, by changing the target to -400 the battery will automatically keep exporting just enough to keep that 400W going into the grid. Limited by the maximum output of the battery of course.

[onlineous]

No, by changing the target to -400 the battery will automatically keep exporting just enough to keep that 400W going into the grid. Limited by the maximum output of the battery of course.

You mean setting the target grid power to the power the solar panels produce instead of having the battery discharge that precize amount?

That would fix the battery not keeping self-consumption anymore, but gives 2 new problems:

• I also have solar panels that are not connected to the batteries. those also can contribute to the grid feed-in
• The house also consumes energy, which should be subtracted from what the battery and stand alone solar panels feed into the grid.

In that case the (probably) easier method would be to set the discharge of the Venus A to the produced solar power on the Venus A OR to the produced solar power on the Venus A + the additional power being drawn from the grid, if power asked from the grid is above 0.

[sincze]

I try to understand the concept. And basically without any discharge logic the following happened today.

Omnibattery did not do anything as a result i nicely exported to the grid.
And then Omnibattery thought... maybe we now need to start charging the batteries based on (i guess solar forecast).
Few hours later battery full... and we still have excessive solar power now delivering back to the grid at a slightly higher price.

So in principle (as far as I understand it) some of our wishes are already possible ??

[ffunes]

Hi,

Thank you for the valuable discussion; it’s key to getting the feature design right. Once you have reached a final agreement, please provide a single, unified set of requirements so I can move forward with implementation.

Best regards

[onlineous]

@ffunes
There are a couple of ideas floating around in this discussion.

It's basically:

• Force battery discharge during high-price peak spikes #270 (this discussion)
  • how to sell surplus energy in the battery at the right moment, under certain conditions.
  • when to force discharge during really high prices
• [Feature] Optimize Solar Charging Based on Dynamic Feed-in Tariffs (Opportunity Cost Optimization) #237
  • when to delay charging either when there will be a solar surplus or when prices will become low enough.

These could be tackled separately, but I could also see the benefit of combining them, and rolling them into the predictive charging behavior.

Correct me if I'm wrong, but I would think the logic of predictive charging is comparable to the logic of predictive discharging and holding off charging until a later moment of the day.

In that case the logic would be:

• (Current battery SoC - Predicted consumption) + predicted solar generation =
  deficit (Predictive Charging) or
  surplus (Predictive Discharging / holding of charging).

What would be your preference, separating them, or combining them into a bigger energy management system?

[ffunes]

Hi,

I will implement this feature, but I cannot assign it to a specific release yet.

The discussion currently combines several related outcomes: covering household consumption during expensive periods, deliberately exporting stored energy, and predictive discharge based on future prices and solar availability. Before implementation, I need one unified specification.

Please confirm:

1. Does “force discharge” mean covering household consumption only, deliberate grid export, or both?
2. Should the trigger be a fixed price threshold, a threshold relative to the day’s price curve, or detection of an unusual peak?
3. What minimum SOC or energy reserve must always be protected?
4. What maximum discharge power and maximum duration should apply?
5. What stops the action: price falling below a second threshold, reaching the reserve, the end of a configured window, or the forecasted return of solar?
6. Should the strategy use the export price and stored-energy cost from [FEATURE] Support Separate Import and Export Electricity Prices #326 and [FEATURE] Stored Energy Cost Sensor (€/kWh) for Dynamic Battery Strategies #269?
7. Should this remain separate from [Feature] Optimize Solar Charging Based on Dynamic Feed-in Tariffs (Opportunity Cost Optimization) #237, or should both become part of one larger predictive energy-management strategy?
8. Please provide one concrete example with prices, SOC, household demand and the expected battery behavior.

Once these requirements are consolidated, I can implement it safely without creating an uneconomical discharge-and-recharge cycle.

[sincze]

Obviously @rrozema and @onlineous have "eaten more Dutch cheese about this topic" than me with only 2 weeks of (Omni)Battery experience.

However based on the simplified explanation of @onlineous and his additional clarification of the 85% RTE + Dutch Taxes system i must agree the buy and sell strategy (without e.g. tibber powerups discounts being currently available), narrows down the Buy & Sell strategy significantly. Except maybe for the collected tax-free solar energy that we might be able to sell. Maybe in the future if everybody starts doing this by themselves the net imbalance will only increase more...

Apart from the discussion I'm also looking at the calculation of the ROI of the investment (investment was not that much but pure for fun) adding a value label to the stored energy as @rrozema suggested seems a valuable addition for that as well..

For discharging (selling) i would limit that to the amount of surplus (Watts) so keep the house going for 'free' and dump the rest kind of approach whilst keeping in mind we would still need sufficient energy to cover for the expensive hours ahead.. (e.g. is sufficient solar available after period of discount to recharge the battery or a price dip that would be beneficial to 'buy' cheap.

[onlineous]

Obviously @rrozema and @onlineous have "eaten more Dutch cheese about this topic" than me with only 2 weeks of (Omni)Battery experience.

To be fair: my experience with Omnibattery is comparable to yours. I've quite a lot of hours invested into trying to get Home Assistant to automate everything as good as possible, through a whole lot of setups before arriving at Omnibattery (which is definitely the best solution for me thusfar).

However based on the simplified explanation of @onlineous and his additional clarification of the 85% RTE + Dutch Taxes system i must agree the buy and sell strategy (without e.g. tibber powerups discounts being currently available), narrows down the Buy & Sell strategy significantly. Except maybe for the collected tax-free solar energy that we might be able to sell. Maybe in the future if everybody starts doing this by themselves the net imbalance will only increase more...

For me, focussing on selling solar energy as profitable as possible is definitely the most important part.

I basically have surplus solar energy every (not rainy) day from april until the end of september / halve of october (give or take a couple of weeks on both ends, also depending on the weather.).

Energy having a negative value of at least 17 cents (to account for taxes and utility fees) only happened a couple of times this year. These days shutting down the solar panels to charge from the grid is beneficial, but implementing this has only low priority, because (if I remember correctly) this happened less than 5 days this year.

Energy having such a high value in the evening that dumping everything is beneficial happens more often, but still I would estimate this happened only around 10 times this year (I'm not sure how this will be in winter, but I've heard price differences between day and night tend to be lower in winter).

Surplus energy from solar happened at least a 100 times this year, so getting this right would be the priority for me.

Apart from the discussion I'm also looking at the calculation of the ROI of the investment (investment was not that much but pure for fun) adding a value label to the stored energy as @rrozema suggested seems a valuable addition for that as well..

Agree

For discharging (selling) i would limit that to the amount of surplus (Watts) so keep the house going for 'free' and dump the rest kind of approach whilst keeping in mind we would still need sufficient energy to cover for the expensive hours ahead.. (e.g. is sufficient solar available after period of discount to recharge the battery or a price dip that would be beneficial to 'buy' cheap.

There were a couple of times this year in which dumping the whole battery in the most expensive hours would have been beneficial. In that case the difference between selling early in the night, and buying back later during the night needs to be at least somewhere around 18 cents (no profit), so realistically that spread should be somewhere between 20 en 25 cents, depending on if (or how) you price in battery degradation.

[rrozema]

The thing is that we seem to have quite different strategies in mind. It seems (based on ‘2 low-price time windows’ and ‘price for the energy’) that you are mainly thinking about buying energy from the grid. For me the strategy is mainly selling unused solar energy for the best possible price.

I don’t think the buying / selling strategy will be all that profitable. I’m living in the Netherlands (you might be too if I see your name. Edit: yes you are), and our energy taxes are that high, that (from 2027) I’m very unconvinced buying and selling will still be profitable. As shown before you need at least a price difference of 15 cents for buying and selling. But it gets worse! If your RTE is only 85% the difference necessary gets even higher, and then you’re not even taking into account battery degradation.

There will definitely be days that buying and selling will be profitable, but I’m not convinced it will be more than 10 days every year in the Netherlands.

I must have been very unclear in my explanation somewhere, because I think we're in agreement on most points, including on the point that selling discharged battery energy is now already hardly profitable, but from January 1st, 2027 it will be near impossible to make any profit of trading energy on the day-ahead market (that's what I think it is called, but I could be mixing up things).

The only 2 things I think you're wrong on are:
1 - being able to manually configure some time window in which to best charge or discharge the battery. I think this should always be done automatically based on the grid prices (import and export), predicted solar production and predicted home usage.
2 - being able to use the existing Predictive Charging (PC) feature in combination with a dynamic contract charge/discharge strategy. PC is heavily based on trying to optimize the amount of energy (in kWh) taken from and send into the grid. Which fits well with the NoM (Nul Op de Meter, sorry for the Dutch) strategy, but for dynamic contracts it doesn't matter how much energy you export or import. It matters when you export or import. PC doesn't take that time factor into account. And neither does Predictive Discharging. Both features have a conceptual mismatch with dynamic tariffs.

So, I'm not against charging from the grid when predicted solar is less than predicted home usage. All I'm saying is we should prioritize the sources to collect our energy from based on their price. Solar is most of the times cheaper than grid, except when grid prices go negative. So we should decide on the price from which source we take our energy, solar, grid or part of both. Another example, on some days highest and lowest day prices may be so close that is more profitable to not charge or discharge the battery at all (due to efficiency losses). Again, prices should be used to make the decision.

I'm rewriting my prices model, because I made a crucial error in my earlier model: I determined the value of the energy put into the battery by taking the price for energy used in the home. That is wrong because the energy we put into the battery is not energy used in the home. It is energy that is left over after we've used what we needed for the home. Therfore, since there are limits on the energy each of the sources can provide, the energy we put into our batteries has a different ratio of sources than the energy used in our house. I've now got a new jinja template to calculate this new prices model. Once I'm confident the calculations are correct i will make them into sensors and share them with you all. That will hopefully lead to a proper implementation faster than me trying to create my very 1st integration with no real python experience.

[rrozema]

@sincze, apologies for completely hi-jacking your request with this discussion. But I think we better complete it here now that it got started here...
If any of you can help validate my ideas by running this script in their template editor and verify if the outcome is as they would expect, that could help me in getting the whole solution together faster and give you more insight in how I try to tackle this. The script references a price for battery out. This is my temporary implementation, working from the old situation. It doesn't really matter what the value is for this test, so if you could put some fixed value in the price_battery_out, you will be able to run the script without having such sensor available to you yet.

          {% set import_entity = 'sensor.electricity_meter_power_consumption' %}
          {% set export_entity = 'sensor.electricity_meter_power_production' %}
          {% set production_entity = 'sensor.power_produced' %}
          {% set battery_out_entity = 'sensor.omnibattery_system_discharge_power' %}
          {% set battery_in_entity = 'sensor.omnibattery_system_charge_power' %}

          {% set import_price_entity = 'sensor.electricity_meter_energy_consumption_price' %}
          {% set export_price_entity = 'sensor.electricity_meter_energy_production_compensation' %}
          {% set battery_out_price_entity = 'sensor.zendure_solarflow_charging_costs' %}
            
          {% set unit_map = {'mW': 0.001, 'W': 1.0, 'kW': 1000.0, 'MW': 1000000.0} %}
                                
          {# grid import #}
          {% set import_unit = state_attr(import_entity, 'unit_of_measurement') %}
          {% set power_import = (states(import_entity) | float(0)) * (unit_map.get(import_unit, 0)) %}
          {% set price_import = states(import_price_entity) | float %}
            
          {# grid export #}
          {% set export_unit = state_attr(export_entity, 'unit_of_measurement') %}
          {% set power_export = (states(export_entity) | float(0)) * (unit_map.get(export_unit, 0)) %}
          {% set price_export = states(export_price_entity) | float %}
            
          {# solar production #}
          {% set production_unit = state_attr(production_entity, 'unit_of_measurement') %}
          {% set power_production = (states(production_entity) | float(0)) * (unit_map.get(production_unit, 0)) %}
            
          {# battery out #}
          {% set battery_out_unit = state_attr(battery_out_entity, 'unit_of_measurement') %}
          {% set power_battery_out = (states(battery_out_entity) | float(0)) * (unit_map.get(battery_out_unit, 0)) %}
          {% set price_battery_out = states(battery_out_price_entity) | float %}
          
          {# battery in #}
          {%- set battery_in_unit = state_attr(battery_in_entity, 'unit_of_measurement') %}
          {%- set power_battery_in = (states(battery_in_entity) | float(0)) * (unit_map.get(battery_in_unit, 0)) %}

          {%- set used_total = max(0.0, (power_import + power_production + power_battery_out) - (power_export + power_battery_in)) | round(3) %}
          {%- set used_grid = min( used_total, max(0.0, (used_total + power_export + power_battery_in) - (power_production + power_battery_out))) | round(3) %}
          {%- set used_solar = min( used_total, max(0.0, (used_total + power_export + power_battery_in) - (power_import + power_battery_out))) | round(3) %}
          {%- set used_battery = min( used_total, max(0.0, (used_total + power_export + power_battery_in) - (power_import + power_production))) | round(3) %}

          {% set price_used = None if used_total == 0.0 else ((used_battery / used_total) * price_battery_out) + ((used_solar / used_total) * price_export) + ((used_grid / used_total) * price_import) %}

          {%- set used_total_left = max( 0.0, (power_import + power_production + power_battery_out) - used_total) %}
          {%- set used_grid_left = max( 0.0,(power_import - used_grid)) %}
          {%- set used_battery_left = max( 0.0, power_battery_out - used_battery) %}
          {%- set used_solar_left = max( 0.0, power_production - used_solar) %}

---- Prio 1: Home usage ----------
total:    {{ used_total }}W @ {{ price_used }} leaving {{ used_total_left }}W
battery:  {{ used_battery }}W @ {{ price_battery_out }} leaving {{ used_battery_left }}W
solar:    {{ used_solar }}W @ {{ price_export }} leaving {{ used_solar_left }}W
grid:     {{ used_grid }}W @ {{ price_import }} leaving {{ used_grid_left }}W

          {%- set charged_total = min( used_total_left, power_battery_in) %}
          {%- set charged_battery = max( 0.0, min( used_battery_left, charged_total)) %}
          {%- set charged_solar = max( 0.0, min( used_solar_left, (charged_total - charged_battery))) %}
          {%- set charged_grid = max( 0.0, min( used_solar_left, (charged_total - (charged_battery + charged_solar)))) %}

          {%- set price_charged = None if charged_total == 0.0 else ((charged_battery / charged_total) * price_battery_out) + ((charged_solar / charged_total) * price_export) + ((charged_grid / charged_total) * price_import) %}

          {%- set charged_total_left = max( 0.0, (used_total_left - charged_total)) %}
          {%- set charged_battery_left = max( 0.0, (used_battery_left - charged_battery)) %}
          {%- set charged_solar_left = max( 0.0, (used_solar_left - charged_solar)) %}
          {%- set charged_grid_left = max( 0.0, (used_grid_left - charged_grid)) %}

----- Prio 2: Battery charging ---
total:    {{ charged_total }}W @ {{ price_charged }} leaving {{ charged_total_left }}W
battery:  {{ charged_battery }}W @ {{ price_battery_out }} leaving {{ charged_battery_left}}W
solar:    {{ charged_solar }}W @ {{ price_export }} leaving {{ charged_solar_left }}W
grid:     {{ charged_grid }}W @ {{ price_import }} leaving {{ charged_grid_left }}W

          {%- set export_total = min( charged_total_left, power_export) %}
          {%- set export_battery = max( 0.0, min( charged_battery_left, export_total)) %}
          {%- set export_solar = max( 0.0, min( charged_solar_left, (export_total - export_battery))) %}
          {%- set export_grid = max( 0.0, min( charged_solar_left, (export_total - (export_battery + export_solar)))) %}

          {%- set price_export_out = None if export_total == 0.0 else ((export_battery / export_total) * price_battery_out) + ((export_solar / export_total) * price_export) + ((export_grid / export_total) * price_import) %}

----- Prio 3: Export -------------
total:    {{ export_total }}W @ {{ price_export_out }} actual selling price {{price_export }}
battery:  {{ export_battery }}W @ {{ price_battery_out }} 
solar:    {{ export_solar }}W @ {{ price_export }}
grid:     {{ export_grid }}W @ {{ price_export }} 

[onlineous]

I must have been very unclear in my explanation somewhere, because I think we're in agreement on most points, including on the point that selling discharged battery energy is now already hardly profitable, but from January 1st, 2027 it will be near impossible to make any profit of trading energy on the day-ahead market (that's what I think it is called, but I could be mixing up things).

Agree.

The only 2 things I think you're wrong on are: 1 - being able to manually configure some time window in which to best charge or discharge the battery. I think this should always be done automatically based on the grid prices (import and export), predicted solar production and predicted home usage.
I actually think we agree even more than you think: I don’t need to be able to manually configure the time slots in which to discharge. I’m currently use some manual time slots to prevent charging the battery in the morning (until 12:30 with a few other conditions), and to discharge in the evening (20:00 – 21:30, with selling of energy stopping when a certain battery threshold is reached). I’m well aware that dynamically finding the best moments to charge and discharge is more profitable (and better, because my summer schedule probably won’t align in winter), but it’s harder to program in Home Assistant, without the automations getting quite involved.
2 - being able to use the existing Predictive Charging (PC) feature in combination with a dynamic contract charge/discharge strategy. PC is heavily based on trying to optimize the amount of energy (in kWh) taken from and send into the grid. Which fits well with the NoM (Nul Op de Meter, sorry for the Dutch) strategy, but for dynamic contracts it doesn't matter how much energy you export or import. It matters when you export or import. PC doesn't take that time factor into account. And neither does Predictive Discharging. Both features have a conceptual mismatch with dynamic tariffs.

I might have not been clear on this point. I DON’T want to charge predictive, and sell energy later during the day with predictive discharge. As we agreed on above, the days this strategy will work, are probably fairly limited (unless winter prices are different than assumed, I’m only on a dynamic contract since April).
When I say integrating predictive charging and discharging together I mainly say this because the programming behind that is probably fairly similar.
Omnibattery already predicts when there is a deficit of energy, based on house consumption, current SoC and predicted solar generation. Calculating the surplus is a logical next step, and if you have that surplus calculated, just like with predictive charging you could calculate the optimal slots to sell this surplus.

Of course you need to make sure predictive charging doesn’t charge up the battery, and sell the energy later for a price that is too cheap. This could be done with a sensor indicating the price of the energy in the battery. I see two other possible options to reach this goal:

• If predictive charging happened, only sell energy during the most expensive time slots if the price during these time slots is at least X more expensive than during the most expensive hours later in the night. For me, that price should at least be 22 cents more expensive than the other parts of the night, to make up for taxes, utility fees, and a small fee for battery degradation.
  The upside of going this route is that this also works for dumping the whole battery if that is monetary beneficial.
• Prediction of how much the home uses should already make sure there is no buying and selling of energy in one day (there might be an exception for above painted scenario): if winter comes the nights become longer, and (my) consumption gets higher because of my heat pump. Omnibattery uses the predicted consumption, so during normal operation there won’t be a surplus during the more expensive hours (unless prices getting highly negative during the day, and you can charge for free), just enough energy (or not enough, if the battery is not big enough to get through the whole night) to last through the night.

So, I'm not against charging from the grid when predicted solar is less than predicted home usage. All I'm saying is we should prioritize the sources to collect our energy from based on their price. Solar is most of the times cheaper than grid, except when grid prices go negative.
And even highly negative because taxes and utility fees should be taken into account as well. So prices should be around 17 cents negative for the grid energy to be free.
So we should decide on the price from which source we take our energy, solar, grid or part of both. Another example, on some days highest and lowest day prices may be so close that is more profitable to not charge or discharge the battery at all (due to efficiency losses). Again, prices should be used to make the decision.

Agree. If the battery RTE is around 80% charging and discharging doesn’t make sense if the prices during day and night vary less than 30% (give or take) after taxes and fees.

I'm rewriting my prices model, because I made a crucial error in my earlier model: I determined the value of the energy put into the battery by taking the price for energy used in the home. That is wrong because the energy we put into the battery is not energy used in the home. It is energy that is left over after we've used what we needed for the home. Therefore, since there are limits on the energy each of the sources can provide, the energy we put into our batteries has a different ratio of sources than the energy used in our house. I've now got a new jinja template to calculate this new prices model. Once I'm confident the calculations are correct i will make them into sensors and share them with you all. That will hopefully lead to a proper implementation faster than me trying to create my very 1st integration with no real python experience.
Very welcome!

I think we’re totally in agreement in what this Omnibattery feature should do, and what it shouldn’t.

[onlineous]

I fed everything into gemini, to get a unified list of requirements:

I pasted the outcome below. Can you agree @rrozema and @sincze, that this is the way @ffunes could move forward, or didn't Gemini and I interpret your feedback / comments / requirements correctly?

Core Objective

Provide an automated, economic strategy for dynamic electricity contracts that optimizes battery charging and discharging. The system prioritizes covering household consumption, then intelligently exports calculated solar surplus during the highest-value dynamic price slots while protecting nighttime home energy needs and accounting for net taxes, fees, and round-trip efficiency (RTE).

Key Requirements & Definitions

1. "Force Discharge" Operational Scope

• Primary Function: Deliberate grid export of calculated solar surplus energy (or extreme price-spike energy) at maximum configured battery discharge power (wattage).

• Secondary Function: Automatic grid feed-in suppression during negative/low price export periods, prioritizing direct solar export to grid early in the day while prices are favorable before switching to battery solar-charging.

2. Discharge Triggers & Operational Modes

The feature should support two main discharge triggers:

• Trigger 1: Solar Surplus Export (Primary Daily Strategy)

  • Logic: Calculates predicted daily solar generation vs. predicted household load. If available battery energy exceeds what is needed to cover the home until the next low-price/solar cycle (plus a configurable safety reserve/margin in kWh), the remaining energy is flagged as Surplus.

  • Timing Selection: Automatically ranks the day's export price slots and selects the $N$ highest-priced time slots required to discharge the total surplus volume at max output power.

• Trigger 2: Extreme Price Spike Dump (Opportunistic Strategy)

  • Logic: Triggered regardless of normal night-coverage calculations when the dynamic export price exceeds a strict spread threshold.

  • Threshold Formula: Triggers when (Export Price + Configured Margin) $\ge$ Highest Night Import Price.

  • Note: The configurable margin accounts for energy taxes, fixed utility per-kWh fees, round-trip efficiency losses (~80–85%), and optional battery degradation costs. (In the Dutch market context, this spread typically requires a $\sim 0.18–0.22\text{ \euro}/kWh$ differential to break even).

3. Constraints, Limits & Stopping Criteria

• Battery Discharge Power: Maximum normal battery output power by default, configurable by the user (e.g., 1500 W limit).

• Reserve Energy Protection:

  • For Trigger 1 (Surplus): Must preserve predicted home consumption for the night/overnight window + user-defined emergency backup SoC.

  • For Trigger 2 (Spike): Must respect at least the hard minimum emergency backup SoC/kWh reserve setting.

• Stop Conditions: Discharging stops immediately when:

  1. Calculated surplus kWh for the window has been fully exported.

  2. The dynamic export price drops below the cost-effectiveness threshold.

  3. Battery SoC reaches the protected reserve threshold.

4. Cost Model & Price Sensitivity Integration

• Net-Price Basis: All price comparisons (import and export) must factor in full net costs: base spot price + energy taxes + utility markup fees + round-trip efficiency (RTE) losses.

• Stored Energy Cost Tracking: A stored energy cost sensor (from [FEATURE] Stored Energy Cost Sensor (€/kWh) for Dynamic Battery Strategies #269 / [FEATURE] Support Separate Import and Export Electricity Prices #326) should be integrated to ensure energy bought from the grid is never sold at a loss.

• Off-Grid / Direct-Grid Charging Priority: Due to tax structures (e.g., post-2026 tax rule changes), charging from solar is significantly cheaper than charging from grid. Charging algorithms must evaluate solar first before grid import.

5. Relationship with Predictive Energy Management

• The feature should be integrated under a unified Dynamic Predictive Energy Strategy framework alongside Predictive Charging.

• Shared Math: Both rely on the same underlying predictive engine (Forecasted Solar - Forecasted Home Load = Deficit or Surplus).

  • If Deficit $\rightarrow$ Triggers Predictive Charging logic (select cheapest slots to import).

  • If Surplus $\rightarrow$ Triggers Predictive Discharging logic (select highest slots to export).

• User Toggles: Provide independent enable/disable toggles for Predictive Charging and Predictive Discharging so users with small capacities or high night loads can disable surplus exporting if desired.

Concrete Example Scenario

Hardware & Settings Setup

• Battery: 6 kWh capacity, 1500 W max discharge rate, 85% Round-Trip Efficiency (RTE).

• Emergency Reserve: 1.0 kWh (Hard SoC minimum).

• Predicted Night Load (20:00 - 07:00): 2.0 kWh.

• Total Protected Reserve Needed: $1.0\text{ kWh} + 2.0\text{ kWh} = 3.0\text{ kWh}$.

• Fixed Tax & Utility Delta Threshold: $0.20\text{ \euro}/kWh$ spread required for arbitrage.

Day Profile & System Behavior (an example, times and behavior isn't hard coded, but dynamically calculated and executed.

[rrozema]

I must have missed the essence of this message before because I really think that primary objective plus everything derived from it is incorrect.

In my opinion exporting from the battery into the grid -especially given the upcoming export tariff changes per January 1st, 2027- only makes sense to "make room in the battery" for some large upcoming charging action, for example before a "very low negative price window" is coming up. That discharge will then probably bring us a small financial loss, but it lets us charge more later, when there's money to be made when the prices are negative. In other situations there is financially almost nothing to be gained by exporting energy already charged into the battery due to a combination of export prices being very much lower than import prices plus battery conversion losses. I think that when the logic is properly based on actual prices, this feature will post-2026 pretty much never be triggered in the Dutch market. And if it does get activated because of manually poorly chosen limits that will most likely bring financial loss instead of gains.

Then again, it may work well for other markets.

[onlineous]

Didn't we have this discussion already before?

The example isn't about buying energy to charge the battery to sell later: it's to sell surplus solar power exactly at the right time.

Let's take friday as an example (as indicated by Frank Energie, if you want to make your own calculations)

Market price of around 0.13 from 00:00 to 06:00, rising to 0.22 at 08:00, then going down to 0.00 between 12:00 and 16:00, going up again to 0.20 around 21:00.

Let's say you have a battery of 6 kWh which only has the reserve power you set when the solar generation of the new day starts.
You start selling surplus energy in the morning, without charging the batteries:

Until 07:00 self consumption
07:00 - 08:00 +0.5 kWh for 0.222
08:00 - 09:00 +0.5 kWh for 0.211
09:00 - 10:00 +0.5 kWh for 0.165
10:00 - 11:00 +1 kWh for 0.094
11:00 - 12:00 +1 kWh for 0.094
12:00 - 16:00 price of 0. Charge battery until full, let's say 5 kWh. 1.5 kWh surplus per hour - 5 = 1 kWh 'lost' for free.
16:00 - 17:00 +1.5 kWh for 0.031
17:00 - 18:00 +1 kWh for 0.094
18:00 - 19:00 +0.5 kWh for 0.183
Calculation for the night: 4 kWh necessary including reserves, 2 kWh available to sell.
1.6 kWh sold (80% conversion efficiency) between 20:00 and 21:00 for a price of 0.201

Total profit: 1.04 Euro.

I don't see how this could be optimized any further, given the restraints of solar generation, house consumption, etc. If you don't sell the 2 kWh / 1.6 kWh surplus you lose 0.32 cents of profit (not taking into account extra battery degradation).

[sincze]

@rrozema no hard feelings. I believe we are making progress ;-) to that is good for Omnibattery as a product. Hopefully @ffunes agrees ;-0

At the moment te template provides me.

----- Prio 1: Home usage ----------
total:    615.0W @ €0.133/kWh leaving 4154.000017404558W
battery:  0.0W leaving 0.0W
solar:    615.0W leaving 2491.0W
grid:     615.0W leaving 1048.0000174045579W

----- Prio 2: Battery charging ---
total:    2490.0W @ €0.133/kWh leaving 1664.000017404558W
battery:  0.0W leaving 0.0W
solar:    2490.0W leaving 1.0W
grid:     0.0W leaving 1048.0000174045579W

----- Prio 3: Export -------------
total:    1664.000017404558W @ €0.133/kWh
battery:  0.0W
solar:    1.0W
grid:     1048.0000174045579W

[rrozema]

Thank you, both for your understanding and the output of the template for your setup. The previous template had a regression in how it calculates the prio 1 (home usage) power source: battery, solar and grid should always add up to total and your output shows clearly that this was not the case.
I fixed that, plus some other smaller problems. I also renamed the variables to make the way the formulas work more clear. If you could try one more time?

          {% set import_entity = 'sensor.electricity_meter_power_consumption' %}
          {% set export_entity = 'sensor.electricity_meter_power_production' %}
          {% set production_entity = 'sensor.power_produced' %}
          {% set battery_out_entity = 'sensor.omnibattery_system_discharge_power' %}
          {% set battery_in_entity = 'sensor.omnibattery_system_charge_power' %}

          {% set import_price_entity = 'sensor.electricity_meter_energy_consumption_price' %}
          {% set export_price_entity = 'sensor.electricity_meter_energy_production_compensation' %}
          {% set battery_out_price_entity = 'sensor.zendure_solarflow_charging_costs' %}
            
          {% set unit_map = {'mW': 0.001, 'W': 1.0, 'kW': 1000.0, 'MW': 1000000.0} %}
                                
          {# grid import #}
          {% set import_unit = state_attr(import_entity, 'unit_of_measurement') %}
          {% set power_import = (states(import_entity) | float(0)) * (unit_map.get(import_unit, 0)) %}
          {% set price_import = states(import_price_entity) | float %}
            
          {# grid export #}
          {% set export_unit = state_attr(export_entity, 'unit_of_measurement') %}
          {% set power_export = (states(export_entity) | float(0)) * (unit_map.get(export_unit, 0)) %}
          {% set price_export = states(export_price_entity) | float %}
            
          {# solar production #}
          {% set production_unit = state_attr(production_entity, 'unit_of_measurement') %}
          {% set power_production = (states(production_entity) | float(0)) * (unit_map.get(production_unit, 0)) %}
            
          {# battery out #}
          {% set battery_out_unit = state_attr(battery_out_entity, 'unit_of_measurement') %}
          {% set power_battery_out = (states(battery_out_entity) | float(0)) * (unit_map.get(battery_out_unit, 0)) %}
          {% set price_battery_out = states(battery_out_price_entity) | float %}
          
          {# battery in #}
          {%- set battery_in_unit = state_attr(battery_in_entity, 'unit_of_measurement') %}
          {%- set power_battery_in = (states(battery_in_entity) | float(0)) * (unit_map.get(battery_in_unit, 0)) %}

          {%- set prio_1_total = max(0.0, (power_battery_out + power_production + power_import) - (power_battery_in + power_export)) | round(3) %}
          {%- set prio_1_battery = max(0.0, min( power_battery_out, prio_1_total)) | round(3) %}
          {%- set prio_1_solar = max(0.0, min( power_production, (prio_1_total - prio_1_battery))) | round(3) %}
          {%- set prio_1_grid = max(0.0, min( power_import, (prio_1_total - (prio_1_battery + prio_1_solar)))) | round(3) %}

          {%- set price_prio_1 = None if prio_1_total == 0.0 else ((prio_1_battery / prio_1_total) * price_battery_out) + ((prio_1_solar / prio_1_total) * price_export) + ((prio_1_grid / prio_1_total) * price_import) %}
            
          {%- set prio_1_total_left = max( 0.0, (power_import + power_production + power_battery_out) - prio_1_total) %}
          {%- set prio_1_battery_left = max( 0.0, power_battery_out - prio_1_battery) %}
          {%- set prio_1_solar_left = max( 0.0, power_production - prio_1_solar) %}
          {%- set prio_1_grid_left = max( 0.0,(power_import - prio_1_grid)) %}

---- Prio 1: Home usage ----------
total:    {{ prio_1_total }}W @ {{ price_prio_1 | round(4) if price_prio_1 | is_number else 'unavailable' }} leaving {{ prio_1_total_left }}W
battery:  {{ prio_1_battery }}W @ {{ price_battery_out | round(4) }} leaving {{ prio_1_battery_left }}W
solar:    {{ prio_1_solar }}W @ {{ price_export | round(4) }} leaving {{ prio_1_solar_left }}W
grid:     {{ prio_1_grid }}W @ {{ price_import | round(4) }} leaving {{ prio_1_grid_left }}W

          {%- set prio_2_total = min( prio_1_total_left, power_battery_in) | round(3) %}
          {%- set prio_2_battery = max( 0.0, min( prio_1_battery_left, prio_2_total)) | round(3) %}
          {%- set prio_2_solar = max( 0.0, min( prio_1_solar_left, (prio_2_total - prio_2_battery))) | round(3) %}
          {%- set prio_2_grid = max( 0.0, min( prio_1_grid_left, (prio_2_total - (prio_2_battery + prio_2_solar)))) | round(3) %}

          {%- set price_prio_2 = None if prio_2_total == 0.0 else ((prio_2_battery / prio_2_total) * price_battery_out) + ((prio_2_solar / prio_2_total) * price_export) + ((prio_2_grid / prio_2_total) * price_import) %}

          {%- set prio_2_total_left = max( 0.0, (prio_1_total_left - prio_2_total)) %}
          {%- set prio_2_battery_left = max( 0.0, (prio_1_battery_left - prio_2_battery)) %}
          {%- set prio_2_solar_left = max( 0.0, (prio_1_solar_left - prio_2_solar)) %}
          {%- set prio_2_grid_left = max( 0.0, (prio_1_grid_left - prio_2_grid)) %}

----- Prio 2: Battery charging ---
total:    {{ prio_2_total }}W @ {{ price_prio_2 | round(4) if price_prio_2 | is_number else 'unavailable' }} leaving {{ prio_2_total_left }}W
battery:  {{ prio_2_battery }}W @ {{ price_battery_out | round(4) }} leaving {{ prio_2_battery_left}}W
solar:    {{ prio_2_solar }}W @ {{ price_export | round(4) }} leaving {{ prio_2_solar_left }}W
grid:     {{ prio_2_grid }}W @ {{ price_import | round(4) }} leaving {{ prio_2_grid_left }}W

          {%- set prio_3_total = min( prio_2_total_left, power_export) %}
          {%- set prio_3_battery = max( 0.0, min( prio_2_battery_left, prio_3_total)) %}
          {%- set prio_3_solar = max( 0.0, min( prio_2_solar_left, (prio_3_total - prio_3_battery))) %}
          {%- set prio_3_grid = max( 0.0, min( prio_2_grid_left, (prio_3_total - (prio_3_battery + prio_3_solar)))) %}

          {%- set price_prio_3 = None if prio_3_total == 0.0 else ((prio_3_battery / prio_3_total) * price_battery_out) + ((prio_3_solar / prio_3_total) * price_export) + ((prio_3_grid / prio_3_total) * price_import) %}

----- Prio 3: Export -------------
total:    {{ prio_3_total }}W @ {{ price_prio_3 | round(4) if price_prio_3 | is_number else 'unavailable' }} actual selling price {{price_export }}
battery:  {{ prio_3_battery }}W @ {{ price_battery_out | round(4) }} 
solar:    {{ prio_3_solar }}W @ {{ price_export | round(4) }}
grid:     {{ prio_3_grid }}W @ {{ price_export | round(4) }}

[onlineous]

When I pasted your code I got the following error:

ValueError: Template error: float got invalid input 'unknown' when rendering template '{% set import_entity = 'sensor.electricity_meter_power_consumption' %} {% set export_entity = 'sensor.electricity_meter_power_production' %} {% set production_entity = 'sensor.power_produced' %} {% set battery_out_entity = 'sensor.omnibattery_system_discharge_power' %} {% set battery_in_entity = 'sensor.omnibattery_system_charge_power' %} {% set import_price_entity = 'sensor.electricity_meter_energy_consumption_price' %} {% set export_price_entity = 'sensor.electricity_meter_energy_production_compensation' %} {% set battery_out_price_entity = 'sensor.zendure_solarflow_charging_costs' %} {% set unit_map = {'mW': 0.001, 'W': 1.0, 'kW': 1000.0, 'MW': 1000000.0} %} {# grid import #} {% set import_unit = state_attr(import_entity, 'unit_of_measurement') %} {% set power_import = (states(import_entity) | float(0)) * (unit_map.get(import_unit, 0)) %} {% set price_import = states(import_price_entity) | float %} {# grid export #} {% set export_unit = state_attr(export_entity, 'unit_of_measurement') %} {% set power_export = (states(export_entity) | float(0)) * (unit_map.get(export_unit, 0)) %} {% set price_export = states(export_price_entity) | float %} {# solar production #} {% set production_unit = state_attr(production_entity, 'unit_of_measurement') %} {% set power_production = (states(production_entity) | float(0)) * (unit_map.get(production_unit, 0)) %} {# battery out #} {% set battery_out_unit = state_attr(battery_out_entity, 'unit_of_measurement') %} {% set power_battery_out = (states(battery_out_entity) | float(0)) * (unit_map.get(battery_out_unit, 0)) %} {% set price_battery_out = states(battery_out_price_entity) | float %} {# battery in #} {%- set battery_in_unit = state_attr(battery_in_entity, 'unit_of_measurement') %} {%- set power_battery_in = (states(battery_in_entity) | float(0)) * (unit_map.get(battery_in_unit, 0)) %} {%- set prio_1_total = max(0.0, (power_battery_out + power_production + power_import) - (power_battery_in + power_export)) | round(3) %} {%- set prio_1_battery = max(0.0, min( power_battery_out, prio_1_total)) | round(3) %} {%- set prio_1_solar = max(0.0, min( power_production, (prio_1_total - prio_1_battery))) | round(3) %} {%- set prio_1_grid = max(0.0, min( power_import, (prio_1_total - (prio_1_battery + prio_1_solar)))) | round(3) %} {%- set price_prio_1 = None if prio_1_total == 0.0 else ((prio_1_battery / prio_1_total) * price_battery_out) + ((prio_1_solar / prio_1_total) * price_export) + ((prio_1_grid / prio_1_total) * price_import) %} {%- set prio_1_total_left = max( 0.0, (power_import + power_production + power_battery_out) - prio_1_total) %} {%- set prio_1_battery_left = max( 0.0, power_battery_out - prio_1_battery) %} {%- set prio_1_solar_left = max( 0.0, power_production - prio_1_solar) %} {%- set prio_1_grid_left = max( 0.0,(power_import - prio_1_grid)) %} ---- Prio 1: Home usage ---------- total: {{ prio_1_total }}W @ {{ price_prio_1 | round(4) if price_prio_1 | is_number else 'unavailable' }} leaving {{ prio_1_total_left }}W battery: {{ prio_1_battery }}W @ {{ price_battery_out | round(4) }} leaving {{ prio_1_battery_left }}W solar: {{ prio_1_solar }}W @ {{ price_export | round(4) }} leaving {{ prio_1_solar_left }}W grid: {{ prio_1_grid }}W @ {{ price_import | round(4) }} leaving {{ prio_1_grid_left }}W {%- set prio_2_total = min( prio_1_total_left, power_battery_in) | round(3) %} {%- set prio_2_battery = max( 0.0, min( prio_1_battery_left, prio_2_total)) | round(3) %} {%- set prio_2_solar = max( 0.0, min( prio_1_solar_left, (prio_2_total - prio_2_battery))) | round(3) %} {%- set prio_2_grid = max( 0.0, min( prio_1_grid_left, (prio_2_total - (prio_2_battery + prio_2_solar)))) | round(3) %} {%- set price_prio_2 = None if prio_2_total == 0.0 else ((prio_2_battery / prio_2_total) * price_battery_out) + ((prio_2_solar / prio_2_total) * price_export) + ((prio_2_grid / prio_2_total) * price_import) %} {%- set prio_2_total_left = max( 0.0, (prio_1_total_left - prio_2_total)) %} {%- set prio_2_battery_left = max( 0.0, (prio_1_battery_left - prio_2_battery)) %} {%- set prio_2_solar_left = max( 0.0, (prio_1_solar_left - prio_2_solar)) %} {%- set prio_2_grid_left = max( 0.0, (prio_1_grid_left - prio_2_grid)) %} ----- Prio 2: Battery charging --- total: {{ prio_2_total }}W @ {{ price_prio_2 | round(4) if price_prio_2 | is_number else 'unavailable' }} leaving {{ prio_2_total_left }}W battery: {{ prio_2_battery }}W @ {{ price_battery_out | round(4) }} leaving {{ prio_2_battery_left}}W solar: {{ prio_2_solar }}W @ {{ price_export | round(4) }} leaving {{ prio_2_solar_left }}W grid: {{ prio_2_grid }}W @ {{ price_import | round(4) }} leaving {{ prio_2_grid_left }}W {%- set prio_3_total = min( prio_2_total_left, power_export) %} {%- set prio_3_battery = max( 0.0, min( prio_2_battery_left, prio_3_total)) %} {%- set prio_3_solar = max( 0.0, min( prio_2_solar_left, (prio_3_total - prio_3_battery))) %} {%- set prio_3_grid = max( 0.0, min( prio_2_grid_left, (prio_3_total - (prio_3_battery + prio_3_solar)))) %} {%- set price_prio_3 = None if prio_3_total == 0.0 else ((prio_3_battery / prio_3_total) * price_battery_out) + ((prio_3_solar / prio_3_total) * price_export) + ((prio_3_grid / prio_3_total) * price_import) %} ----- Prio 3: Export ------------- total: {{ prio_3_total }}W @ {{ price_prio_3 | round(4) if price_prio_3 | is_number else 'unavailable' }} actual selling price {{price_export }} battery: {{ prio_3_battery }}W @ {{ price_battery_out | round(4) }} solar: {{ prio_3_solar }}W @ {{ price_export | round(4) }} grid: {{ prio_3_grid }}W @ {{ price_export | round(4) }}' but no default was specified

I asked Gemini for help, and got:

The error ValueError: Template error: float got invalid input 'unknown' when rendering template happens because Home Assistant strict-type checking throws an exception when passing 'unknown' or 'unavailable' to | float without supplying a default fallback value (| float(0)).

In your template, the three price variables lack default values:

Code snippet
{% set price_import = states(import_price_entity) | float %}
{% set price_export = states(export_price_entity) | float %}
{% set price_battery_out = states(battery_out_price_entity) | float %}
The Fix
Supply a default value (0) to each price filter, just like you did for power values:

Result after doing this:

---- Prio 1: Home usage ----------
total: 371.0W @ 0.0 leaving 0.0W
battery: 371.0W @ 0.0 leaving 0.0W
solar: 0.0W @ 0.0 leaving 0.0W
grid: 0.0W @ 0.0 leaving 0.0W

----- Prio 2: Battery charging ---
total: 0.0W @ unavailable leaving 0.0W
battery: 0.0W @ 0.0 leaving 0.0W
solar: 0.0W @ 0.0 leaving 0.0W
grid: 0.0W @ 0.0 leaving 0.0W

----- Prio 3: Export -------------
total: 0.0W @ unavailable actual selling price 0
battery: 0.0W @ 0.0
solar: 0.0W @ 0.0
grid: 0.0W @ 0.0

[rrozema]

The top-most 8 lines define the names for the sensors to read in your Home Assistant. The names that are in there currently are the names in my setup. If you replace those names by the names for your power and price sensors you'll see the template calculate from your data the price for energy used in your home (= prio 1), another price for energy charged into the battery (prio 2), and finally a price for the energy you're exporting (prio 3).

I'm pretty sure already the calculations are correct now. This was for verifying mostly. You're still welcome to try it, but I think i can start turning the formulas into template sensors now. When done I will upload those into my feature request #269, hoping ffunes can turn them into something more generically usable.

I will also try myself to build a prices integration, but I've never built an integration before and have no experience writing python, so I have no idea how long that is going to take or if I can do it at all...

[rrozema]

One remark, maybe not entirely related to forced discharging but more to the "idle" periods in between charging and discharging. I see in Gemini's summary that the battery is said to sit idle in some situations. I don't think that is correct in many of those situations: if the battery sits idle, that means we're using part of the energy produced by the solar (provided there is solar production of course). If the battery price is below the export price (which happens a lot every day if we charge at the right time), we will want to run our home of the battery and export **all** of the solar energy pretty much all of the time when we're not charging the battery: to achieve this the battery will have to discharge just enough to cover our home use: no more no less. This can easily be done by manipulating omnibattery's PD target. If we set it equal to the negative solar output the battery will discharge exactly our home usage, "pushing out" all solar production at the higher export price. The battery should therefore only be fully idle when it is at minimum SOC and it's not time to charge yet, or when it is at max SOC and the battery price is still higher than the export price. Op ma 31 aug 2026, 10:54 schreef onlineous ***@***.***>:

…

I fed everything into gemini, to get a unified list of requirements: I pasted the outcome below. Can you agree @rrozema <https://github.com/rrozema> and @sincze <https://github.com/sincze>, that this is the way @ffunes <https://github.com/ffunes> could move forward, or didn't Gemini and I interpret your feedback / comments / requirements correctly? Core Objective Provide an automated, economic strategy for dynamic electricity contracts that optimizes battery charging and discharging. The system prioritizes covering household consumption, then intelligently exports calculated *solar surplus* during the highest-value dynamic price slots while protecting nighttime home energy needs and accounting for net taxes, fees, and round-trip efficiency (RTE). Key Requirements & Definitions1. "Force Discharge" Operational Scope - *Primary Function:* Deliberate grid export of *calculated solar surplus energy* (or extreme price-spike energy) at maximum configured battery discharge power (wattage). - *Secondary Function:* Automatic grid feed-in suppression during negative/low price export periods, prioritizing direct solar export to grid early in the day while prices are favorable before switching to battery solar-charging. 2. Discharge Triggers & Operational Modes The feature should support two main discharge triggers: - *Trigger 1: Solar Surplus Export (Primary Daily Strategy)* - *Logic:* Calculates predicted daily solar generation vs. predicted household load. If available battery energy exceeds what is needed to cover the home until the next low-price/solar cycle (plus a configurable safety reserve/margin in kWh), the remaining energy is flagged as *Surplus* . - *Timing Selection:* Automatically ranks the day's export price slots and selects the $N$ highest-priced time slots required to discharge the total surplus volume at max output power. - *Trigger 2: Extreme Price Spike Dump (Opportunistic Strategy)* - *Logic:* Triggered regardless of normal night-coverage calculations when the dynamic export price exceeds a strict spread threshold. - *Threshold Formula:* Triggers when (Export Price + Configured Margin) $\ge$ Highest Night Import Price. - *Note:* The configurable margin accounts for energy taxes, fixed utility per-kWh fees, round-trip efficiency losses (~80–85%), and optional battery degradation costs. (In the Dutch market context, this spread typically requires a $\sim 0.18–0.22\text{ \euro}/kWh$ differential to break even). 3. Constraints, Limits & Stopping Criteria - *Battery Discharge Power:* Maximum normal battery output power by default, configurable by the user (e.g., 1500 W limit). - *Reserve Energy Protection:* - For *Trigger 1 (Surplus):* Must preserve predicted home consumption for the night/overnight window + user-defined emergency backup SoC. - For *Trigger 2 (Spike):* Must respect at least the hard minimum emergency backup SoC/kWh reserve setting. - *Stop Conditions:* Discharging stops immediately when: 1. Calculated surplus kWh for the window has been fully exported. 2. The dynamic export price drops below the cost-effectiveness threshold. 3. Battery SoC reaches the protected reserve threshold. 4. Cost Model & Price Sensitivity Integration - *Net-Price Basis:* All price comparisons (import and export) must factor in full net costs: base spot price + energy taxes + utility markup fees + round-trip efficiency (RTE) losses. - *Stored Energy Cost Tracking:* A stored energy cost sensor (from #269 <#269> / #326 <#326>) should be integrated to ensure energy bought from the grid is *never sold at a loss*. - *Off-Grid / Direct-Grid Charging Priority:* Due to tax structures (e.g., post-2026 tax rule changes), charging from solar is significantly cheaper than charging from grid. Charging algorithms must evaluate solar first before grid import. 5. Relationship with Predictive Energy Management - The feature should be integrated under a unified *Dynamic Predictive Energy Strategy* framework alongside Predictive Charging. - *Shared Math:* Both rely on the same underlying predictive engine (Forecasted Solar - Forecasted Home Load = Deficit or Surplus). - If *Deficit* $\rightarrow$ Triggers Predictive Charging logic (select cheapest slots to import). - If *Surplus* $\rightarrow$ Triggers Predictive Discharging logic (select highest slots to export). - *User Toggles:* Provide independent enable/disable toggles for *Predictive Charging* and *Predictive Discharging* so users with small capacities or high night loads can disable surplus exporting if desired. Concrete Example ScenarioHardware & Settings Setup - *Battery:* 6 kWh capacity, 1500 W max discharge rate, 85% Round-Trip Efficiency (RTE). - *Emergency Reserve:* 1.0 kWh (Hard SoC minimum). - *Predicted Night Load (20:00 - 07:00):* 2.0 kWh. - *Total Protected Reserve Needed:* $1.0\text{ kWh} + 2.0\text{ kWh} = 3.0\text{ kWh}$. - *Fixed Tax & Utility Delta Threshold:* $0.20\text{ \euro}/kWh$ spread required for arbitrage. Day Profile & System Behavior (an example, times and behavior isn't hard coded, but dynamically calculated and executed. Image: Example behavior (view on web) <https://github.com/user-attachments/assets/6eae9854-8a19-418d-ba76-34edf25a2e85> — Reply to this email directly, view it on GitHub <#270?email_source=notifications&email_token=AANKYDWIPLWHF5I3NLAQUFT5MU4JVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGE2TONBQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18215740>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANKYDUDMXY53YGDZ257FOT5MU4JVAVCNFSNUABJKJSXA33TNF2G64TZHMYTEOBTGEYDQNBXGU5UI2LTMN2XG43JN5XDWMJQGYYDINBYGGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AANKYDQXFOZ2BPGQHJDYWFL5MU4JVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGE2TONBQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AANKYDXNZ5E6OUKQTQ5ER735MU4JVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGE2TONBQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[onlineous]

Agree. I noticed the 'Idle' as well. I chose to let it slide, because self-consumption mode is indicated as well, which I think would be more appropriate.

[onlineous]

I updated the picture with the example of day behavior, to clarify the 06:00 to 12:00 slot.

[sincze]

I now have:

---- Prio 1: Home usage ----------
total:    513.0W @ 0.363 leaving 178.00000560283627W
battery:  134.0W @ 0.363 leaving 0.0W
solar:    341.0W @ 0.363 leaving 0.0W
grid:     38.0W @ 0.363 leaving 178.00000560283627W

----- Prio 2: Battery charging ---
total:    0.0W @ unavailable leaving 178.00000560283627W
battery:  0.0W @ 0.363 leaving 0.0W
solar:    0.0W @ 0.363 leaving 0.0W
grid:     0.0W @ 0.363 leaving 178.00000560283627W

----- Prio 3: Export -------------
total:    178.000003099442W @ 0.363 actual selling price 0.363
battery:  0.0W @ 0.363
solar:    0.0W @ 0.363
grid:     178.000003099442W @ 0.363
This template listens for the following state changed events:

Entity: sensor.omnibattery_system_charge_power
Entity: sensor.omnibattery_system_discharge_power
Entity: sensor.p1_en_watermeter_power_consumed_l1_2
Entity: sensor.p1_en_watermeter_power_consumed_l2_2
Entity: sensor.p1_en_watermeter_power_consumed_l3_2
Entity: sensor.p1_en_watermeter_power_produced_l1_2
Entity: sensor.p1_en_watermeter_power_produced_l2_2
Entity: sensor.p1_en_watermeter_power_produced_l3_2
Entity: sensor.sincze_electricity_price
Entity: sensor.solar_production_power

[rrozema]

Thank you. That output seems correct. The "demo-effect" is a bit low though in this case, as you seem to have entered the exact same price sensor for all 3 three prices: import, export and battery. I suggest you already create a separate (template) sensor that gives the price for energy exported (= returned into the grid) and use that everywhere in your (energy)dashboards and calculations where you need a price for exported energy. That way on January 1st you can simply change that sensor and you'll have all dashboards and calculations use the correct pricing.
An example of a template for such a sensor could be to take the import price and subtract a fee that your energy provider takes for exported energy. Something like {{ states('sensor.sincze_electricity_price') | float - 0.025 }}.
If you then include that sensor in the above script for the export price, you'll better see what the effect of the formulas will be for your setup.

[sincze]

Hoe gaat Tibber om met teruglevering na 2027?
Voor de stroom die je teruglevert krijg je bij Tibber de actuele beursprijs op het moment van teruglevering – het kale stroomtarief, zonder belastingen of inkoopvergoeding. Aparte terugleverkosten rekenen we niet, en de huidige verkoopvergoeding vervalt. Bekijk een voorbeeldfactuur om precies het effect van de wijzigingen te zien vanaf 2027.

[onlineous]

Hoe gaat Tibber om met teruglevering na 2027? Voor de stroom die je teruglevert krijg je bij Tibber de actuele beursprijs op het moment van teruglevering – het kale stroomtarief, zonder belastingen of inkoopvergoeding. Aparte terugleverkosten rekenen we niet, en de huidige verkoopvergoeding vervalt. Bekijk een voorbeeldfactuur om precies het effect van de wijzigingen te zien vanaf 2027.

As far as I understand FrankEnergie will take the same approach in 2027. Makes programming in HA a bit easier, because I don't have to take the 1.2 cents utility fee for feed-in into account anymore.

[iceicerickert]

First of all, I agree that it's way better to combine all this in omnibattery than building everything yourself. Very interested in this as well, since its actually what I find one of the biggest advantages of a home battery.
Let me know where I can be of help.

[iceicerickert]

after installing omnibattery and playing with it im very happy except im missing 2 features. This one, #410 and #237.
They all are very popular and I understand why. With those 3 you have a very complete package and I think nothing else for home-assistant comes close to that feature set.
Maybe we can sign off on those 3 so we can start implementing the changes?

[onlineous]

I totally agree these 3 are the way to go. It's definitely not a quick, 10 minute fix, but these 3 features will make Omnibattery a complete EMS solution (possibly even the most complete EMS solution available). These 3 features probably fit together very nicely, but require an overhaul of the predictive charging functionality.

[iceicerickert]

No not 10 minutes but there is a lot already! Im actually playing around with some simple tweaks and it already works quite nice.
So if we can incoporate it in the code base it would be doable I think. But yeah, not 10 minutes :)

[ffunes]

Implemented — available in 1.5.0b3.

How it works:

• During an expensive slot the battery can now deliberately export to the grid, on top of covering the house.
• It is an economic decision, not a fixed threshold, which is where this thread landed. A slot is only sold into if its export price beats the highest import price still ahead in the planning window, plus your minimum arbitrage margin — the same spread requirement already used for grid charging, read in the other direction. If the sale would not clearly pay for the energy you then have to buy back, it does not happen.
• It only sells energy above your minimum SOC, and only the kWh it can tie to a later moment you would otherwise have covered from the battery. Energy you are going to need before the sun comes back is never put on the market.
• The expensive slots are taken first, and each one is limited by what your batteries can actually deliver in that time. The export ceiling is simply your fleet's discharge power — if you want to export less, lower the system-wide discharge limit; there is no separate slider that could disagree with it.
• Anything uncertain — missing prices, a guard, a slot that has expired — removes the export and returns the battery to normal operation on the next cycle. Not exporting is always the safe direction.

Where to find it: the High-Price Discharge switch, with Predictive Charging in Dynamic Pricing mode (it needs a forward price curve). If you have configured a separate feed-in price sensor it uses that; without one it falls back to the import curve, which is correct under net metering.

What you'll see: a High-Price Discharge Status sensor — Disabled / Invalid configuration / No data / Blocked / Waiting / Active — with the plan and the reason behind the current state.

Related but separate: holding solar surplus back for the cheapest feed-in hours is #237 (also in 1.5.0b3), and pricing stored energy by what it cost to store it is #269.

Reports from a real price peak are very welcome.

[iceicerickert]

this looks awesome, I will migrate from my own custom sensors to the complete solution this week and report back.