Flex model fields from sensors

[Flix6x]

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

Field in flex model	API support since	CLI support since	References
soc-at-start
soc-unit	-	-	not relevant
soc-min
soc-max
soc-minima
soc-maxima
soc-targets
soc-gain	v0.18		#906
soc-usage	v0.18		#906
roundtrip-efficiency
charging-efficiency	v0.18		#933
discharging-efficiency	v0.18		#933
storage-efficiency
prefer-charging-sooner
power-capacity	v0.18		#897
consumption-capacity	v0.18		#897
production-capacity	v0.18		#897

---

Similarly, for flex context fields:

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

[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.

[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.