Scheduling a battery against multiple constraints

[anirudh-ramesh]

I have a use-case of scheduling a battery pack against a combination of three constraints:

• load (MW)
• WTG production (MW, constant €/MWh)
• SPV production (MW, constant €/MWh)

I've added beliefs for each of the three electricity meters. There's a forecast created from an external application for each of the three entities mentioned above.

I'm able to prepare a schedule against an individual constraint, but I'm unable to use flexmeasures add schedule for-schedule with sensor-id as the battery schedule. What should be the consumption price sensor for this use-case?

Thanks!

[Flix6x]

(I'm assuming you used for-storage rather than for-schedule.)

It looks like you want to optimize the battery as part of a system that includes (power sensors for) a load and 2 generators (wind and solar). Our storage scheduler allows you to include those 3 power sensors using the inflexible-device-sensors field (as a list of sensor ids).

Note that FlexMeasures' default is to store consumption as negative power values. If you need the scheduler to switch the interpretation of the sign of your power values, add the consumption_is_positive attribute to the given sensor, for example, using:

flexmeasures edit attribute --sensor-id <id> --attribute consumption_is_positive --bool true

As far as pricing is concerned, our current scheduler only allows you to put a price on the net load/supply flow of this system, rather than on the power flow of the individual assets. To price the net load flow, you can use the consumption-price-sensor field (a sensor id). To price the net supply flow, you can use the production-price-sensor field (also a sensor id, which can be the same as the consumption-price-sensor).

You'll need to set up at least one price sensor with price data, too.

I should note that the fields I mention above are all API fields. For the CLI (which is what it looks like you're using), we have corresponding options (in flexmeasures==0.12, for just 2 out of 3). They are called --consumption-price-sensor and --production-price-sensor. Importantly, the --inflexible-device-sensor option hasn't been implemented yet.

If this answers your question, I would propose to interpret your issue as a feature request for implementing the --inflexible-device-sensor CLI option.

[anirudh-ramesh]

Hi @Flix6x,

Thanks for helping me out here! Yes, for-storage is what I used, sorry.

I'm using the inflexible-device-sensor option in the HTTP REST API with the sensors, beliefs and configurations defined in a manner similar to the example in the API documentation i.e. as follows, from sensors.py, after replacing the values with the correct sensor ids.

            {
                "start": "2015-06-02T10:00:00+00:00",
                "duration": "PT24H",
                "flex-model": {
                    "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,
                },
                "flex-context": {
                    "consumption-price-sensor": 9,
                    "production-price-sensor": 10,
                    "inflexible-device-sensors": [13, 14, 15]
                }
            }

With this API call, I'm seeing the validation error coming from Marshmallow returning 422 UNPROCESSABLE_ENTITY with an Unknown field. for each of the three key-value pairs i.e. consumption-price-sensor, production-price-sensor and inflexible-device-sensors. I see, however, that the JSON body format is in accordance with FlexContextSchema.

What's the correct way to diagnose this 422 error?

Thanks!

[Flix6x]

Looks like you encountered a broken feature regression (@ArdJonker I think you ran into this as well). I'm working on the fix right now (#593).

[anirudh-ramesh]

@Flix6x, I see, okay, I'd be glad to contribute to a patch.

[nhoening]

@Flix6x, #593 has been merged. So can we close this issue now?

Should @anirudh-ramesh test on the main branch (if possible)?

[Flix6x]

@anirudh-ramesh Thanks for the offer. I've just released flexmeasures==0.12.3, which should fix the regression. Please reopen this issue if it still doesn't work for you with the new version.

Otherwise, if you have a need to be able to pass --inflexible-device-sensor options (using multiple=True) to the corresponding CLI command, I'd be happy to accept a contribution.