New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Save SOC values to a sensor #1006
Comments
I have two questions:
|
My first question is cleared from the documentation. By default it will be 0. |
NaN values should not be saved indeed. |
I was trying to save the 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'))}]} |
That looks like time series data to me :) |
It's just a single value with the same start and end. I understand that there might be multiple values but that can saved. |
Ah. With the help of |
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. |
What does it signify when if self.return_multiple:
return [
{
"name": "storage_schedule",
"sensor": sensor,
"data": storage_schedule,
}
]
else:
return storage_schedule |
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). |
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
andsoc-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 life in a new field in
flex-model
:soc
.The text was updated successfully, but these errors were encountered: