Save SOC values to a sensor

[victorgarcia98]

Currently, the StorageScheduler is saving the power flows of the storage but not the state of charge. Even though there is a direct relation, it's not trivial as we could have different charging / discharging efficiencies.

With the introduction of the soc-maxima, soc-minima and soc-targets as sensors, it would be nice to plot them altogether to check if the constraints are respected. Also, we could compare the SOC measurements of the storage asset with the expected SOC given by the schedulers.

Moreover, this could be a starting point to have the field soc-at-start defined as a sensor.

As discussed in an internal meeting with @Flix6x and @Ahmad-Wahid, the sensor description would live in a new field in flex-model: soc.

[Ahmad-Wahid]

I have two questions:

• What should happen if I pass soc-at-start as a sensor but there are no data for the sensor. In other words, I have not created the sensor. How should we decide the soc-at-start in this case?
• NaN values should not be saved, right?

[Ahmad-Wahid]

My first question is cleared from the documentation. By default it will be 0.

[Flix6x]

NaN values should not be saved indeed.

[Ahmad-Wahid]

I was trying to save the soc-target values, but I found that it's a list of dictionaries. How should I go forward from here?

soc_target =>  {'sensor-id': None, 'value': [{'value': 0.45, 'datetime': datetime.datetime(2024, 3, 15, 13, 40, 52, tzinfo=datetime.timezone(datetime.timedelta(0), '+0000')), 'start': datetime.datetime(2024, 3, 15, 13, 40, 52, tzinfo=datetime.timezone(datetime.timedelta(0), '+0000')), 'end': datetime.datetime(2024, 3, 15, 13, 40, 52, tzinfo=datetime.timezone(datetime.timedelta(0), '+0000'))}]}

[nhoening]

That looks like time series data to me :)

[Ahmad-Wahid]

It's just a single value with the same start and end. I understand that there might be multiple values but that can saved.

[nhoening]

Ah. With the help of sensor.event_resolution, you can derive the values in between, right?

[Flix6x]

I'd say the first step is to only save the SoC values computed by the scheduler, with support limited to a SoC sensor with instantaneous event resolution. This avoids the need to deal with resampling. And the source of this data is the scheduler (same as the scheduled power data).

Saving the input data (such as targets) can be a separate follow-up issue.

[Ahmad-Wahid]

What does it signify when scheduler.compute() returns multiple schedules?

  if self.return_multiple:
      return [
          {
              "name": "storage_schedule",
              "sensor": sensor,
              "data": storage_schedule,
          }
      ]
  else:
      return storage_schedule

[Flix6x]

We designed this to prepare for schedulers that can output multiple time series. This should be useful for scheduling multiple assets (e.g. each having a power sensor), but also to support your case (single asset with multiple sensors).