Allow to show static values and flex-model/context fields in plots

[nhoening]

Right now, our plots can only consist of sensors. Our dashboard model, asset.sensors_to_show, has no ability to include static values.

I see two ways we might want to support:

1. Static values could be entered in the Graphs dialogue freely. We'd only allow a label and a float.
2. The values can be taken from flex-context and flex-model. The latter can actually have both fixed values or sensors, so it would be nice to simply link to a combination of asset and flex-context/model field, and the backend figures out if that includes a fixed value or a sensor. The label is the context/model field name. The dialogue could simply

Work items:

• The sensors_to_show schema would be adapted to allow three new types of entries:
  • {"title": "my plot", "value": 15} (adding the "value" option)
  • {"title": "my plot", "asset": ASSETID, "flex-model": "max-soc"}
  • as above, but for flex-context
• The UI dialogue needs extension (as I wrote, context/model fields might simply come from a list - or we only make selectable the keys that actually exist on the asset context/dialogue, assets also need to come from a dropdown list, which is the lit of accessible assets)
• Update the code to generate charts, so it understand these new options. I would make sure it is robust against failure. Error messages (e.g. the field max-soc is not set on the asset) could even be shown in the console or even a Toast.
• Update the toy tutorial, showing the battery's power capacity on its dashboard (power flow graph), and the site power capacity in the dashboard of the building.

I would rule out model fields which are more complex than fixed value or sensor (e.g. target SoCs, commitments). But they should be added later, same as annotations.

[Flix6x]

Nice! I have a couple of suggestions:

Values should get a unit

So:

{
  "value": "15 kW"
}

Support multiple values per sub-chart

Wouldn't we want the ability to show multiple flex-model fields in a single graph, for instance, both soc-min and soc-max?

Right now we have this:

[
  {"title": "Prices", "sensors": [1, 2]},
  {"title": "Storages", "sensors": [3, 4]}
]

I could imagine the static values would be a list, for instance:

[
  {"title": "Prices", "values": ["10 EUR/MWh", "100 EUR/MWh"], "sensors": [1, 2]},
  {"title": "Storages", "values": [{"asset": 10, "flex-model": "max-soc"}, {"asset": 10, "flex-model": "min-soc"}], "sensors": [3, 4]}
]

Or alternatively, more like variable quantities:

[
  {"title": "Prices", "data": ["10 EUR/MWh", "100 EUR/MWh", {"sensor": 1}, {"sensor": 2}]},
  {"title": "Storages", "data": [{"asset": 10, "flex-model": "max-soc"}, {"asset": 10, "flex-model": "min-soc"}, {"sensor": 3}, {"sensor": 4}]}
]

Values should get a label

For example:

[
    {"title": "Prices", "data": [{"value": "10 EUR/MWh", "label": "Minimum price"}, {"value": "100 EUR/MWh", "label": "Maximum price"}, {"sensor": 1}, {"sensor": 2}]},
]

The labels should be shown in the legend. Maybe together with sensors?

[nhoening]

All good additions!

I find "data" indicates time series, but we only deal with fixed values here. "Fixed values" is also our term in the flex-model and flex-context dialogues.

So this would be the two new kinds of entries I suggest, to be found under "fixed-values" (we can also allow only one under "fixed-value", as we do for "sensor" I believe):

"fixed-values": [
    {"value": "10 EUR/MWh", "label": "Minimum price"},
    {"asset": 10, "flex-model": "min-soc"}
]

[nhoening]

Mh, actually I was thinking only about fixed values there, but to go all the way, the flex-model/flex-context fields that point to sensors should also be usable.

Then, @Flix6x ideas make more sense

[Flix6x]

More implementation suggestions:

1. Start with support for sensor references, because that data already has the structure expected by the chart specs. Could be a separate PR even.
2. Then, support the "label" field, just to override the sensor name shown in the chart.
3. Idea: for each fixed value, let asset.chart_data create a sensor-like JSON object so that the chart specs do not require any changes (or minimal changes in the tooltip). And likewise, create one source-like JSON object that represents the data is defined in the dashboard. Negative sensor/source IDs could be used to let the chart specs match values to sensors/sources. (Clarification: these objects do not live in the db.)

[nhoening]

Hm ... if we support all flex-config (which has both sensors and fixed values), do we really need to let users to add arbitrary fixed values to graphs?

I mean, it could be something we add later, right?
Or do you want that for your own projects?

[Flix6x]

I'm fine with narrowing the scope, but I see hardly any difference, though.

[nhoening]

Supporting the flex-config is the bigger part of the work, true -― but we'd save some work in the UX at least. There would be just two options for the user: lookup any sensor (as it is now) and adding a flex-config field for an asset (#1874 might help to list the relevant assets). We save ourselves the third option (enter any static value).

And we could not do the value/label addition to the schema for now. That also saves some effort.

This is because flex-config fields already have a label we would display,

So I would go for only this new schema version for now:

[
  {
    "title": "Storages",
    "data": [
      {"asset": 10, "flex-model": "soc-max"},
      {"asset": 10, "flex-model": "soc-min"},
      {"asset": 10, "flex-context": "consumption-price"},
      {"sensor": 3},
      {"sensor": 4}
    ]
  }
]

(example would mix units, let's ignore)

So sensors and sensor would move into the data field for current versions of the schema.

[nhoening]

Petition to use the key plots instead of data:

[
  {
    "title": "Storages",
    "plots": [
      {"asset": 10, "flex-model": "soc-max"},
      {"asset": 10, "flex-model": "soc-min"},
      {"asset": 10, "flex-context": "consumption-price"},
      {"sensor": 3},
      {"sensor": 4}
    ]
  }
]

[nhoening]

This idea is now being picked up in this story: #1879

First PR only works on the schema, UI to follow,