Add feed-in peak shaving, i.e. Solarspitzengesetz (Solar Peak Act)

[andig]

Charge home batteries during peak hours to reduce (but not restrict) grid feed-in during peak solar hours.

On evcc side, being able to control this would require evcc-io/evcc#27906.

[larsxschneider]

@andig evcc-io/evcc#27906 adds the capability to stop charging entirely (which might have use cases). However, for the optimizer I think it would be more useful to charge with a certain limit. Do you have an opinion on a mode like BatteryLimitCharge(rate)?

[ekkea]

Can you tell a bit more what you want to address here?

I understand that the "Solarspitzengesetz" has basically two rules which we could support (correct me if I'm wrong):

1. On intervals with negative EEX prices, the remuneration for feeding to the grid is zero.
2. If there is no smart meter installed, the feed in power is limited to 60% of the installed generator power.

If that is correct, I think the optimizer would support (1.) as you can supply a feed in remuneration time series p_E and set the values to zero for all intervals with negative EEX prices. And we can cover (2.) by setting the limit for the export power p_max_exp.

the strategy attenuate_grid_peaks will actually only kick in when there is no real financial advantage in exporting at another point in time. It acts at the same level as charge_before_export. If this is what you want, that's great but I do not see the relation to the mentioned law 🤔 .

[larsxschneider]

Most people, like myself, currently have no smart meter and need to follow the 60% rule. Consider this scenario:

The sun rises and the PV charges the battery at full speed while nothing is exported. The battery is full at 9am. Afterwards, the surplus is exported. However, at 11am there is so much surplus that the 60% cap limits my feed-in. That energy is lost.

If the optimizer told evcc to charge slowly in the morning, I could already feed into the grid during those hours (well under the 60% cap). During peak sun hours, only the surplus above the 60% cap would go to the battery until it is fully charged.

Setting p_max_exp enforces the 60% cap, but it doesn’t tell the optimizer when to charge the battery. That’s where BatteryLimitCharge(rate) combined with attenuate_grid_peaks could help — the optimizer plans the optimal charge schedule and evcc enforces it.

This approach would kill three birds with one stone:

1. Maximize feed-in revenue — spread exports across the day instead of losing energy to the 60% cap at peak hours
2. Grid friendly — morning feed-in is more valuable than adding to the midday peak
3. Battery friendly — the battery doesn’t sit at 100% from 9am to 7pm, which might reduce aging

[ekkea]

Setting p_max_exp enforces the 60% cap, but it doesn’t tell the optimizer when to charge the battery.

This is essentially correct, however, the optimizer will search for the economic optimum which would be charging the battery while there is more solar yield than can be exported due to the 60% grid limit. This sort of also creates a grid friendly behavior.

Only in cases where there is more battery capacity than is needed to avoid loss of solar capacity due to the 60% limit, the attenuate_grid_peaks strategy would come into effect at all. But then it would add extra grid friendliness.

And I agree, both settings would reduce hours in which the battery hangs around at 100% SOC, this is a (positive) side effect.

[iseeberg79]

I would also prefer a limitCharge setting. The mode noCharge/holdCharge should be replaced by limitCharge(zero).

Technically there are inverters supporting not to control the power value from battery but to define a limit for charge or discharge. This should technically be the counterpart of many hold implementations allowing to charge remaining surplus.

It also adresses not to set actual battery power values and not restricting grid feedin power.

The charging should be limited to a value allowing to charge up to a specific power until full. This could be

• a calculated linear limit ensuring a full battery/enough power at evening (respecting PV forecast and household at low risk)
• unlimited on cap situations and/or
• zero to allow delayed maximized charging on cap events.

As limitcharge is a more enhanced approach, limitcharge(zero) might be kind of minimal implementation.

Not to force an actual battery power has some side effects as battery charge capacity is not reserved if loadpoints are charging surplus. Probably it could have some reserved capacity at site power calculation?

I'd love to see this handled by a single instance as this requires optimization by multiple instances, today.

[ttjaden]

@ekkea : I agree, that setting the p_max_exp is sufficient to reduce curtailment losses due to Solarspitzengesetz or other technical feedin restrictions.

But: as far as I know there is no configurtation field within evcc UI, right? @naltatis

In my opinion it should not be configured within pv as there can be more than one PV systems. So it could/should be configured at grid or even better more intuitive at optimizer ?

[nano8443]

I´m one of the (more or less) happy owners of a smartmeter gateway and receive the optimizers output with MQTT to control my 11kWh battery. For me, charging in intervals with positive EXX prices early in the morning, like in these days, is a bit disadvantageaus.. ;-) Additionally, the time with a high battery SOC increases with this strategy. But the batterys capacity is anyway too small to catch the complete time with negative EXX prices in the afertoon.

[ekkea]

@nano8443 can you share an example request to understand the situation better?

[nano8443]

The evopt result "charging_power" is at 1,17KW for tomorrow morning at 6:15 with a SoC of ~50%. It would be better to not charge until 10:15, when EXX prices are going to neg. values for the first time on that day. (and my the remuneration for feeding to the grid is zero)

[naltatis]

But: as far as I know there is no configurtation field within evcc UI, right? @naltatis

@ttjaden Correct, we would eventually need a user configuration for this.

[ekkea]

The evopt result "charging_power" is at 1,17KW for tomorrow morning at 6:15 with a SoC of ~50%. It would be better to not charge until 10:15, when EXX prices are going to neg. values for the first time on that day. (and my the remuneration for feeding to the grid is zero)

I see your point, however, the optimizer does a perfect job of assigning maximum (correct?) charging for the times with zero export prices and allocates the rest to the early hours. I guess you are are adding the assumption that after the end of the time horizon there should be battery capacity left for additional hours with zero feed in price and therefore think it could have been smarter? If so, it would be interesting to learn how the prediction looked 12 hours later. Did the plan to charge early remain or did it change as the optimizer had the rest of the day in its horizon?

Btw, did you run the optimization shown with the strategy attenuate_grid_peaks or not? If so, I would have expected a different behavior.

[nano8443]

@ekkea Sorry, you are right! The optimization was simply running from the evcc UI and I had no idea, that something like attenuate_grid_peaks even exists. But the output of the optimizer shows:
"strategy": { "charging_strategy": "charge_before_export", "discharging_strategy": "discharge_before_import" }
So I think, I have to spend some time with the input parameters to understand, how that should work. Thanks!

[ttjaden]

But: as far as I know there is no configurtation field within evcc UI, right? @naltatis

@ttjaden Correct, we would eventually need a user configuration for this.

@naltatis is there a plan, when to implement the setting in the UI/UX