Moving the power distributor as part of a BatteryPool

[leandro-lucarella-frequenz]

Think about moving the power distributor as part of a BatteryPool object proposed in the new design. So power requests can be done to a particular pool.

[ela-kotulska-frequenz]

BatteryPool could have set_power method to charge/discharge batteries. And this method should use PowerDistributor.

But PowerDistributor should be separate instace because there would be many BatteryPool instances in Microgrid, but only one PowerDistributor and PowerManagerActor.

We would have only one instance of PowerDistributor/PowerManager because it should coordinate power set between many use-case actors.

[leandro-lucarella-frequenz]

Yeah, I was wondering if we should have a generic ComponentPoolAggregatingActor (*) actor that can manage all the pools of all (appropriate) component category type, so we can say something like (these would actually be control messages for the actor but using function call syntax for simplicity: pool_id = aggregator.create(BATTERY, battery_id_1, battery_id_2, battery_id_3) and then say aggregator.subscribe(BATTERY, pool_id, METRIC_ID).

So all pools will be global to the system.

Then we can have a BatteryPool class that just acts as a ComponentPoolAggregatingActor and a PowerDistributingActor client, so we can create it with BatteryPool(pool_id) and then say pool.subscribe(METRIC_ID) or pool.charge(power) and it will do its magic sending messages to the actors.

I'm not sure how we will send pool_ids around, but if we sort that out I think it can make the interface for users super lean. And the underlying implementation pretty well decoupled between reporting and control, and global to the system.

(*) Generic because I think the code will be the same for any component category that we want to put in pools.

Maybe something to discuss in the SDK devs meeting.

[leandro-lucarella-frequenz]

So we discard the idea to have a an actor that can handle more than one component category because each component category has their own particularities and will use more than one component category. For example a battery is not only a battery, it also needs to operate an inverter; for EV chargers, the pool should also take into account if there is a meter in front of the EV charger and use that instead of the EV charger.

[leandro-lucarella-frequenz]

We still have to figure out if different battery pools can share batteries. On a quick view it look like they shouldn't, but if we have a power manager that will have the last saying on how batteries are used, we might be able to share batteries between different pools.

We don't need to decide this right now as we don't have yet use cases for different pools, but is something to have in mind, and if we have a restriction one way or the other it can really affect the design of a battery pool (if we can't share batteries, then we need a global view of the battery pools for the whole system, otherwise creating pools can be done locally, by a use case actor for example).

[leandro-lucarella-frequenz]

@ela-kotulska-frequenz if I recall correctly, this is not going to happen, right? The power distributor will still exist but as a more low-level interface and the battery pool will use it?

Can you please write a new comment if there is a conclusion and mark it as answer?

[ela-kotulska-frequenz]

Summary of long term discussion:

1. BatteryPool will be global and will exist in the SDKInterface. User would ask for the batteryPool liek this:

      sdk.register(host, post)
      pool = sdk.battery_pool(battery_ids: Set[int])

If battery_pool for this set of components is existing, then sdk will return the battery pool (so it can be reused by different actor). If battery pool doesn't exist, then sdk will create it.
More examples can be found here: https://github.com/frequenz-io/frequenz-apps-draft

2. For now it won't be possible to send power command using the BatteryPool. We decided that because we will soon have PowerManager and the whole interface for sending power commands will change. We will add support for sending power commands in the BatteryPool after PowerManager is implemented.

We still have to figure out if different battery pools can share batteries.

Yes, they can. :( In this case PowerManager should solve the conficts.

I recall correctly, this is not going to happen, right? The power distributor will still exist but as a more low-level interface and the battery pool will use it?

Yes, exactly. :) But not in the direct way. BatteryPool will use PowerManager. And PowerManager will use PowerDistributor. PowerDistributor will be invisible for the user. However this is feature after we have PowerManager

[leandro-lucarella-frequenz]

(copied from @ela-kotulska-frequenz answer in a comment so I can mark it as the answer)

Summary of long term discussion:

1. BatteryPool will be global and will exist in the SDKInterface. User would ask for the batteryPool liek this:

      sdk.register(host, post)
      pool = sdk.battery_pool(battery_ids: Set[int])

If battery_pool for this set of components is existing, then sdk will return the battery pool (so it can be reused by different actor). If battery pool doesn't exist, then sdk will create it.
More examples can be found here: https://github.com/frequenz-io/frequenz-apps-draft

2. For now it won't be possible to send power command using the BatteryPool. We decided that because we will soon have PowerManager and the whole interface for sending power commands will change. We will add support for sending power commands in the BatteryPool after PowerManager is implemented.

We still have to figure out if different battery pools can share batteries.

Yes, they can. :( In this case PowerManager should solve the conficts.

I recall correctly, this is not going to happen, right? The power distributor will still exist but as a more low-level interface and the battery pool will use it?

Yes, exactly. :) But not in the direct way. BatteryPool will use PowerManager. And PowerManager will use PowerDistributor. PowerDistributor will be invisible for the user. However this is feature after we have PowerManager