docs: be more precise in flex-model field descriptions for StorageScheduler #1041
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
More clarity on some flex-model field descriptions, the idea came up when someone on the mailing list used
soc-min
and thensoc-at-start
below that, which is as of now infeasible for our storage scheduler.I'm not quite happy with this PR yet, either.
Apparently, we are very hard on the
soc-min
andsoc-max
values, while we are (planning to be) softer onsoc-minima
,soc-maxima
andsoc-targets
. I notice that the terms "min"/"minima" and "max"/"maxima" don't give that impression.Example from a user perspective: If I prefer my EV battery to not be charged below 20%, I set that as
soc-min
. My intention is not that I bring the EV back to the charger at 10% and no schedule will be made until I bring it back up to 20%.