Add a way to determine if a meter can have a hidden connection

[llucax]

What's needed?

When reading electrical data from the microgrid, we rely mostly on meters and inverters. It is very common that inverters even have a meter in front of them as they provide more reliable data. In those cases one can use the inverter as a fallback way to get data in cases where the meter is not working. There are cases where we even have a component connected to a meter but for technical reasons there is no way to measure the component (like a PV inverter), but we can read it indirectly via a meter.

The problem is a meter can have connections to other electrical components (like a load) that is not represented in the component graph, and if that is the case, we can't rely anymore on the meter to either be a proxy for some other phantom/virtual component or an unknown load.

To solve this, we need a way to determine a meter is only connected to its children nodes or if there could be phantom/hidden/virtual connection that is not represented in the component graph, so we can know how we can use that meter and what is it metering exactly.

Proposed solution

The proposed solution is to add a metadata Meter message with a bool field to tell if there is (or could be) a hidden connection or if it is guaranteed that all connections to the meter are represented in the component graph. For example:

// Frequenz definitions for transformers.
//
// Copyright:
// Copyright 2024 Frequenz Energy-as-a-Service GmbH
//
// License:
// MIT

syntax = "proto3";

package frequenz.api.common.v1.microgrid.components;

// TODO: Docs
message Meter {
  // Wether this meter has hidden connections.
  //
  // Hidden connections are connections that are not represented
  // in the component graph. For example, if a consumer load is
  // connected to the meter.
  bool has_hidden_connection = 1;
}

diff --git a/proto/frequenz/api/common/v1/microgrid/components/components.proto b/proto/frequenz/api/common/v1/microgrid/components/components.proto
index c21251d..bfca30b 100644
--- a/proto/frequenz/api/common/v1/microgrid/components/components.proto
+++ b/proto/frequenz/api/common/v1/microgrid/components/components.proto
@@ -17,6 +17,7 @@ import "frequenz/api/common/v1/microgrid/components/ev_charger.proto";
 import "frequenz/api/common/v1/microgrid/components/fuse.proto";
 import "frequenz/api/common/v1/microgrid/components/grid.proto";
 import "frequenz/api/common/v1/microgrid/components/inverter.proto";
+import "frequenz/api/common/v1/microgrid/components/meter.proto";
 import "frequenz/api/common/v1/microgrid/components/transformer.proto";
 import "frequenz/api/common/v1/microgrid/lifetime.proto";
 
@@ -96,6 +97,7 @@ message ComponentCategoryMetadataVariant {
     frequenz.api.common.v1.microgrid.components.Inverter inverter = 5;
     frequenz.api.common.v1.microgrid.components.VoltageTransformer
       voltage_transformer = 6;
+    frequenz.api.common.v1.microgrid.components.Meter meter = 7;
   }
 }
 

Use cases

No response

Alternatives and workarounds

No response

Additional context

Other issues related to supporting this use case:

• Support for disabling fallback components frequenz-sdk-python#1072
• Provide ability to extend or replace the component graph frequenz-sdk-python#1073

[tiyash-basu-frequenz]

I would like to propose another potential solution - we can just add a "virtual" meter to the component graph. This has a few advantages to the proposal above:

• It does not need any API change.
• We already use "virtual" components, e.g., PV inverters, or CHPs, etc, to which we do not have data connections. We could use the same approach here, because like, say, a virtual inverter, the load exists, but the corresponding meter is missing, or we do not have a data connection to it. This will keep things more consistent.

However, if we really want to follow the proposal mentioned in the issue description, then we could get replace all virtual components with meter metadata fields, again for consistency.

[llucax]

Also for cross-referencing, the #246 also touches on the point of metadata vs components in the component graph.

I also feel like having a more representative component graph sounds cleaner and less hacky.

[tiyash-basu-frequenz]

Marking this blocked for now, until we stabilize the requirement in discussions.

[tiyash-basu-frequenz]

We discussed that we do not need to consider meters having hidden connections. Client app algorithms should be able to adapt to anomalous meter readings.