Skip to content

Sync ElectricalComponent with the protobuf message#216

Merged
llucax merged 5 commits into
frequenz-floss:v0.x.xfrom
llucax:sync-electrical-comp
Jun 17, 2026
Merged

Sync ElectricalComponent with the protobuf message#216
llucax merged 5 commits into
frequenz-floss:v0.x.xfrom
llucax:sync-electrical-comp

Conversation

@llucax

@llucax llucax commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

The protobuf have a few new and deprecated fields and one existing field had a name that doesn't match the protobuf name, which could lead to confusion.

Since this code is new, we completely remove the deprecated fields.

Part of #203.

@llucax llucax requested a review from a team as a code owner June 16, 2026 10:38
@llucax llucax requested review from florian-wagner-frequenz and removed request for a team June 16, 2026 10:38
@github-actions github-actions Bot added part:tests Affects the unit, integration and performance (benchmarks) tests part:tooling Affects the development tooling (CI, deployment, dependency management, etc.) part:microgrid Affects the microgrid protobuf definitions labels Jun 16, 2026
@llucax llucax added the cmd:skip-release-notes It is not necessary to update release notes for this PR label Jun 16, 2026
@llucax llucax enabled auto-merge June 16, 2026 10:39
@llucax llucax self-assigned this Jun 16, 2026
@llucax llucax changed the title Rename and add missing electrical component fields Sync ElectricalComponent with the protobuf message Jun 16, 2026
@llucax

llucax commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

@tiyash-basu-frequenz I guess the new "model" field should be working by now and there is no need to keep the old "manufacturer" and "model_name" fields, right? Or should I leave them as deprecated as they are in the protobuf?

@llucax llucax force-pushed the sync-electrical-comp branch 2 times, most recently from af2033f to a7f6353 Compare June 16, 2026 10:55
@llucax llucax added this to the v0.4.1 milestone Jun 16, 2026
@tiyash-basu-frequenz

Copy link
Copy Markdown

@tiyash-basu-frequenz I guess the new "model" field should be working by now and there is no need to keep the old "manufacturer" and "model_name" fields, right? Or should I leave them as deprecated as they are in the protobuf?

The new field is indeed working now.

The protobuf `ElectricalComponent` message has an `operational_mode` field
typed as the `ElectricalComponentOperationalMode` enum, but the wrapper had
no equivalent enum. Add the enum wrapper together with its `v1alpha8`
`*_from_proto`/`*_to_proto` converters and parity test, following the
existing enum conventions.

This is a prerequisite for exposing the `ElectricalComponent.operational_mode`
field in a follow-up commit.

Signed-off-by: Leandro Lucarella <luca-frequenz@llucax.com>
@llucax llucax force-pushed the sync-electrical-comp branch from a7f6353 to 08193a2 Compare June 16, 2026 19:53
@llucax

llucax commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

Great. Rebased with resolved conflicts.

llucax added 4 commits June 17, 2026 09:14
The protobuf `ElectricalComponent` message has an `operational_mode` field
(number 10) that was neither exposed on the wrapper nor read by the converter,
losing data.

Expose it as `ElectricalComponent.operational_mode` (defaulting to
`UNSPECIFIED`) and populate it in `_ElectricalComponentBaseData` and every
constructed component subclass.

Signed-off-by: Leandro Lucarella <luca-frequenz@llucax.com>
The protobuf `ElectricalComponent` message has a `model` field (number 11)
that was neither exposed on the wrapper nor read by the converter, losing
data. This field is the non-deprecated replacement for `manufacturer` and
`model_name`, so it is the most important of the three going forward.

Expose it as `ElectricalComponent.model` and populate it in
`_ElectricalComponentBaseData` and every constructed component subclass.

Signed-off-by: Leandro Lucarella <luca-frequenz@llucax.com>
The wrapper field for the protobuf `metric_config_bounds` was named
`rated_bounds`, which narrows the meaning. The proto describes configuration
bounds that may be derived from the component configuration, manufacturer
limits, or limits of other devices, not just rated limits.

Rename the public `ElectricalComponent.rated_bounds` field (and the internal
base-data plumbing and tests) to `metric_config_bounds` to match the protobuf
semantics. The repeated-message-to-mapping conversion is unchanged.

Signed-off-by: Leandro Lucarella <luca-frequenz@llucax.com>
Remove the deprecated wrapper fields that were superseded by the kept
`model` field in unreleased code.

Signed-off-by: Leandro Lucarella <luca-frequenz@llucax.com>
@llucax llucax force-pushed the sync-electrical-comp branch from 08193a2 to d9d325f Compare June 17, 2026 07:15
@llucax llucax added this pull request to the merge queue Jun 17, 2026
Merged via the queue into frequenz-floss:v0.x.x with commit d988ee9 Jun 17, 2026
9 checks passed
@llucax llucax deleted the sync-electrical-comp branch June 17, 2026 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cmd:skip-release-notes It is not necessary to update release notes for this PR part:microgrid Affects the microgrid protobuf definitions part:tests Affects the unit, integration and performance (benchmarks) tests part:tooling Affects the development tooling (CI, deployment, dependency management, etc.)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants