Make soc-minima and soc-maxima the default, simplifying usage

[nhoening]

Users use state of charge (soc) constraints as one of the most crucial flex-model parameters.

We now have two settings, i.e. for minimums we have soc-min and soc-minima. (in this issue, we will talk only about minima, but the same needs to be applied to maxima).

soc-min is the one users will usually reach for first. Simple name, simple usage. Just one value.

However, it is being interpreted as a fixed constraints, and an effect can be that no schedule is feasible in some situations. soc-minima is recommended as it is interpreted as soft target. It is more powerful for dynamic situations (e.g. date ranges of thresholds), so it is not as straightforward to use.

Overall, we need to simplify. There should be one powerful setting. Plus maybe a simple fallback option for each situation where the main setting has no values.

• First, relax-soc-constraints becomes True by default. That also simplifies, as this was a major reason to have two distinct settings. Actually, we are doing this in an ongoing PR already (where the fallback scheduler is retired), in Feat/retire fallback scheduler #2252.
• soc-min becomes the default setting to work with. It absorbs soc-minima' s functionality, actually. It's purpose of a fixed value is moved to a new setting "default". Here is a simple example, where only a sensor is set, plus the default:

  {
     "soc-min": {
       "sensor": 50,
       "default": "0 kWh"
     }
  }
  

  (the sensor option seems already to be possible in the schema, is it supported by the scheduler @Flix6x ?)
• (In the future, this default setting should allow 0% and 100% if we stop requiring energy units, but for something like temperature it's unclear. So for now, we keep it as energy units.)

We need these changes:

• rename soc-minima to soc-min
• update the schema, to allow for the "default" field (actually the schema supports a fixed value as far as I can tell, but we need to accept bot a dynamic and a fixed value, so the schema might need to be a bot special.
• update the scheduler to take the fields into account correctly (dynamic first, default is fallback, if given) - adapt scheduler tests to pass, maybe add one or two.
• update the docs with renaming - check both Sphinx and OpenAPI
• update the UI (flex-model dialogue, which currently only allws to add a sensor - a fixed value is supported by this UI as well, in principle, but we need to label it "default" in the UI.

Also, improve the docs on the field. Here are two things I noticed:

• In the API (Swaggerdocs) schema of the trigger endpoint, there is only one implementation listed under "Time series specification containing a list of segments that together describe a variable quantity.", namely value/start/duration. There are two other means of describing a time range, I believe. Why are they not listed?
• The docs in the flex-context dialogue says "Both single points in time and ranges are possible, see example." But there is no example shown in that dialgoue. Ideally, the examples could also be incuded in the flex-model dialogue, in a foldable way.

I feel that copilot can make good suggestions to most of this, as we have good modeling/architecture in place, but the dev in charge needs to think along and check independently.

[Flix6x]

• I get the rationale behind simplifying, but I thought we wanted to have a single field instead. Instead of soc-min-default, I recommend extending the SensorReferenceSchema to accept a default there, so for example:

  {
    "soc-min": {
      "sensor": 50,
      "default": "0 kWh"
    }
  }

  • or "missing" or "fallback".
  • In this example, I kept soc-min instead of soc-minima, as it's the shorter of the two, but I don't really mind either way.
• Why is support for recurring (soc) limits needed?

[nhoening]

I agree with keeping only one, and soc-min would be nicer to keep.
Good idea to add a fallback, but I'm not sure if our UI support would become more difficult - you can recall the current code relies on fixed values or sensors.

On that note, the recurring soc limits were your idea I believe, we discussed that this is what may users need, setting dynamic limits every day again is cumbersome. You suggest a sensor would be a better trade-off? Can soc-minima be a sensor today?

[Flix6x]

I may have brought up the recurring profile idea when regarding commitments, such as ToU capacities. I don't think it would be used much for SoC limits. Regardless, it would be something that extends the VariableQuantityField, impacting all fields that use that schema, making them all more powerfull. Imo it would be a separate story. And it should start with discussing the pain point. For instance:

The sensor reference can be cumbersome, because you have to fill the sensor with data for it to be useful. However, once you do, you also obtained a good record of scheduling inputs for later analysis and reporting. One idea is to add support for setting a recurring time series in the flex-config. Another idea is to add support for recording a recurring time series on a sensor. Both ideas require a new widget, but the latter avoids some extra work such as adapting the StorageScheduler amd making a recurring time series spec show up in charts.

[nhoening]

I don't understand the recurring time series on the context thought.

But a widget to select a piece of time series and then make it repeat sounds cool.
Maybe in combination with drawing a time series with clicks on the graph? No idea how difficult that is, but it would be amazing for playing around.

[nhoening]

I also think we should separate more than one stories from this