Add `flex-model` field on asset model

[nhoening]

Similar to our work on the flex-context, the flex-model can live on the asset model, as well.

Some attributes will be needing migration, as well.

[joshuaunity]

Flex model Fields:

soc-at-start: Not Moving
soc-unit: Not Moving

soc-min: To be moved
Current/Falback attribute: min_soc_in_mwh
Data type Before: Float
Data type After: Fixed quantity, sensor

soc-max: To be moved
Current/Falback attribute: max_soc_in_mwh
Data type Before: Float
Data type After: Fixed quantity, sensor

soc-minima: To be moved (no fallback attribute)
Data type Before: None
Data type After: sensor

soc-maxima: To be moved (no fallback attribute)
Data type Before: None
Data type After: sensor

soc-targets: To be moved (no fallback attribute)
Data type Before: None
Data type After: sensor

state-of-charge: To be moved (no fallback attribute)
Data type Before: None
Data type After: sensor

soc-gain: To be moved
current/Falback attribute: soc-gain
Data type Before: list of Fixed quantities or Sensor (E.g [100 kw, {"sensor": 4}])
Data type After: list of Fixed quantities or Sensor (E.g [100 kw, {"sensor": 4}])

soc-usage: To be moved
current/Falback attribute: soc-usage
Data type Before: list of Fixed quantities or Sensor (E.g [100 kw, {"sensor": 4}])
Data type After: list of Fixed quantities or Sensor (E.g [100 kw, {"sensor": 4}])

roundtrip-efficiency: To be moved
Current/Fallback attribute: roundtrip_efficiency
Data type Before: Float
Data type After: Fixed quantity, sensor

charging-efficiency: To be moved
Current/Falback attribute: charging-efficiency
Data type Before: Fixed quantity, sensor, Float
Data type After: Fixed quantity, sensor

discharging-efficiency: To be moved
Current/Falback attribute: discharging-efficiency
Data type Before: Fixed quantity, sensor, Float
Data type After: Fixed quantity, sensor

storage-efficiency: To be moved
Current/Falback attribute: storage_efficiency
To be transformed to storage-efficiency
Data type Before: Fixed quantity, sensor, Float
Data type After: Fixed quantity, sensor

prefer-charging-sooner: To be moved
Data type Before: None
Data type After: Boolean

prefer-curtailing-later: To be moved
Data type Before: None
Data type After: Boolean

power-capacity: To be moved
Current/Falback attribute: capacity_in_mw
To be transformed to power-capacity
Data type Before: Float
Data type After: Fixed quantity, sensor

consumption-capacity: To be moved
Current/Falback attribute: consumption_capacity
Data type Before: Fixed quantity, sensor
Data type After: Fixed quantity, sensor

production-capacity: To be moved
Current/Falback attribute: production_capacity
Data type Before: Fixed quantity, sensor
Data type After: Fixed quantity, sensor

(only consumption)

The above was commented on in the docs. It's unclear what this comment means for now

@Flix6x

[nhoening]

Flex model Fields:
....

Why is roundtrip-efficiency not being moved? I believe it should, and it also has a current/fallback attribute, see here.

Also, storage-efficiency is being moved, which is similar in function.

[Flix6x]

(only consumption)

The above was commented on in the docs. It's unclear what this comment means for now

I figured it out. It means that the example value of setting the production-capacity to 0 kW effectively means that the device can not produce anything, so it is a consumption-only device.

[Flix6x]

Why is roundtrip-efficiency not being moved? I believe it should, and it also has a current/fallback attribute, see here.

Alright, let's move it, too. @joshuaunity I edited this field in your list accordingly.

[nhoening]

(only consumption)

The above was commented on in the docs. It's unclear what this comment means for now

I figured it out. It means that the example value of setting the production-capacity to 0 kW effectively means that the device can not produce anything, so it is a consumption-only device.

Great, I recall being confused by that as well.
Please clarify as part of this PR.

[Flix6x]

More notes:

@joshuaunity I noticed the following fields in our StorageFlexModelSchema are still a QuantityField rather than a VariableQuantityField. That means these fields did not support passing a sensor reference yet.

• soc-min
• soc-max
• roundtrip-efficiency (actually a EfficiencyField, supporting a float or a string quantity with % units)

And we have a new field in our schema, too, which I had missed when I went through the stable documentation, but is already in our latest documentation:

• prefer-curtailing-later (boolean)

Finally, a new field in our schema, that hasn't got documentation yet in our flex-model section:

• state-of-charge (Data type before: None (no fallback) and Data type after: Sensor)

[nhoening]

I guess boolean fields would be the new UI feature we didn't do yet :) (not this issue/PR, of course)

[Flix6x]

Please clarify as part of this PR.

For example, by changing the comment to (i.e. no production).

[joshuaunity]

More notes:

@joshuaunity I noticed the following fields in our StorageFlexModelSchema are still a QuantityField rather than a VariableQuantityField. That means these fields did not support passing a sensor reference yet.

• soc-min
• soc-max
• roundtrip-efficiency (actually a EfficiencyField, supporting a float or a string quantity with % units)

Ok, does that mean that in the new schema, we leave them as QuantityField or no use VariableQuantityField.

And we have a new field in our schema, too, which I had missed when I went through the stable documentation, but is already in our latest documentation:

• prefer-curtailing-later (boolean)

Finally, a new field in our schema, that hasn't got documentation yet in our flex-model section:

• state-of-charge (Data type before: None (no fallback) and Data type after: Sensor)

So I should add them to the list as well as the new schema I will be creating right?

[Flix6x]

Ok, does that mean that in the new schema, we leave them as QuantityField or now use VariableQuantityField.

VariableQuantityField

So I should add them [prefer-curtailing-later, state-of-charge] to the list as well as the new schema I will be creating right?

Yes, please.

[Flix6x]

It's a long list, so please start with a small implementation (preferably even just one field), otherwise I fear the review burden will become too hefty.

[joshuaunity]

For soc-min, which will be in the form of a float, I'm assuming that will also be in MW, so 7 mwh, and I will be converting to kw, right?

[Flix6x]

For soc-min, which will be in the form of a float, I'm assuming that will also be in MW, so 7 mwh, and I will be converting to kw, right?

A few comments:

• Capitalization in units matters. It's MWh and kW.
• We measure soc-min in units of energy (e.g. kWh), not power (e.g. kW)
• Values for the old field (named min_soc_in_mwh) are floats, so e.g. 0.065 and that should be saved under the soc_min flex-model field as "65 kWh".

[joshuaunity]

For soc-min, which will be in the form of a float, I'm assuming that will also be in MW, so 7 mwh, and I will be converting to kw, right?

A few comments:

• Capitalization in units matters. It's MWh and kW.
• We measure soc-min in units of energy (e.g. kWh), not power (e.g. kW)
• Values for the old field (named min_soc_in_mwh) are floats, so e.g. 0.065 and that should be saved under the soc_min flex-model field as "65 kWh".

Thanks for the clarification