Flex model fields from sensors

[Flix6x]

This serves as a page to track compatibility of sensor cross-referencing in API, CLI and UI flex model fields. That is, which fields already support pointing to a sensor:

Field in flex model	API support since	CLI support since	UI support since	References
soc-at-start / state-of-charge	v0.32.0	v0.32.0	v0.32.0	#1429, #2026 1
soc-unit	-	-	-	not relevant
soc-min			v0.29.0	#989, #1429
soc-max			v0.29.0	#989, #1429
soc-minima	v0.20		v0.29.0	#996, #1002
soc-maxima	v0.20		v0.29.0	#996, #1002
soc-targets	v0.20		v0.29.0	#996, #1002, #1429
soc-gain	v0.18	v0.19	v0.29.0	#906, #966, #1429
soc-usage	v0.18	v0.19	v0.29.0	#906, #966, #1429
roundtrip-efficiency	-	-	-	not planned
charging-efficiency	v0.18	v0.19	v0.29.0	#933, #966, #1429
discharging-efficiency	v0.18	v0.19	v0.29.0	#933, #966, #1429
storage-efficiency		v0.19	v0.29.0	#966, #1429
prefer-charging-sooner	-	-	-	not planned
power-capacity	v0.18.2	v0.19.1	v0.29.0	#897, #966, #984, #1429
consumption-capacity	v0.18	v0.19	v0.29.0	#897, #966, #1429
production-capacity	v0.18	v0.19	v0.29.0	#897, #966, #1429

---

Similarly, for flex context fields:

Field in flex context	API support since	CLI support since	References
consumption-price-sensor	v0.11	v0.11	#451 2
production-price-sensor	v0.11	v0.11	#451 2
inflexible-device-sensors	v0.11	v0.13	#451, #534 2
site-power-capacity	v0.20	v0.20	#985
site-production-capacity	v0.20	v0.20	#985
site-consumption-capacity	v0.20	v0.20	#985

Footnotes

1. If the soc-at-start is used, the state-of-charge sensor reference is only used to store the scheduled SoC. If soc-at-start is left out, the state-of-charge sensor is also used to infer the starting SoC. ↩

2. The current syntax used by ...-sensor flex-context fields differs from flex-model fields, because they use the SensorIdField schema rather than the QuantityOrSensor schema. For example: consumption-price-sensor: 1 as opposed to charging-efficiency: {sensor: 2}. ↩ ↩² ↩³

[nhoening]

I'd be interested to see whether we support these fields on asset or sensor attributes. That is a goal we should pursue.

Also, this could also become a discussion.

[nhoening]

@Flix6x @victorgarcia98 I guess my idea isn't really about this discussion, but this list is a great starting point to get that done, as well. Should that simply become an issue, in which I link to this list here?

Also, I can use this list in my ongoing documentation effort in #953 ! :-)

[nhoening]

Has been made into discussion #990

[victorgarcia98]

Nice, thanks for compiling this list!

What fields should we implement first?

IMO:

• soc-maxima
• soc-minima
• soc-at-start

[Flix6x]

What fields should we implement first?

• I'd start with storage-efficiency, as this is usually very much dependent on ambient temperature, and is important in the context of heat modelling.
• Then I'd treat soc-maxima, soc-minima and soc-targets as one ticket, as they are very similar.
• The soc-at-start is a bit more tricky, because it is somewhat entangled with the concept of the schedule's start time. But yes, it would be next.

I imagine that after the implementation of soc-maxima and soc-minima as sensors, there is no longer any need to be able to implement soc-max and soc-min as sensors, too. If you agree, I'll add notes to the table, accordingly.

[victorgarcia98]

I agree, it's pretty reasonable. The other group of fields that are interesting are the site level power constraints.

[Flix6x]

Also, we should start after (or based on) #899 to avoid the extra overhead of merge conflicts.