Skip to content

Add mechanism to fetch tags associated with metric/component data #207

Open
@tiyash-basu-frequenz

Description

@tiyash-basu-frequenz

What's needed?

We need a mechanism to fetch tags associated with metric/component data while reading from our APIs. Such tags are represented by arbitrary payloads (JSONs) that have a one-to-one relation with sample timestamp.

This could be used to indicate the last activity or last command that was issued to an API, e.g., a charge command to the Dispatch API or Microgrid API. (such tags could be set on these APIs through their own RPCs).

As of now, the tag is intended to be present in only one outgoing data sample, and not in the succesive data samples.

Proposed solution

Solution 1

One way of doing this would be to add a tag field in the MetricSample message. This field would store a JSON to be able to represent arbotrary payloads:

google.protobuf.Struct tag = 6;

(also, suggesting tag as the field name because "payload" would generally refer to the whole message, so could be confusing in this context)

This would also affect the contents ComponentData message. If this solution is accepted, then the message would look like the following:

{
  "component_id": 13,
  "metric_samples": [
    {
      "sampled_at": "2023-10-01T00:00:00Z",
      "tag": { "command_issued_by": "dispatch_actor_123" },
      "metric": "DC_VOLTAGE",
      "sample": {},
      "bounds": {}
    },
    {
      "sampled_at": "2023-10-01T00:00:00Z",
      "tag": { "command_issued_by": "dispatch_actor_123" },
      "metric": "DC_CURRENT",
      "sample": {},
      "bounds": {}
    },
    {
      "sampled_at": "2023-10-01T00:00:01Z",
      "tag": { "command_issued_by": "dispatch_actor_123" },
      "metric": "DC_VOLTAGE_V",
      "sample": {},
      "bounds": {}
    },
    {
      "sampled_at": "2023-10-01T00:00:01Z",
      "tag": { "command_issued_by": "dispatch_actor_123" },
      "metric": "DC_CURRENT",
      "sample": {},
      "bounds": {}
    }
  ],
  "states": [
    {
      "sampled_at": "2023-10-01T00:00:00Z",
      "tag": { "command_issued_by": "dispatch_actor_123" },
      "states": [],
      "warnings": [],
      "errors": []
    },
    {
      "sampled_at": "2023-10-01T00:00:01Z",
      "tag": { "command_issued_by": "dispatch_actor_123" },
      "states": [],
      "warnings": [],
      "errors": []
    }
  ]
}

One downside of this solution is that we replicate the tag multiple times for each metric, given the way we have organize the data structure.

Solution 2

Similar to solution1, but structured a bit differently:

{
  "component_id": 13,
  "tags": [
    {"sampled_at": "2023-10-01T00:00:00Z", "tag": { "command_issued_by": "dispatch_actor_123" }},
    {"sampled_at": "2023-10-01T00:00:01Z", "tag": { "command_issued_by": "dispatch_actor_123" }}
  ],
  "metric_samples": [
    {
      "sampled_at": "2023-10-01T00:00:00Z",
      "metric": "DC_VOLTAGE",
      "sample": {},
      "bounds": {}
    },
    {
      "sampled_at": "2023-10-01T00:00:00Z",
      "metric": "DC_CURRENT",
      "sample": {},
      "bounds": {}
    },
    {
      "sampled_at": "2023-10-01T00:00:01Z",
      "metric": "DC_VOLTAGE_V",
      "sample": {},
      "bounds": {}
    },
    {
      "sampled_at": "2023-10-01T00:00:01Z",
      "metric": "DC_CURRENT",
      "sample": {},
      "bounds": {}
    }
  ],
  "states": [
    {
      "sampled_at": "2023-10-01T00:00:00Z",
      "states": [],
      "warnings": [],
      "errors": []
    },
    {
      "sampled_at": "2023-10-01T00:00:01Z",
      "states": [],
      "warnings": [],
      "errors": []
    }
  ]
}

This would need a protobuf message:

message SampleTimestampTag {
    google.protobuf.Timestamp sampled_at = 1;
    google.protobuf.Struct tag = 2;
}

Use cases

In addition to the broader use-case of tagging inverter activity, there are some cases where the AC electricity data is not enough to identify what's going on. E.g., in case of the FCR app, this could help determine working-point-offset (assuming the app uses it properly). In this example, obtaining the working-point-offset just from AC data would be difficult, if not impossible.

Alternatives and workarounds

No response

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    part:❓We need to figure out which part is affectedpriority:❓We need to figure out how soon this should be addressedtype:enhancementNew feature or enhancement visitble to users

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions