Flex context as model fields

[nhoening]

In #990, we discuss adding most fields in flex-model and flex-context to the data model, in order to give users less API dev work and more power to review and change important settings in the FlexMeasures UI.

The first step should be the flex context fields for pricing, because they are straightforward: They already represent a sensor (e.g. a market) and nothing else, and they are one interesting setting for users to switch.

Also, the list of inflexible device sensors is interesting - which sensors within an asset (or outside of it? - I'd favor only suggesting a list of offspring) make sense to take into account?

In essence, these fields should be made into data model fields (or in the case of inflexible-device-sensors, an m:n relationship?):

• consumption-price-sensor
• production-price-sensor
• inflexible-device-sensors

And for each, the scheduling logic should get updates:

• These fields can be missing from the schema that comes in via the API
• As fallback, new fields on the model (added here) are allowed.

[nhoening]

Braindump of the steps I think need to be taken:

1. Add these fields to the asset data model. Inflexible sensors are a backward relationship, as the one-to-many relationship leads to a field on the sensor table!
2. Add property or function on asset class, which searches upwards on the asset tree for these fields
3. Adapt scheduling logic (/trigger endpoint and/or _scheduling_job()?) to accept that these fields might not come via API but can be looked up on model
4. Show fields on asset page
5. Enable choosing values (sensors) for these fields on the asset page