prevent export of grid-charged energy / self-consumption-only grid charging

[seboos75]

Hi, I would like to request a feature that prevents Predbat from exporting energy that was previously charged from the grid.

My use case is:

I want to keep grid charging for self-consumption and battery preparation.

I still want to export genuine solar surplus when export prices are good.

But I do not want Predbat to charge the battery from the grid and then export that same energy later.

At the moment, in Control charge & discharge mode, Predbat can create plans with repeated charge/export cycles such as Chrg -> Exp -> Chrg -> Exp, especially overnight. This looks like energy arbitrage rather than self-consumption optimization, and it also increases battery wear.

In my country, a prosumer is not allowed to trade energy this way. Exporting energy previously imported from the grid and stored in a battery is not allowed for a normal prosumer setup, so this behavior is a legal/compliance problem, not just a preference.

A useful solution would be an option such as:

“Do not export grid-charged energy”

or “Allow export only from PV surplus / PV-charged battery energy”

or a mode where grid charging is allowed for self-consumption only, but not for arbitrage.

This would be very helpful for users in countries where battery arbitrage is restricted or not permitted.

[gcoan]

have you tried switch.predbat_set_export_freeze_only

https://springfall2008.github.io/batpred/customisation/#inverter-control-options

Once energy is in the battery predbat doesn't keep track of where it came from, this could be the nearest to what you are asking for

[seboos75]

Thanks for the suggestion. I already have switch.predbat_set_export_freeze and switch.predbat_set_export_freeze_only enabled, but Predbat still plans a charge -> export -> charge cycle. From my testing, freeze_only does not stop trading of grid-charged energy, because Predbat does not track where the energy in the battery originally came from. So it looks like this does not solve my problem

[cyberkryten]

I think you need to check the wording/legalities because as has been said, once energy is in a battery it is just electrons. Predbat doesn't track it, but if you are required to then you need to know how you are to account for it.

So, assume that you charge 5kW from the grid and generate 5kW of solar and use 5kW in the house, which 5kW did you use?

Are you allowed to export the 5kW of 'solar' you generated later that day, because you used the grid power for your house, or are you deemed to have used all the solar and are therefore not allowed to export the 'grid power' stored in the battery?

Are you only allowed to export excess Solar the moment it is generated?

How will the grid know how much solar you generated?!

There's so many possibilities, you need to know exactly what is/is not allowed, this will differ by location so probably isn't going to be something Predbat can handle for you as standard, but there's a few ways you can deal with it once you know the exact formula to be used:

You could track export and set predbat to Charge Only control once the 'max' has been reached, that will only allow it to charge the battery, and so it can only export if excess solar is produced.

If you set Metric Battery Cycle Cost to a high value (greater than the difference between import and export) then Predbat won't try to charge for exporting.

You could also create an automation that Predbat uses to set Export and then check if you're over the allowed limit before actually setting the invert to export mode.

[seboos75]

I understand that, from a settlement point of view, once the energy is in the battery it is just energy. But it still seems worthwhile to have an option that limits battery charging only for the purpose of later export. Technically, that does not seem impossible — Predbat already distinguishes between different operating modes, charge/export slots, and can control battery behavior, so a rule like that seems like something that could be added. On the other hand, Charge Only feels like the opposite extreme, because export is not controlled there either.Maybe a better option would be something like: “do not export more than the solar production from the last X hours.”
That would make the rule much more realistic, because it would limit export to energy that is likely to have come from recent PV generation, instead of allowing the battery to be used for grid-charged arbitrage.

[cyberkryten]

If you don’t have export limits then you can just charge the battery and export any excess solar

As I said, you need to define exactly what you expect to be done, in detail to have any chance of this being accepted as a feature request

However, but given how specific this is you will probably need to achieve it yourself with automations as I suggested - eg set the cycle cost high anytime export today > solar today to stop more battery export

[seboos75]

I think a feature like this could still be defined in a precise enough way.
A possible rule, similar to what exists in some other EMS systems, would be: do not export more than the unadjusted PV forecast from the last 24 hours.
In other words, block the ability to export more battery energy than the amount of PV energy that was produced or expected from PV over a rolling time window.

For each hour in the forecast, the system could look back over the previous X hours and compare two sums: the cumulative PV forecast, and the cumulative forced battery discharge planned for export.

The export would only be accepted if total forced discharge is less than or equal to the total PV forecast over that same window.
I have also tried different values for input_number.predbat_metric_min_improvement_export_freeze (currently 20), input_number.predbat_metric_battery_cycle (currently 3.5), and input_number.predbat_metric_min_improvement_export (currently 20), but I was not able to optimize this behavior with those settings.
I also tried using rates_export_override with:

`rates_export_override:

• start: '22:00:00'
  end: '06:00:00'
  rate: 0`

but that did not seem to have any effect. My import is based on two fixed tariffs, while export uses dynamic pricing.

Also, I would not assume this is impossible to verify in practice.
The grid operator knows how much energy I import from the grid, and they also know the installed PV capacity and battery size.
In my view, that is enough to identify at least potential non-compliant behavior
I have also invested a lot of time in this integration, and I think the software is excellent and very configurable.
The only thing I am still missing to be fully happy is the ability to avoid trading energy with the grid.

[cyberkryten]

It could do a lot of things, yes, but if you want a change, then you need to exactly define what change is needed for this situation as no-one else seems to have the same requirements: Is the rolling 24/hours or midnight to midnight? How many hours is X hours? However, given how specific it is, I'm not sure it'll make it too high up the list.

However, the good news is that it's very flexible and I'm still pretty sure you can do this already. If you want to limit exported energy to no more than forecast (or generated?) PV then you can do that with an automation. Regularly check your PV/Export daily sensors and if it shouldn't be allowed, then set Predbat to Demand for the next half hour slot - this is almost the opposite of how many of us deal with Clipping, by Forcing Export to keep space in the battery.

This is the automation I use to set Force Export during the current hour if my Clipped Remaining energy is above the Battery Capacity. If you change that around to compare your Exported and PV figures and set the State to 'Demand' (or maybe a Freeze mode) then it will probably do what you're after:

alias: PV Clipped - Forced Export This Half Hour
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.calc_battery_available_capacity
  - trigger: state
    entity_id:
      - input_number.pv_clipped_remaining_today
conditions:
  - condition: numeric_state
    entity_id: sensor.calc_battery_all_state
    above: 50
  - condition: not
    conditions:
      - condition: state
        entity_id: select.solaredgemodbus_i1_storage_command_mode
        state: Discharge to Maximize Export
actions:
  - if:
      - condition: time
        after: "05:28:00"
      - condition: sun
        before: sunset
      - condition: numeric_state
        entity_id: input_number.pv_clipped_remaining_today
        above: 0.5
      - condition: numeric_state
        entity_id: input_number.pv_clipped_remaining_today
        above: sensor.calc_battery_available_capacity
    then:
      - action: select.select_option
        metadata: {}
        data:
          option: >
            {% set t = utcnow().strftime("%s") | int %}    {{ (t - (t%1800) ) |
            timestamp_custom("%a %H:%M") }}
        target:
          entity_id: select.predbat_manual_export
mode: single

[seboos75]

I do understand the principle and the rules, but I do not yet know how to implement them in practice. What I appreciate about Predbat is the flexibility and the fact that the data and logic are well encapsulated (not cloud).
When testing other EMS systems, I usually only get a simple option like “Buying energy for trade: Yes/No”, without any explanation of what happens internally. The description is only:
“The algorithm will buy energy at a low rate to sell it later at a high rate to maximize profit. Please note that selling purchased energy goes beyond the prosumer status. When trading is disabled, the algorithm only buys energy for consumption and sells energy generated from production.”
I am sure there must be some way to make it block grid charging once PV-derived energy has been discharged, so that it does not start charging from the grid again just for the purpose of selling.

[cyberkryten]

I think the automation will work.

However, I think you've not put a large enough value in the charge rate - you said you've put 20 (not sure of your currency), but what's the difference between import and export values?

From your screenshot, it looks like you import for 65 off-peak and have export slots of 101, 159 and 170. 65+20 is 85, so Predbat will deem all of those slots acceptable for export.
If you want to stop it, then 150 would never use any, and 100 would only use the highest slot.

input_number.predbat_metric_min_improvement_export (expert mode) Sets the minimum pence cost improvement it's worth doing a forced export for. A value of 0.1p is the default which prevents any marginal exports as they must be worth at least 0.1 pence for a slot (less for shorter slots). If you increase this value (e.g. you only want to force export if very profitable), then exports will become less common. The value is in pence per slot of export time.

[seboos75]

I think I agree with you. What you described is about the profitability threshold for export — that is, whether the difference between import and export prices is large enough to justify planning a forced export. It does not create a hard block against trading energy from the grid.

Since I have both set_export_freeze_only = true and set_export_freeze = true, this is even more about controlling export behavior through freeze modes rather than through the simple economic threshold. That is why I believe you are right: metric_min_improvement_export can reduce the number of exports, but it does not solve the problem of charging from the grid only to sell later. I also cannot predict the dynamic export price. And my goal is not to limit export from PV production, but to limit the Predbat mechanism that charges the battery from the grid and then sells that same grid energy shortly afterwards. I also set set_export_freeze: true
set_export_freeze_only: true
but, this is not solutions. Predbat was able to charge the battery up to ~100% from the grid, then export to the grid shortly afterwards, then charge again, and export again. Of course, in total this could still produce a profit, and Predbat handles that very well. However, this is not compliant with the regulations in my country.
I am still thinking about an automation based either on actual consumption or on forecasted consumption, which would switch Predbat into Charge Only. At this point, though, I think I am running out of ideas with Predbat.

[seboos75]

I want to add another concrete example, because it still imports and exports again even with these settings:

metric_battery_cycle: 3.5
battery_loss_discharge: 0.04
battery_loss: 0.04
metric_min_improvement_export: 30
metric_min_improvement_export_freeze: 30

In the example shown, the difference between the import price and the export price is 25, while the metric threshold is set to 30. So on the face of it, this should not qualify, yet Predbat still plans import and export.

+1

apps.yaml