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.

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.

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.

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

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?

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.

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