Feature: zero feed in (when energy prices are negative)
Is your feature request related to a problem? Please describe. In the Netherlands and Belgium negative energy prices or put in other words “having to pay to put your PV power on the grid” is becoming more and more prevalent. EVCC is currently the only (HEMS) tool enabling us to steer significant/worthwile consumption to cheaper hours and auto consume our PV power as much as possible. EVCC is the “last system” and most global system in line and determines the excess on which it can decide what to do with it.
Hence, why not have it decide if and how much excess energy there should be and most certainly when the user will be penalized for delivering energy to the grid while there is already an abundance of PV/green energy.
Describe the solution you'd like Have EVCC control the PV output during certains periods.
Describe alternatives you've considered Victro VRM, but not compatible with SMA inverters.
:green_heart: indeed, only the (fading out) groenestroomcertificaten are withholding us from switching off the PV on sunny sundays.
So what would "zero feed in" controller mean?
So what would "zero feed in" controller mean?
A template mechanism (just as with the charging points or solar inverters) via modbus/protocol which allows EVCC to control the power of the inverters in your household.
A control loop that checks if energy injection tariffs are above/below a treshold, if this is the case and no car is charging it will throttle the power output to something a little above the necessary power in the household.
Example: No car is charging, and user sets treshold to negative prices If negative prices are active EVCC checks power consumption of the house, EVCC checks how much the home battery is charging and can charge maximum, if home battery can not ingest all power then PV inverters are throttled to something a little bit above the zero on the meter principle (definable value).
As an addition to this idea: it might also be that the heatpump is charging with PV surplus but cannot consume all the PV energy. It then would be also good to "dim" the solar panels to just above 0 as mentioned above. This is also a solution for the "terugleverboete" in The Netherlands: you will get charged for every kwh that you feed to the grid.
When the charger can consume more or if you for instance plug in your EV, the "dimming" of the PV can be reduced or cancelled.
As an addition to this idea: it might also be that the heatpump is charging with PV surplus but cannot consume all the PV energy. It then would be also good to "dim" the solar panels to just above 0 as mentioned above. This is also a solution for the "terugleverboete" in The Netherlands: you will get charged for every kwh that you feed to the grid.
When the charger can consume more or if you for instance plug in your EV, the "dimming" of the PV can be reduced or cancelled.
You can cover this by setting the price to a high number, my feature request/logic would never reach said price and thus always provide NOM/zero on the meter then. That’s the beauty of it 🤩
See https://github.com/evcc-io/evcc/discussions/19715#discussioncomment-13421941 for related apis.
When the charger can consume more or if you for instance plug in your EV, the "dimming" of the PV can be reduced or cancelled.
The primary approach would be to limit feed in to a fixed value (zero). The inverter will maintain this value and dimm production. The true challenge here, similar to battery boost, is scaling the loads up when there is no consumable feed-in.
It might make more sense to dimm feed in to at least the minimum step size for scaling any available charger up (e.g. 3p x 1A x 230V for a charging charger or even x6A for a disabled charger). This party is fiddly imho.
See #19715 (comment) for related apis.
When the charger can consume more or if you for instance plug in your EV, the "dimming" of the PV can be reduced or cancelled.
The primary approach would be to limit feed in to a fixed value (zero). The inverter will maintain this value and dimm production. The true challenge here, similar to battery boost, is scaling the loads up when there is no consumable feed-in.
It might make more sense to dimm feed in to at least the minimum step size for scaling any available charger up (e.g. 3p x 1A x 230V for a charging charger or even x6A for a disabled charger). This party is fiddly imho.
The inverters are able to scale down to almost 0W if needed. Can you explain to me/us why a minimum of 6A should be injected? When a charger wants to enable, wouldn't it be possible to ramp up an inverter or multiple inverters, check if there is enough surplus and then activate charging according to the proven/well known logic which we are using now?
How do you know a charger „wants“ to enable in PV mode? The whole definitionnof PV mode is that it enables on surplus. Which you don‘t have in this case.
You know that it is dimmed, and you know the maximum capacity of the charger?
@andig good point. One could solve this by not working with a static zero value but with a variable to be set. Depending on the enable/disable values one should accept that this feed in value is equal to the enable values or accept that the charging point would not enable.
An alternative would be as @tbiest was referring to (if I understood him correctly) where you would check
If PV mode == true and SoC is below SocLimit then open dimmer to provide more than 6A
Why not make it simpler: have all the evcc chargers to work (start/stop/increase/decrease) based on a non-dimmed PV value so they don't get influenced by the dimming. And then decide to dim the PV based on the actual grid feed-in value.
based on a non-dimmed PV value
...and that would come from...?
based on a non-dimmed PV value
...and that would come from...?
When you dim, you know by what percentage you are dimming. I guess this is also a value that you need to set by modbus on the inverter. So I think you can correct for that?
[Non-dimmed PV value] = [Actual PV output] / 1 - [dim %]
I guess
Dimming refers to kWp, not to actual potential production.
That is exactly the problem. You do not know what is the undimmed power production. So increasing the dimming is not an issue, but how can you figure out when to reduce the dimming (increase PV power). I guess the only way to do that is to do a test every 5 minutes or so and remove all dimming and see what happens. EVCC can increase the charging power first if possible. Only after that the PV should be dimmed again to achieve zero export.
That is exactly the problem. You do not know what is the undimmed power production. So increasing the dimming is not an issue, but how can you figure out when to reduce the dimming (increase PV power). I guess the only way to do that is to do a test every 5 minutes or so and remove all dimming and see what happens. EVCC can increase the charging power first if possible. Only after that the PV should be dimmed again to achieve zero export.
If the chargers consume more than the Reduced PV value, the chargers will start to consume from the grid. You can then correct for this value by reducing the dimming with this amount? You need to base the decisions for the chargers on the undimmed PV. And you know the undimmed PV because you know the actual PV + you know how much % you dimmed.
And you know the undimmed PV because you know the actual PV + you know how much % you dimmed.
I do not think you do. As was written before, the percentage is related to the peak output of the inverter. If you decrease the dimming percentage, it does not mean that the output will increase. You only change the maximum allowable output power.
I repeat: we need a mechanism to allow start charging or scaling charging demand under zero feed-in regime. We do have this experimentally for battery boost but it's only one-shot and far from great and has had very little real-life testing.
Maybe we should take this step by step and first focus on preventing feed in while prices are negative which is the first thing we should prevent: overloading the grid and incurring costs on our own household which can be prevented.
If/when we have tested we can have the team look at a control loop to ramp up, if that is feasible.
For now I would already be very happy with a loop that we can enable to prevent feed in all together when it is negative/at a certain price point.
As energy is negatively priced at that point we can always charge our car cheap/ESG efficient and for those that want to charge with their own PV additionally to the negative price benefit from the grid we can have them disable the control loop "Prevent Zero feed in"
What do you say?
Wondering what the device API for zero feed-in should be. I guess we would need something like:
type FeedinController interface {
SetMaxFeedinLimit(float64) error
}
type FeedinLimiter interface {
GetMaxFeedinLimit() (float64, error)
}
This would be for devices that limit feed-in at grid point.
This would also need another option to disable feedin restriction. It is afaikt not a "mode" in terms of charge/hold/normal but orthogonal:
var MaxFeedinLimit float64
Alternatively, math.NaN should disable the limit. Not having "mode" is unfortunate since we'd need to remember per battery if limit has already been engaged or would need to re-set on each cycle.
A simpler option of the Api would be enable/disable only:
type FeedinController interface {
FeedinLimitEnable(bool) error
}
type FeedinLimiter interface {
FeedinLimitEnabled() (bool, error)
}
Does anybody see issues with this simpler api? It might be good enough to get started.
@andig for MOSCOW Must this would be perfect and I absolutely see no issues. Let us collect and contribute some useful results for you from the community and we can see how it goes from there.
Question: From a UI perspective. Do we need a configurable feedin price value under which this behavior is activated or can we use "below 0" as a fixed setting. My naive answer would be "let's export anything I can produce as long as it makes some money". This assumes that my feedin tariff is correctly configured (including fees and chargers), but for this we already have mechanisms in our tariff definition.
see https://github.com/evcc-io/evcc/pull/21839#discussion_r2148186725
We also need to align on the feed-in tariff. Do we treat positive values as "I make money by feeding into the grid"?
Do we need a configurable feedin price value under which this behavior is activated or can we use "below 0" as a fixed setting.
That would make it a solarFeedinControl setting similar to batteryDischargeControl, seems a valid alternative.
Positive feedin tariff values mean "you get paid by your electricity provider". This is how we use this in all our calculations right now.
https://docs.evcc.io/en/docs/tariffs#fixed-electricity-price
Question: From a UI perspective. Do we need a configurable feedin price value under which this behavior is activated or can we use "below 0" as a fixed setting. My naive answer would be "let's export anything I can produce as long as it makes some money". This assumes that my feedin tariff is correctly configured (including fees and chargers), but for this we already have mechanisms in our tariff definition.
see #21839 (comment)
@naltatis Some thoughts which I want to present to you because I am not familiar with the internal parameters/logic of EVCC (yet) ;) . You need to be aware about the fact there is a grey area where injecting costs you money but taking from the grid also costs you money.
For injection tariff aka the settable "decision point" one should be able to take into account the "naked" energy tariff only without any taxes or grid tariffs which are put as a surplus on the naked energy tariff.
I have another use case: Flexio box is a device from the Belgian company Flexio: https://flexio.lifepowr.io/en
Which handles the zero feed-in (during negative feed-in rate hours) and also sells the available energy in my home battery when the wholesale power price is optimal or if there is grid imbalance. (grid imbalance: say a power plant fails and the lack of power from that power plant needs to be compensated, they can use my stored power for that for which flexio and I get compensated)
So I already have a device that handles the zero feed in. Flexio manages my inverter/battery. It can also manage the car charger but I have not enabled that yet.
I've stumbled upon evcc (installed it in homeassistant) and it seems to pick up on all my devices. (home battery/inverter/car/charger/power meter) I'm wondering/testing if flexio and evcc will play nice together. e.g. While the zero feed-in of flexio is active (during negative feed in rate hours), will evcc be able to charge my car (as the decision point is excess power aka feed-in)?
if not there would be a lost opportunity to use solar power that my system could have generated but was prevented by the zero feed-in principle of the flexio box.
could be fixed by:
- comparing the forecasted solar production of the system to the actual production of the system. which I know is a guestimate but better then nothing if the difference is too big, start the car charger (if no additional grid power is used in the first minutes it's fine to continue charging as the PV system still has headroom, if not stop charging, recheck every so often)
- see if zero feed-in limitation has been set on the inverter. I don't understand all the technicalities, but I assume there is a flag or parameter in the inverter which prevents the PV system from producing more energy then what the current house load is. If this parameter/flag has been set, start charging (if no additional grid power is used in the first minutes it's fine to continue charging as the PV system still has headroom, if not stop charging, recheck every so often)
Just my 2 cents as a non-programmer.
I hope it's useful in some way ;-)
While the zero feed-in of flexio is active (during negative feed in rate hours), will evcc be able to charge my car
Same answer as above: yes, but not in PV mode since excess PV is not available.
could be fixed by:
Yes, but that's quite complex and will, worst case, trigger charging over and over again. For time being I'd stick to https://github.com/evcc-io/evcc/issues/21747#issuecomment-2972774554.
See https://github.com/evcc-io/evcc/discussions/22468 for context