Improvements to sensor/component metrics

[llucax]

This is a proposal for a few, sometimes related, sensor metrics improvements:

1. Remove metrics that include a source in their name
2. Remove the _SENSOR prefix for environmental conditions metrics
3. Rename WIND_SPEED -> VELOCITY
4. Rename WIND_DIRECTION -> ANGLE
5. Rename AIR_PRESSURE -> PRESSURE

We were talking about having a source for sensor metric samples, and unifying Metric/SensorMetric, MetricSample/SensorMetricSample. Once we have this, it seems a bit redundant to have metrics where the source is part of the metric name, for example:

enum Metric {
 // ...

 METRIC_BATTERY_TEMPERATURE = 103;

  // General inverter metrics.
  METRIC_INVERTER_TEMPERATURE = 120;
  METRIC_INVERTER_TEMPERATURE_CABINET = 121;
  METRIC_INVERTER_TEMPERATURE_HEATSINK = 122;
  METRIC_INVERTER_TEMPERATURE_TRANSFORMER = 123;

  // EV charging station metrics.
  METRIC_EV_CHARGER_TEMPERATURE = 140;

  // General sensor metrics
  METRIC_SENSOR_WIND_SPEED = 160;
  METRIC_SENSOR_WIND_DIRECTION = 162;  // Whoops! Gap!
  METRIC_SENSOR_TEMPERATURE = 163;
  METRIC_SENSOR_RELATIVE_HUMIDITY = 164;
  METRIC_SENSOR_DEW_POINT = 165;
  METRIC_SENSOR_AIR_PRESSURE = 166;
  METRIC_SENSOR_IRRADIANCE = 167;
}

Maybe it makes more sense to remove all METRIC_*_TEMPERATURE metrics, and just use METRIC_SENSOR_TEMPERATURE and set the source to the * where it makes sense. For example, if I'm reading METRIC_SENSOR_TEMPERATURE for a Battery component, it is pretty obvious that if there is no source, the source is the battery. But for inverters we can have these sources: CABINET, HEATSINK, TRANSFORMER.

Even more, maybe the _SENSOR prefix is also redundant now, as the temperature doesn't really come from a "sensor component" (for you @tiyash-basu-frequenz 😘 😆 ):

Also, SensorMetric use VELOCITY and ANGLE instead of WIND_SPEED and WIND_DIRECTION. I find the former more general, and the later to also include the source in a way (for a hydro plant maybe there is a water velocity sensor?), so maybe WIND can be the source?

On the same line, SensorMetric uses just PRESSURE while Metric uses AIR_PRESSURE. I also wonder we might need to measure other pressures (water pressure for example). So then AIR would be the source, and we have some overlap here too, as AIR moving is the source for WIND, so we can just have VELOCITY with source=AIR for WIND_SPEED, for example.

Putting it all together, I propose to replace the above snippet with:

enum Metric {
  // ...

  // Environmental metrics
  METRIC_VELOCITY = 160;
  METRIC_ANGLE = 161;
  METRIC_TEMPERATURE = 162;
  METRIC_RELATIVE_HUMIDITY = 163;
  METRIC_DEW_POINT = 164;
  METRIC_PRESSURE = 165;
  METRIC_IRRADIANCE = 166;
}

And leave all the specifics to sources. We might want to then standardize sources, maybe having source as something like:

enum MetricSource {
    METRIC_SOURCE_AIR = 1;
    METRIC_SOURCE_WATER = 2;
    METRIC_SOURCE_CABINET = 3;
    METRIC_SOURCE_HEATSINK = 4;
    METRIC_SOURCE_TRANSFORMER = 5;
    // etc.
}

message MetricSampleSource {
  oneof kind {
      MetricSource predefined;
      string custom;
  }
}

message MetricSample {
  // ...
  MetricSampleSource source;
}

So we can have some standard, well-known sources, otherwise it could get a bit messy if different people start using different names fro well-known sources.

[llucax]

Not sure if MetricSampleSource should allow for both predefined and custom, in case you want more specificity for a predefined source, like: AIR+"roof" and AIR+"ground" or something like that, or even to be able to combine predefined, like AIR, CABINET.

Something like:

message MetricSampleSource {
  repeated MetricSource predefined;
  string custom;
}

But not sure if it doesn't get too complicated.

[cwasicki]

Also, SensorMetric use VELOCITY and ANGLE instead of WIND_SPEED and WIND_DIRECTION

Note that for wind this is the standard meteorological terminology.