Energy optimization use cases

[andig]

Recently, there has been a bunch of new requests for adding more control over how especially solar generation with regards to feed-in and battery energy should be utilized.

In an attempt to structure what use cases evcc already supports do see what we're missing I've drawn the following table:

Component	Use Case	Feature	Measurement
Adjustable loads (e.g. chargers)	Use excess PV energy	PV mode	Grid feed-in power
	Cost-optimised grid charging	Planner	Grid consumption cost
	Low-cost grid charging	Smart grid charging	Grid consumption cost
	Avoid high grid cost		Grid consumption cost
	Peak throttling/ Load management		Grid consumption power
Solar generation	High-revenue grid feed-in	Smart feed-in priority	Feed-in cost
	Avoid high-cost feed-in	Smart feed-in disable (#21747)	Feed-in cost
	Peak shaving/ 70% reduction		Feed-in power
Battery utilization	Battery-supported charging	Battery-supported charging	Battery soc
	Forced battery discharge	Battery boost	Grid feed-in power
	Avoid high-C battery-to-battery charging	Battery discharge control	Charge mode & power
	Cost-optimised grid charging	Battery grid charging	Grid consumption cost
	Cost-optimised battery discharging	Battery discharge disable (#22301)	Grid consumption cost

Please let me know if I forgot anything or add more use cases to the discussion to help rounding the picture.

[benesolar]

If possible i would like an option for energy communities.
That means adjustable min grid feed-in (from pv and battery) including a daily schedule, weekend schedule, etc.
Also take into account the forcast energy for the day.

[CiNcH83]

60/70% cutoff? Shift home battery charging, EV charging or domestic hot water generation until noon to prevent the cutoff.

Or is this considered something of the past?

[andig]

It's actually the same as load management for the grid connection point: keep consumption/ feed-in power below a certain limit. I'll add both to the list.

[BravoNLD]

1. Maybe it is already on the list, but I would like a feature to charge below a certain price. With the planner this is completely doable for the price that I have to pay to the electricity company (cheap grid charging). The tariff for feed in is at a lower rate, so PV surplus is less costly. So there are some moments that the combined price of my PV surplus and some power from the grid is below the threshold that is in the planner.
   The charger/battery should be able to match the load till the point that the cost is below the cost/unit threshold, within the min A and max A boundaries of course.

[andig]

So there are some moments that the combined price of my PV surplus and some power from the grid is below the threshold that is in the planner.

That doesn't exist in evcc. It's either full-pv or forced charging. In the latter case price doesn't matter. I don't think it fits the patterns here?

[Kiechlus]

Maybe that's already in "Cost-optimised battery discharging" or "Peak shaving" in 22495:

• Feed-in from battery (or car in future) when feed-in revenue is high
• Only so that it is still enough for expected consumption
• Would be typically in summer mornings/evenings where larger batteries available

Could be started with very simple UI, just opposite of grid-based home battery charging and users can script their own logic. Use cases in Germany still limited because no dynamic feed in prices. But saw them in Austria already.

[andig]

Feed-in from battery (or car in future) when feed-in revenue is high

That's "High-revenue grid feed-in". Optimizer might make this more flexible in future. We reduce local demand, but there is no forced discharging for this case.

[harmendp]

Sorry if already aswered before, but is there a specific reason why battery discharge to grid is not allowed/considered?

It can certainly help to get battery to a decent level (positive feed-in price) to absorb all energy the next day (negative feed-in price) when working with dynamic tarifs.

[andig]

Good question. Tbo: not allowed in Germany until now. We'll need to revisit this now anyway since V2G will become regulatory reality in 2026 (MiSpeL).

[harmendp]

In Belgium v2g not allowed yet as far as I know. Battery feed-in is no issue. I´m certainly willing to take a look. Will need an extra battery mode to begin with.

[andig]

See #27906 (comment)

[bmesuere]

For "Cost-optimised grid charging" it would also be nice to have a planner to set a target SoC instead of just a price point.

[andig]

Use case unclear. For what purpose? Seems this doesn't match the scheme here, separate discussion?

[RTTTC]

Heatpumps with relay controlled boost mode and dim/stop mode.
Boost - during pv excess and possibly when grid price below certain threshold (less important as there is not much energy volume to be added to a normally operating heating system/hot water tank)
Dim/Stop during high energy price periods (very important)
Heatpump uses much more energy than a vehicle - in my case 4x more energy per year that my car, so every bit of optimisation helps my wallet and also helps stabilise grid during high demand

[andig]

Dimming is a special case of load management. Currently only activated for chargers supporting it (SG Ready) but not meters. Meters is #24595.

[RTTTC]

Another idea for heating devices - to have a setting that would shave off the selected number of highest energy price hours by dimming/stopping heating during those, automatically each 24h period. (dynamic pricing)
This way , if I select for example "3 hours and 15 minutes" setting - my heatpump would operate for a total of 20 hours 45 minutes and be idle during peak price periods thus saving money and helping the grid.

[andig]

Does not match this discussion. For timings use external automation.

[MorrisJobke]

This is special for Germany based PV setups, but since February 25th there is the change that in case of a negative price there is no feed-in payment happening anymore. That has two implications:

• the price for the kWh charged during those times changes from the feed-in rate to 0
• it would make sense to have a special charging option to only charge in those times to use this as much as possible

I'm also happy to help out from a coding perspective if wished.

For more details https://www.clearingstelle-eeg-kwkg.de/haeufige-rechtsfrage/264 has listed the key numbers.

[andig]

the price for the kWh charged during those times changes from the feed-in rate to 0

Make sure your feed-in tariff reflects that so evcc is aware.

it would make sense to have a special charging option to only charge in those times to use this as much as possible

Separate discussion. "only" limits any other use case, so that won't work.

[bigbig6]

Hello,

To have a specific priority between each loadpoint and home battery.

I asked a feature about it but it was automatically closed ([https://github.com//issues/24599])

For example, for my cars, when a 40% of home battery SoC is reached I prefer to charge cars.
But for water heating, maybe a 25% is suffisient, anyway a need to have hot water.
And for the swimmingpool, 70% is suffisient, don't matter I can swim in autumn, the house is most important.

I know i can act on software, but it is easier to parameter it once, and don't touch it anymore.

Thanks.

[florian240483]

smart feed-in priority is currently implemented only for Loadpoints. With the new "Hold Charge-Mode" this should also be possible for the home battery.

[chriser-]

Maybe a uncommon use-case: My panels are able to generate 12kW of peak power, however my inverter is only able to supply 10kW AC. If the battery is not full, the remaining 2kW would charge the battery, but usually the battery is already full by this point.
This use-case could indirectly be achieved by the "reduce grid peaks" method, but I would love to have this behavior directly in the optimizer.
PVSOL estimates the losses to around 250kWh per year (of around 15000kWh total generation), which is almost nothing, but not exactly nothing 😄

[andig]

That should go into the optimizer when we make it actionable (first step is to show the actions, see #30834). It's currently not aware of the AC limitation. See evcc-io/optimizer#84 for further discussion.