Long sensor names reveal a need to model how sensors are grouped within assets

[Flix6x]

@ArdJonker suggested to move part of our y-axis label to the chart title, because the labels can be quite lengthy with respect to the chart height. For example:

The y-axis label is currently made up of 2 components:

• The sensor name, capitalized
• The sensor unit, in parentheses

For example: Wind speed (m/s).

However, in practice, I've seen the sensor name used to contain more information than just the physical quantity, because we lack a data model to describe asset subgrouping. For example, I've seen Steam flow dryer 1 (t/h) and Nissan Leaf battery state of charge (%). In these cases, it would be preferable to use the sensor name only for holding the physical quantity (steam flow and state of charge, respectively), and moving the remainder (dryer 1 and Nissan Leaf battery, respectively) to some separate data model or attribute. When these characteristics are treated as separate data:

• it will become more straightforward to show things like a single chart plotting steam flow over time for both dryer 1 and 2
• y-axis labels will become shorter

I suggest:

• increasing the default chart height for vertically concatenated charts
• implementing a data model to hold sensor groupings within an asset, for example, a new asset attribute describing the sensor groupings, such as:

  {
      "house": {
          "solar panels": [4, 5],
          "other": [14],
          "charge point": {
              "EVSE 1": [16, 19, 33],
              "EVSE 2": [23, 63, 35],
              "EV 1": [83],
              "EV 2": [84],
              "EV 3": [85]
          },
          "energy contract": [1]
      }
  }
  

• adding documentation explaining what should be considered a good sensor name to use in FlexMeasures:
  • good: wind speed
  • good: energy price
  • good: state of charge
  • bad: steam flow dryer 1 -> instead, create a sensor named steam flow and a sensor grouping named dryer 1
  • bad: day-ahead prices -> instead, create a sensor named energy price and a sensor grouping named day-ahead market
  • bad: Nissan Leaf battery power -> instead create a sensor named power output and a sensor grouping named Nissan Leaf battery