API option to customize which price and power sensors to take into account for scheduling

[Flix6x]

I envision an API option to communicate an EMS organisational model:

• Specify/override which price sensors apply to the EMS's up and down deviations
• Specify/override which power sensors should be used to model the devices within the EMS
• (Out of scope, but to take into account in the API design) Specify/override which price sensors apply to the devices

For example, something along the lines of the following optimization context:

{
    "commitments": [20, 21],
    "up-deviation-price-sensors": [4, 9],
    "down-deviation-price-sensors": [4, 10],
    "inflexible-device-sensors": [13, 14, 15]
}

to denote that previous commitments of the aggregate power flow are specified by sensors 20 and 21, upward deviations from those commitments should be priced by sensors 4 and 9, respectively, and downward deviations should be priced by sensors 4 and 10, and the aggregate power flow includes the sum over sensors 13, 14 and 15.

Note that this still assumes only a single flexible device is scheduled (after all, we're calling /sensors/<id>/schedules/trigger). Scheduling multiple flexible devices together will require a new endpoint, and communicating multiple flexibility models in one API call, something along the lines of:

{
    "start": "2015-06-02T10:00:00+00:00",
    "devices": [
        {
            "sensor-id": 104,
            "soc-at-start": 12.1,
            "soc-unit": "kWh",
            "soc-targets": [
                {
                    "value": 25,
                    "datetime": "2015-06-02T16:00:00+00:00"
                }
            ],
            "soc-min": 10,
            "soc-max": 25,
            "roundtrip-efficiency": 0.98
        },
        {
            "sensor-id": 105,
            "soc-at-start": 14.1,
            "soc-unit": "kWh",
            "soc-targets": [
                {
                    "value": 20,
                    "datetime": "2015-06-02T12:00:00+00:00"
                }
            ],
            "soc-min": 5,
            "soc-max": 30,
            "roundtrip-efficiency": 0.95
        }
    ],
    "commitments": [20, 21],
    "up-deviation-price-sensors": [4, 9],
    "down-deviation-price-sensors": [4, 10],
    "inflexible-device-sensors": [13, 14, 15]
}

[nhoening]

Very interesting to consider that this information is not really stored anywhere right?

It's good that the EMS / optimization specs can change over time, but it's a tough problem if one wants to understand the past. Maybe there should be versions of these in the database?

[Flix6x]

Very interesting to consider that this information is not really stored anywhere right?

It's good that the EMS / optimization specs can change over time, but it's a tough problem if one wants to understand the past. Maybe there should be versions of these in the database?

#401 is somewhat related, but it's probably not a good idea to also store the optimization context as sensor data. Perhaps as a separate source (version), every time the optimization context changes, and we store the optimization context as a source attribute.

[Flix6x]

As always, I try to name user-facing API fields such that they have a chance of immediately being understood. Suggestions:

• Not opening up the commitments option right now, since I only see it being used to support explicit demand response. The default commitment is zero kW, which works for implicit demand response.
• Renaming up-deviation-price-sensors to consumption-price-sensor. That is, only 1 sensor for now, and against default zero commitments it effectively becomes the consumption price.
• Renaming down-deviation-price-sensors to feed-in-price-sensor. That is, only 1 sensor for now, and against default zero commitments it effectively becomes the feed-in price.