springfall2008
input_number for Configurable Max SoC%
Is your feature request related to a problem? Please describe.
This is intended to help with a few problems.
- Firstly, to allow people to leave a known amount of space in case of clipping, and
- Secondly, to allow people to ensure that any solar power can be directly exported without being stored in the battery (which incurs losses and also adds to battery cycling).
- Thirdly, it could be used to reduce the amount of charging activity in the extreme upper SoC range, which causes more battery degradation than charging elsewhere in the SoC range (this is something I particularly worry about so I try to stick to 20/80 charging most of the time, other than regular calibration runs).
- Fourthly, charging in the extreme upper end of the SoC range is slower than elsewhere (because the battery is trying to protect itself), hence this would allow the user to avoid the slower charging zone.
Describe the solution you'd like
I would like a configurable Maximum SoC% setting, above which all solar is directly exported (Freeze Export) rather than being stored in the battery, and also to stop overnight charging at that level. Zero/negative would mean no limit and the optimisation process decides (as current behaviour). Using an input_number would mean that people can control it via automations to customise the behaviour to their particular use-case.
It's basically input_number.predbat_best_soc_max but extended to force freeze-export during the day (a switch to modify the behaviour of best_soc_max would have the same effect).
Describe alternatives you've considered
Currently the optimisation process will try to set Freeze Export slots during the solar periods, but this seems to be inconsistent since it depends on there being enough of an improvement to be picked up. I've seen it flick back and forward between the two modes on the inverter as subsequent plans have slightly different optimisation. So an alternative might be to start with Freeze Export on all PV slots as a default, and only remove them if the export would be better in a different slot, or if the battery level is lower than the expected load.
Another alternative would be to add optimisation metrics for additional battery degradation factors beyond just summing throughput (charging in extreme SoC ranges, extreme temperatures, and so forth). This is only relevant to the third use-case.
A third alternative is that my inverter allows the user to set the maximum SoC as a hard limit in a similar fashion, but doing this would confuse predbat because it would not know why charging stops (additionally, being a hard limit, it would result in any clipping being lost, which is undesirable for most people).
A 4th alternative would be an input_boolean to modify input_number.predbat_best_soc_max so that it forces freeze-export above the specified SoC during the day.
However, I think a simple configurable Max SoC% setting is easier to understand and implement, and leaves it up to the user to decide how much of a SoC buffer they would prefer, and allows them to automate it if they wish.
Additional context
- FR - Clipping buffer - https://github.com/springfall2008/batpred/issues/1206
- Discussion - How to configure max charge %? https://github.com/springfall2008/batpred/discussions/2126
- Battery degradation factors (cell temperature, SoC extremes, charging speed) - https://mospace.umsystem.edu/xmlui/handle/10355/73777#:~:text=The%20degradation%20rate%20is%20affected,to%20better%20serve%20their%20purpose
I should note that Freeze Export has been more consistent since the last update than it was at the time I submitted this feature request.
I would like a configurable Maximum SoC% setting, above which all solar is directly exported rather than being stored in the battery, and also to stop overnight charging at that level. Zero/negative would mean no limit and the optimisation process decides (as current behaviour).
How do you see the switch to direct export being achieved?
Do you meant if the Max SoC is reached, switching to Export instead of self-use? That could be hard to manage. A simple 'charge limiter' would be easier and that's how I'd envisioned a Max SoC working: simply use it to limit grid powered charging to the Max SoC value but once it is achieved, return to normal planning (ie it is simply a proxy for the normal, 100% limiter).
This may differ between systems - mine is a Hybrid with DC connected batteries so if there is more solar then this will increase the charge state of the batteries and is not Inverter limited, I've not got any experience of AC connected batteries to know how this could work for those systems.
How do you see the switch to direct export being achieved?
For PV, I see it picking the 'Freeze export' mode instead of 'demand' mode (or in Fox terms, 'Feed-in First' rather than 'Self use', this is on a hybrid DC coupled system BTW, GivEnergy, Fox, & most others support it). Freeze Export puts the inverter into a mode where PV is first used for house load, then any surplus is exported. If the export limit is hit, then the inverter starts charging the battery. So it is the inverter which is doing all the work to figure it out, all predbat does is set the appropriate mode via a single inverter write.
--- Edit:
I can see you have SolarEdge, the relevant inverter mode is called 'Charge from clipped solar power'. So your system already supports it (provided it is configured appropriately in predbat).
This issue on SolarEdge systems is that the Freeze modes only really work when the import rate is low.
The "Charge from Clipped Solar Power" mode, disables discharge from the battery completely and so if House Load > PV then any excess is drawn from the grid which is a 'bad plan' if peak rates are in force - no easy solutions!
so if House Load > PV then any excess is drawn from the grid
I have an automation which tracks house load versus PV versus the force discharge rate every 10 seconds during the expensive period, and makes changes if necessary if it starts importing from the grid. So something similar could work for you (changing inverter mode rather than the force discharge rate).