Feature/save soc values as a sensor

[Ahmad-Wahid]

Description

This PR introduces create_soc_schedule, a function to generate a state of charge (SOC) schedule from provided data. It also handles the creation or retrieval of the corresponding SOC sensor.

• When the scheduler is instantiated with multiple=True and the flex-model passed to it includes a "soc": {"sensor": <sensor_id>}, its compute function returns a dict that includes the SoC schedule next to the power schedule.
• Unit conversion to the unit of the SoC sensor.

Look & Feel

UI output looks like this:

How to test

Try to run the Toy examples(1 and 2), first add the beliefs from here and then add the schedule from here. You will see a sensor with name soc schedule and id 4. Similarly, you can see the data in timed_beliefs table.

Further Improvements

Follow-ups:

• Test passing a fixed quantity to "soc". This should be used as the starting value, and we should throw a ValidationError if both "soc" and "soc-at-start" are passed in the flex-model).
• Read starting value from soc sensor, plus test cases. We should make some sort of inference if the sensor had not registered a value for the exact start time of the schedule, or fail with a clear error message.
• Test passing a time series specs to "soc". We should make some sort of inference if the specs do not contain a value for the exact start time of the schedule, or fail with a clear error message.

Related Items

Mention if this PR closes an Issue or Project.

---

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

[Flix6x]

Thanks. It's even a bit more already than what was needed. Let's limit the scope just a little for clarity and a step-wise robust approach, and other than that I think we only need to pass some more info to the integration function.

[Flix6x]

I resolved some merge conflicts and updated the PR description (incl. follow-up suggestions). I hope that clarifies the scope of this PR. Can you create the follow-up tickets?

As for this PR, I suggest to leave in the commented out code that already works towards reading the starting SoC from the SoC sensor. The one code change I'd still like to see is the CLI and API initialize the scheduler with multiple=True in case the "soc" flex-model field is used. Finally, some documentation is within this PR's scope. Specifically, a changelog entry and an entry in the list of flex-model fields in features/scheduling.rst.

[Flix6x]

Suggested change

	help="State of charge (e.g sensor:<id>, or 0.328) at the start of the schedule.",
	# help='State of charge (e.g sensor:<id>, or "328 kWh") at the start of the schedule. If a sensor is passed, the computed schedule will also be saved to it.',
	help='If a sensor (e.g sensor:<id>) recording the state of charge is passed, the computed schedule will also be saved to it.',