add (device) consumption and production capacities as sensors

[victorgarcia98]

Description

This PR introduces the capability of defining device-level power constraints as time series.

This sensors can be passed through the flex-model and the scheduler will look into the sensors belonging to the device (sensors of the same asset) and look for sensors with some alias.

To support this, this PR introduces the concept of sensor alias, a new column of the sensor table that serves as an internal reference for sensors. Using the name would have been a good alternative but the user could change it, the idea is that the alias is not touched by the user.

Further Improvements

• Do the same for the site-level capacity. This might require defaulting to a sensor belonging to the parent Asset.
• Document this.
• Create more tests where, we are actually checking that the min/max device constraints columns are being set properly.

Related Items

Closes #761

Note: I'll keep this PR as draft for now to flag this as very prototype work.

---

• 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]

I don't really understand what the alias concept is for yet. Could you give one or two examples of how you'd intend to use it?

[victorgarcia98]

I don't really understand what the alias concept is for yet. Could you give one or two examples of how you'd intend to use it?

Sure. In short the alias is a protected name which means that users should not be able to edit it. Even though the name cannot be changed via the UI yet (as far as I know), It will probably be something we want to implement. If we rely on the name for internal mechanisms the process might fail in case the name is changed.

Some examples:

• What is the power sensor of an Asset? The one that has the power alias. The user might decide to use any other name on the visual side but internally, we can fetch that sensor using the alias power. Alternative names: discharge, charge, charge power, discharge power, consumption, production, ...
• What is the SOC of the battery? The one that has the SOC alias. Same here: the user could chose to present a different sensor name. Some examples: State of Charge, Fill level, Capacity, ...
• Solar power: power, production, active power, dc power, ...

An alternative would be to define which sensor represents what as a the asset attribute.

Other reasons to have this alias is to standarize operations. Let's say we want to set up 100 sites. In that case, we might use a format for the sensor names, for example: charge power. In another project the client might set this as discharge power. Internally, we could just fetch the power sensor using the power alias and use the consumption_is_positive attribute to get the sign right.

[Flix6x]

Then technically the alias isn't required for this PR, right? This is about allowing API users to pass a sensor ID rather than a float. My line of thinking is the following.

Right now, we support:

{
    "flex-model": {
        "power-capacity": "25 kW"
    }
}

After this PR, this would become a viable alternative:

{
    "flex-model": {
        "power-capacity": {"sensor": 51}
    }
}

The title of this PR suggests it tackles a second feature at the same time (separate device power capacities for consumption and production), which is fine. My line of thinking would be to keep the API fields as consistent as possible, by introducing the consumption-capacity and production-capacity fields, similarly to what we have done with site-power-capacity, site-consumption-capacity and site-production-capacity. Then we would support flex models such as:

{
    "flex-model": {
        "consumption-capacity": "25 kW",
        "production-capacity": {"sensor": 51}
    }
}

In this example, the consumption capacity is a constant value, while the production capacity changes over time, as recorded in sensor 51.

[victorgarcia98]

You're absolutely right, the alias feature is not really needed to allow passing the capacities as sensors.

I've created a new Schema for what I call a QuantityOrSensor (name TBD). Maybe the name should be something more inline with QuantityOrEntity to allow for an Asset to be an input? Perhaps it's fine to limit it to a sensor given that it's the way we describe the data.

On the side, I've created the utility function get_series_from_sensor_or_quantity to create a pandas series from the output of a QuantityOrEntity field.

This feature is tested in flexmeasures/data/models/planning/tests/test_solver.py:test_battery_power_capacity_as_sensor.

[Flix6x]

Just an update: I'm refactoring this work slightly and will create a PR to merge into this branch any day now.

[Flix6x]

Looks like this is almost ready to ship out. Can you resolve the merge conflict, add a changelog item, and create tickets for your suggested follow-ups?

[victorgarcia98]

Looks like this is almost ready to ship out. Can you resolve the merge conflict, add a changelog item, and create tickets for your suggested follow-ups?

Thanks! I've resolved the merge conflict added the changelog entry and created the tickets.

[nhoening]

A side question: These capacity fields are not supported in flexmeasures add schedule for-storage, right? Should this be a new issue?

[Flix6x]

Yes, new issue please. We want to make headway with the API first.