New microgrid logical components and the role of logical_meter

[llucax]

We have a proposal to add more logical components, as we have with battery_pool and grid, so metrics are grouped in namespaces more naturally.

The idea is to move metrics like consumer_power and producer_power to microgrid.consumer.power and microgrid.producer.power.

At the end all logical components exposed via the microgrid namespace can potentially offer the full set of metrics a meter could offer (current, power, voltage, etc.).

This leaves the current logical_meter() sort of empty. But users should be able to make their own logical meters by applying formulas. Just to put an early example, it could be something like my_measure = microgrid.logical_meter("some + formula").

[llucax]

Related to this, I think we should think a bit more and make more explicit when we are creating new objects and when we are just returning a singleton.

• grid and logical_meter now return a singleton, so they could be properties instead to make this very clear.
• xxx_pool are really creating new objects (even when they might return a pre-existing cached object), so they should stay a function.
• If we change logical_meter to return a new object to create new formulas, then it should stay a function.

For functions, I think we should rename them new_xxx_pool(), specially now that the battery_pool() is taking a name instead of a UUID, so each time the function is called the instantiated BatteryPool will have a different source_id.

It makes it super clear that if you want to use the same battery pool in different places you need to save the object instead of calling battery_pool("my_battery_pool") multiple times.

[llucax]

ping @frequenz-floss/python-sdk-team

[llucax]

consumer and producer done.

Follow-up issues:

• Rename xxx_pool() functions to new_xxx_pool() #915
• Make consumer, producer and grid properties #973

[llucax]

The question about if logical_meter should be converted to something else, removed or kept as-is is still open.