Add a new variant Meter to ElectricalComponentCategorySpecificInfo

[tiyash-basu-frequenz]

This commit introduces a new message Meter to the v1alpha8 package, which encapsulates static information about meters in a microgrid. Additionally, the ElectricalComponentCategorySpecificInfo enum has been extended to include the Meter variant. This enhancement enables the representation of meter-specific information within a microgrid.

[Copilot]

Pull Request Overview

This PR adds support for meters in the microgrid electrical components API by introducing a new Meter message type and extending the existing component categorization system.

• Introduces a new Meter message with polarity reversal configuration
• Extends ElectricalComponentCategorySpecificInfo enum to include the new Meter variant
• Updates release notes to document the new meter functionality

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
electrical_components.proto	Adds new Meter message type and extends enum with meter variant
RELEASE_NOTES.md	Documents the new meter features in the release notes

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[llucax]

LGTM, only comment is it looks a bit like a negative saying "polarity reversed". I wonder if it would make more sense/be more extensible, if we have maybe a enum instead, like SignConvention with PASSIVE and ACTIVE.

When bouncing with Gemini, it agreed the enum is more robust but took it further and suggested PASSIVE, REVERSED_PASSIVE and ACTIVE, saying even if reversed passive and active are the same intent matter. I'm not so sure, but mentioning in case you can think of cases where differentiating both can make a difference.

In any case, this is just food for thought, I know in practice probably the enum works as well. But I thought throwing it out there in case anyone can think of more reasons to really prefer an enum in the long term.

FYI @shsms

[llucax]

When challenging Gemini about the need for both it said (among other things):

The difference in intent becomes critical for everything around that simple calculation: operations, maintenance, and risk management. Treating a mistake the same as a correct configuration introduces hidden risks that can cause serious problems down the line.

Think of the REVERSED_PASSIVE state as a "Check Engine" light for your meter. The car still drives, but the light tells you there's an underlying issue that needs to be tracked and eventually fixed.

So I guess for the UI/people on the other side of the SDK it could be valuable information, if there is really a conceptual difference between both.

[tiyash-basu-frequenz]

@llucax thanks for the review. We are thinking about other ways to do this, which do not involve other ways to add this information to this API.

I will update the PR according to what we eventually agree upon.

[tiyash-basu-frequenz]

We have successfully agreed upon an alternate solution. This PR s not needed anymore.