Skip to content

Conversation

llucax
Copy link
Contributor

@llucax llucax commented Oct 16, 2025

This is a WIP PR, it still needs a lot of cleaning up, but all tests should be passing (minus pylint because I added a few FIXME/TODOs.

This PR is mostly created for having early feedback, and to allow doing some experiments to see how this works in the real world before start cleaning it up. It probably makes more sense to look at the resulting File Changes than going commit by commit at this stage.

@shsms FYI.

@github-actions github-actions bot added part:docs Affects the documentation part:tests Affects the unit, integration and performance (benchmarks) tests part:tooling Affects the development tooling (CI, deployment, dependency management, etc.) part:data-pipeline Affects the data pipeline part:microgrid Affects the interactions with the microgrid labels Oct 16, 2025
This introduces the new microgrid API v0.18.

Signed-off-by: Leandro Lucarella <[email protected]>
Signed-off-by: Leandro Lucarella <[email protected]>
The microgrid API now doesn't support not reporting a rated fuse for a
grid connection, so we don't need to test for that case anymore.

Signed-off-by: Leandro Lucarella <[email protected]>
This introduces the new microgrid API v0.17.

Signed-off-by: Leandro Lucarella <[email protected]>
The battery pool bounds calculation is buggy and these tests are wrong
(see frequenz-floss#1180).
By switching to using ranges of bounds, the buggy behaviour changes and
make these tests fail.

Fixing them is difficult without switching to using ranges natively
first, so we just skip these tests for now.

Signed-off-by: Leandro Lucarella <[email protected]>
@llucax llucax force-pushed the microgrid-api-0.18 branch from 60cf5b2 to a996c07 Compare October 16, 2025 12:52
Copy link
Contributor Author

@llucax llucax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these are all the TODOs/FIXMEs I wrote when doing the update. It would be good to get some feedback.

Comment on lines +110 to +111
# FIXME: This might not be true forever, but the service for now seems to send
# all metrics with the same timestamp for now.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this one can be removed, at least IIRC @tiyash-basu-frequenz confirmed this was going to be like this for the time being. In any case, this is a temporary transitional module, at some point we should start using the telemetry messages as they come from the API.

if not samples.states:
return class_(component_id=samples.component_id, timestamp=timestamp)

# FIXME: Maybe we can have more than one, in which case we need to merge them?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @tiyash-basu-frequenz also confirmed this was fine for now, but I don't remember if the idea is that more than one could come in the future.

Comment on lines +211 to +215
# FIXME: All of this have now a default of 0.0 because this is what it was done when
# we used the API v0.15, as we accessed the fields without checking if the fields
# really existed, so the defaul protobuf value of 0.0 for floats was used.
# We might beed to review this and if they are not present interpret them as None
# instea.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is tricky, I guess we can leave it as it is now and will have to come back to it forcibly when removing this temporary adaption layer.

Comment on lines +495 to +497
# FIXME: We assume only one range is present
# If one bound is None, we assume 0 to match the previous
# behavior of v0.15, but this should eventually be fixed
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we'll also fix this when removing this adaption layer, not sure if it is worth adding a separate issue for this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can disable pylint fixme check for this entire module and keep the FIXMEs as they are now to remember to address these issues when removing this adaption layer.

Comment on lines +1102 to +1110
# Old code:
# return self.component_state not in (
# EVChargerComponentState.AUTHORIZATION_REJECTED,
# EVChargerComponentState.ERROR,
# ) and self.cable_state in (
# EVChargerCableState.EV_LOCKED,
# EVChargerCableState.EV_PLUGGED,
# )
# TODO: Verify this logic is correct
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you can check this @shsms ?

component.id
for component in component_graph.predecessors(battery_id)
if component.category == ComponentCategory.INVERTER
# TODO: Shouldn't this be (SolarInverter, HybridInverter)?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shsms ? Maybe it is better to create a separate issue anyways as this was a pre-existing issue.

Comment on lines +374 to +375
# TODO: This was using ErrorLevel.CRITICAL to see if an error was critical or
# warning. I guess now we use the separate errors and warnings fields.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you have a look at this one too @shsms ?

Comment on lines +597 to +604
# TODO: This is old validation logic, which should probably be removed
if component.id == ComponentId(0) and not isinstance(
component, GridConnectionPoint
):
issues.append(
"Component with ID 0 should be a GridConnectionPoint, "
f"but it is a {component!r} instead."
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this check is safe to remove. I only found a previous check in an unused method _correct_graph_errors, removed in 635914c. I think I wrote this code before committing that removal.

FYI @tiyash-basu-frequenz @shsms @ela-kotulska-frequenz, I will remove this check unless someone complains.

Comment on lines +256 to +258
# TODO: This code is unreacheable, as T can't be None. We need to
# figure out which case this was supposed to handle. Maybe we need
# some sentinel value or to allow None in T.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shsms maybe you can check this one?

@llucax llucax self-assigned this Oct 16, 2025
@llucax llucax moved this from To do to In progress in Python SDK Roadmap Oct 16, 2025
@llucax llucax added this to the v1.0.0-rc2200 milestone Oct 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

part:data-pipeline Affects the data pipeline part:docs Affects the documentation part:microgrid Affects the interactions with the microgrid part:tests Affects the unit, integration and performance (benchmarks) tests part:tooling Affects the development tooling (CI, deployment, dependency management, etc.)

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

1 participant