What's needed?

We need to make sure we don't leak the internal dependencies to the users, ensuring that we can change the underlying implementation in the future without it being a breaking change.

Proposed solution

• Wrap grpclib errors in some ClientError that will have the underlying grpc error as the cause
• Use a connection string instead of a grpclib.client.Channel

Use cases

No response

Alternatives and workarounds

No response

Additional context

No response

What's needed?

When the client create new channels, it uses a fixed string f"raw-component-data-{component_id}", which means multiple instances of the client will use the same name for channels, which could be confusing/misleading when looking at the logs.

Proposed solution

Add some name to the API client itself so it can be used in the logs too, defaulting to some short hash that will be unlikely match the auto-generated hash of other API client instances.

What's needed?

We are currently testing that some Connections are valid, we should test which are invalid too.

Additional context

• #12 (comment)

What's needed?

Meter and Inverter data types currently don't extract reactive power from the protobuf messages. This needs to be supported.

What's needed?

The SDK is using some symbols directly from the protobuf generated files.

Proposed solution

Wrap it so it can be used from the client instead.

Use cases

• https://github.com/frequenz-floss/frequenz-sdk-python/blob/a31c84506b1a15761308ceb5c982a99d0c3f9948/src/frequenz/sdk/actor/power_distributing/_component_status/_pv_inverter_status_tracker.py#L14-L16
• https://github.com/frequenz-floss/frequenz-sdk-python/blob/a31c84506b1a15761308ceb5c982a99d0c3f9948/src/frequenz/sdk/actor/power_distributing/_component_status/_battery_status_tracker.py#L25-L28
• Maybe more

What's needed?

We need to be able to test examples in the examples directory as part of the CI so we don't break them accidentally (or forget to update them when there are API changes), and allow users to do the same for their apps and actors.

Proposed solution

Create a microgrid mock, or a microgrid API client mock.

The simplest first version should just run an example for few seconds and check if there it didn't crash.

Use cases

No response

Alternatives and workarounds

Test using a real microgrid API, but that would be overkill.

Additional context

No response

What's needed?

Client errors should be easy to catch in a pythonic way, so we should provide one separate error per gRPC status code, at least.

Proposed solution

Add ClientTimeout, RequestCancelled, etc. exceptions inheriting from ClientError.

Additional context

• https://grpc.io/docs/guides/error/