Index

frequenz.sdk.microgrid

A microgrid is a local electrical grid that connects a set of electrical components together. They are often built around a passive power consumer, to supplement the electricity consumed from the public grid with on-site power generation or storage systems.

Microgrids can also function in island-mode, without a grid connection, or without a local power consumer, but they have to have at least one of the two, to be meaningful.

Frequenz SDK Microgrid Model

The SDK aims to provide an abstract model of the microgrid that enables high-level interactions with microgrid components, without having to worry about (or even be aware of) location-specific details such as:

• where the meters are placed,
• how many batteries,
• whether there's a grid connection or a passive consumer,
• what models the inverters are, etc.
• whether components are having downtimes, because metrics and limits get adjusted automatically when components are having downtimes.

Users of the SDK can develop applications around this interface once and deploy anywhere, and the SDK will take care of translating the requests and instructions to correspond to the specific microgrid configurations.

flowchart LR

subgraph Left[Measurements only]
direction LR
  grid["Grid Connection Point"]
  consumer["Consumer"]
  pv["PV Arrays"]
  chp["CHP"]
end

junction(( ))

subgraph Right[Measurements and control]
direction LR
  bat["Batteries"]
  ev["EV Chargers"]
end

grid --- junction
consumer --- junction
pv --- junction
chp --- junction

junction --- bat
junction --- ev

Grid

This refers to a microgrid's grid-connection-point. The power flowing through this connection can be streamed through grid_power.

In locations without a grid connection point, this method remains accessible, and streams zero values.

Consumer

This is the main power consumer at the site of a microgrid, and often the load the microgrid is built to support. The power drawn by the consumer is available through consumer_power

In locations without a consumer, this method streams zero values.

Producers: PV Arrays, CHP

The total CHP production in a site can be streamed through chp_power. PV Power is available through the PV pool described below. And total producer power is available through microgrid.producer().power.

As is the case with the other methods, if PV Arrays or CHPs are not available in a microgrid, the corresponding methods stream zero values.

PV Arrays

The total PV power production is available through pv_pool's power. The PV pool by default uses all PV inverters available at a location, but PV pool instances can be created for subsets of PV inverters if necessary, by specifying the inverter ids.

The pv_pool also provides available power bounds through the power_status method.

The pv_pool also provides a control method propose_power, which accepts values in the Passive Sign Convention and supports only production.

Batteries

The total Battery power is available through the battery_pool's power. The battery pool by default uses all batteries available at a location, but battery pool instances can be created for subsets of batteries if necessary, by specifying the battery ids.

The battery_pool also provides soc, capacity, temperature and available power bounds through the power_status method.

The battery_pool also provides control methods propose_power (which accepts values in the Passive Sign Convention and supports both charging and discharging), or through propose_charge, or propose_discharge.

EV Chargers

The ev_charger_pool offers a power method that streams the total power measured for all the EV Chargers at a site.

The ev_charger_pool also provides available power bounds through the power_status method.

The ev_charger_pool also provides a control method propose_power, which accepts values in the Passive Sign Convention and supports only charging.

Component pools

The SDK provides a unified interface for interacting with sets of Batteries, EV chargers and PV arrays, through their corresponding Pools.

• Battery pool
• EV charger pool
• PV pool

All of them provide support for streaming aggregated data and for setting the power values of the components.

Streaming component data

All pools have a power property, which is a Formula that can

• provide a stream of resampled power values, which correspond to the sum of the power measured from all the components in the pool together.

• be composed with other power streams to for composite formulas.

In addition, the battery pool has some additional properties that can be used as streams for metrics specific to batteries: soc, capacity and temperature.

Setting power

All pools provide a propose_power method for setting power for the pool. This would then be distributed to the individual components in the pool, using an algorithm that's suitable for the category of the components. For example, when controlling batteries, power could be distributed based on the SoC of the individual batteries, to keep the batteries in balance.

How to work with other actors

If multiple actors are trying to control (by proposing power values) the same set of components, the power manager will aggregate their desired power values, while considering the priority of the actors and the bounds they set, to calculate the target power for the components.

The final target power can be accessed using the receiver returned from the power_status method available for all pools, which also streams the bounds that an actor should comply with, based on its priority.

Working with other actors to control Batteries

This section describes the details of the power manager's reconciliation algorithm for controlling batteries.

Adding the power proposals of individual actors

When an actor A calls the propose_power method with a power, the proposed power of the lower priority actor will get added to actor A's power. This works as follows:

• the lower priority actor would see bounds shifted by the power proposed by actor A.
• After lower priority actor B sets a power in its shifted bounds, it will get shifted back by the power set by actor A.

This has the effect of adding the powers set by actors A and B.

Example 1: Battery bounds available for use: -100kW to 100kW

Actor	Priority	Available Bounds	Requested Bounds	Requested Power	Adjusted Power	Aggregate Power
A	3	-100kW .. 100kW	None	20kW	20kW	20kW
B	2	-120kW .. 80kW	None	50kW	50kW	70kW
C	1	-170kW .. 30kW	None	50kW	30kW	100kW
					target power	100kW

1. Actor A sees the full system: Available Bounds = -100kW .. 100kW. It proposes a power of 20kW, but no bounds.

2. This becomes the operating point for actor B, so actor B sees bounds shifted by A's proposal = -120kW .. 80kW. It can operate only in this range.

3. Actor B proposes a power of 50kW on this shifted range, and if this is applied on to the original bounds (aka shift the bounds back to the original range), it would be 20kW + 50kW = 70kW.

4. So Actor C sees bounds shifted by 70kW from the original bounds, and sets 50kW on this shifted range, but it can't exceed 30kW, so its request gets limited to 30kW.

5. Shifting this back by 70kW, the target power is calculated to be 100kW.

Irrespective of what any actor sets, the final power won't exceed the available battery bounds.

Example 2:

Actor	Priority	Available Bounds	Requested Bounds	Requested Power	Adjusted Power	Aggregate Power
A	3	-100kW .. 100kW	None	20kW	20kW	20kW
B	2	-120kW .. 80kW	None	-20kW	-20kW	0kW
					target power	0kW

Actors with exactly opposite requests cancel each other out.

Limiting bounds for lower priority actors

When an actor A calls the propose_power method with bounds (either both lower and upper bounds or at least one of them), lower priority actors will see their (shifted) bounds restricted and can only propose power values within that range.

Example 1: Battery bounds available for use: -100kW to 100kW

Actor	Priority	Available Bounds	Requested Bounds	Requested Power	Adjusted Power	Aggregate Power
A	3	-100kW .. 100kW	-20kW .. 100kW	50kW	50kW	50kW
B	2	-70kW .. 50kW	-90kW .. 0kW	-10kW	-10kW	40kW
C	1	-60kW .. 10kW	None	-20kW	-20kW	20kW
					target power	20kW

1. Actor A with the highest priority has the entire battery bounds available to it. It sets limited bounds of -20kW .. 100kW, and proposes a power of 50kW.

2. Actor B's operating point is now 50kW. So, Actor B sees Actor A's limit of -20kW..100kW shifted by 50kW as -70kW..50kW, and can only operate within this range.

3. Actor B tries to limit the bounds of actor C to -90kW .. 0kW, but it doesn't have access to that full range and can only operate in the -70kW .. 50kW range, so its specified bounds get restricted to -70kW .. 0kW.

4. Actor C sees this as -60kW .. 10kW, because it gets shifted by Actor B's proposed power of -10kW.

5. Actor C proposes a power within its bounds and the proposals of all the actors are added to get the target power.

Example 2:

Actor	Priority	Available Bounds	Requested Bounds	Requested Power	Adjusted Power	Aggregate Power
A	3	-100kW .. 100kW	-20kW .. 100kW	50kW	50kW	50kW
B	2	-70kW .. 50kW	-90kW .. 0kW	-90kW	-70kW	-20kW
					target power	-20kW

When an actor requests a power that's outside its available bounds, the closest available power is used.

Comprehensive example

Battery bounds available for use: -100kW to 100kW

Priority	Available Bounds	Requested Bounds	Requested Power	Adjusted Power	Aggregate Power
7	-100 kW .. 100 kW	None	10 kW	10 kW	10 kW
6	-110 kW .. 90 kW	-110 kW .. 80 kW	10 kW	10 kW	20 kW
5	-120 kW .. 70 kW	-100 kW .. 80 kW	80 kW	70 kW	90 kW
4	-170 kW .. 0 kW	None	-120 kW	-120 kW	-30 kW
3	-50 kW .. 120 kW	None	60 kW	60 kW	30 kW
2	-110 kW .. 60 kW	-40 kW .. 30 kW	20 kW	20 kW	50 kW
1	-60 kW .. 10 kW	-50 kW .. 40 kW	25 kW	10 kW	60 kW
0	-60 kW .. 0 kW	None	12 kW	0 kW	60 kW
-1	-60 kW .. 0 kW	-40 kW .. -10 kW	-10 kW	-10 kW	50 kW
				Target Power	50 kW

Working with other actors to control PV inverters and EV chargers

The power manager reconciles power proposals for PV inverters and EV chargers similarly to batteries, but with one key difference:

There is no shifting of operating point between actors, and the powers are not added together.

Higher priority actors can strictly limit the bounds available to lower priority actors, but the power proposals by lower priority actors take precedence, as long as they are within the bounds set by higher priority actors.

This is because PV inverters can only produce power (negative power according to the PSC), and EV chargers can only consume power (positive power according to the PSC), and shifting bounds would make ranges available to actors that a PV inverter or EV charger can't operate in.

A PV pool Example

Actor	Priority	Available Bounds	Requested Bounds	Requested Power	Adjusted Power
A	4	-100kW .. 0W	-90kW .. 0kW	-20kW	-20kW
B	3	-90kW .. 0kW	-75kW .. -20kW	-50kW	-50kW
C	2	-75kW .. -20kW	None	-100kW	-75kW
D	1	-75kW .. -20kW	-60kW .. -60kW	-60kW	-60kW
E	0	-60kW .. -60kW	None	-20kW	-60kW
				Final Power	-60kW

1. Actor A with the highest priority has access to the entire range of the PV inverters. In this case -100kW .. 0W.

2. It wants to limit production to a maximum of -90kW, so it sets bounds of -90kW .. 0W. It also proposes a power of -20kW. If there are no lower priority actors, that power will get set to the inverters. But here, it gets overridden by lower priority actors.

3. Actor B limits the bounds further, and proposes its preferred power.

4. Actor C proposes -100kW, which is outside of what Actor B has allowed, so it gets clamped to -75kW, which is the closest Actor C can get to its requested power in its available range of -75kW .. -20kW.

5. Actor D wants exactly -60kW, so it clamps the bounds to -60kW .. -60kW, and sets -60kW, making sure Actor E or other lower priority actors can't change the power further.

Withdrawing power proposals

An actor can withdraw its power proposal by calling propose_power with None target_power and None bounds (which are the default anyway). As soon as an actor calls pool.propose_power(None), its proposal is dropped and the target power is recalculated and the component powers are updated.

When all the proposals for a pool are withdrawn, the components get reset to their default powers immediately. These are:

component category	default power (according to Passive Sign Convention)
Batteries	Zero
PV	Max production (Min power according to PSC)
EV Chargers	Max consumption (Max power according to PSC)

Classes

frequenz.sdk.microgrid.ComponentGraphConfig

Configuration for the component graph.

Source code in frequenz/microgrid_component_graph/__init__.py

    "FormulaGenerationError",
    "FormulaOverrides",
    "InvalidGraphError",
]

Methods:

__init__

__init__(
    *,
    allow_component_validation_failures: bool = False,
    allow_unconnected_components: bool = False,
    allow_unspecified_inverters: bool = False,
    disable_fallback_components: bool = False,
    include_phantom_loads_in_consumer_formula: bool = False,
    prefer_meters_in_component_formulas: bool = False,
    formula_overrides: FormulaOverrides | None = None
) -> None

Initialize this instance.

PARAMETER	DESCRIPTION
allow_component_validation_failures	Whether to allow validation errors on components. When this is True, the graph will be built even if there are validation errors on the components. TYPE: bool DEFAULT: False
allow_unconnected_components	Whether to allow unconnected components in the graph, that are not reachable from the root. TYPE: bool DEFAULT: False
allow_unspecified_inverters	Whether to allow untyped inverters in the graph. When this is True, inverters that have InverterType::Unspecified will be assumed to be Battery inverters. TYPE: bool DEFAULT: False
disable_fallback_components	Whether to disable fallback components in generated formulas. When this is True, the formulas will not include fallback components. TYPE: bool DEFAULT: False
include_phantom_loads_in_consumer_formula	Whether to consider phantom loads in the consumer formula. Meters with successors can still have loads not represented in the component graph. These are called phantom loads. When this is true, phantom loads are included in formulas by excluding the measurements of successor meters from the measurements of their predecessor meters. When false, consumer formula is generated by excluding production and battery components from the grid measurements. The non-consumer components behind one internal meter are excluded as one group: the meter reading first, the component readings as the fallback. While the meter reading is used, a load behind that meter that is not in the component graph is then also excluded together with the group. TYPE: bool DEFAULT: False
prefer_meters_in_component_formulas	Default policy for the per-category formulas. When False (the default), the component measurement is the primary source and the meter measurement is the fallback for battery_formula, chp_formula, pv_formula, wind_turbine_formula, ev_charger_formula, and steam_boiler_formula. When True, the meter is primary and the component is the fallback. Has no effect on grid_formula, consumer_formula, producer_formula, or any of the coalesce formulas. TYPE: bool DEFAULT: False
formula_overrides	Per-formula overrides for the meter/component preference; see FormulaOverrides. Each entry, when set, takes precedence over prefer_meters_in_component_formulas for that formula. TYPE: FormulaOverrides | None DEFAULT: None

Source code in frequenz/microgrid_component_graph/__init__.py

]

frequenz.sdk.microgrid.FormulaOverrides

Per-formula overrides for the meter/component preference.

Each parameter is None by default, meaning the corresponding formula follows the global prefer_meters_in_component_formulas setting on ComponentGraphConfig. Setting True forces the meter as primary for that formula; False forces the component.

Methods:

__init__

__init__(
    *,
    prefer_meters_in_pv_formula: bool | None = None,
    prefer_meters_in_battery_formula: bool | None = None,
    prefer_meters_in_chp_formula: bool | None = None,
    prefer_meters_in_ev_charger_formula: bool | None = None,
    prefer_meters_in_wind_turbine_formula: (
        bool | None
    ) = None,
    prefer_meters_in_steam_boiler_formula: (
        bool | None
    ) = None
) -> None

Initialize this instance.

PARAMETER	DESCRIPTION
prefer_meters_in_pv_formula	Override for pv_formula. TYPE: bool | None DEFAULT: None
prefer_meters_in_battery_formula	Override for battery_formula. TYPE: bool | None DEFAULT: None
prefer_meters_in_chp_formula	Override for chp_formula. TYPE: bool | None DEFAULT: None
prefer_meters_in_ev_charger_formula	Override for ev_charger_formula. TYPE: bool | None DEFAULT: None
prefer_meters_in_wind_turbine_formula	Override for wind_turbine_formula. TYPE: bool | None DEFAULT: None
prefer_meters_in_steam_boiler_formula	Override for steam_boiler_formula. TYPE: bool | None DEFAULT: None

frequenz.sdk.microgrid.PowerManagerAlgorithm

Bases: Enum

The available algorithms for the power manager.

Source code in src/frequenz/sdk/microgrid/_power_managing/_base_classes.py

class PowerManagerAlgorithm(enum.Enum):
    """The available algorithms for the power manager."""

    MATRYOSHKA = "matryoshka"
    SHIFTING_MATRYOSHKA = "shifting_matryoshka"

Functions:

frequenz.sdk.microgrid.consumer

consumer() -> Consumer

Return the Consumption measuring point.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def consumer() -> Consumer:
    """Return the [`Consumption`][frequenz.sdk.timeseries.consumer.Consumer] measuring point."""
    return _get().consumer()

frequenz.sdk.microgrid.frequency

frequency() -> GridFrequency

Return the grid frequency measuring point.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def frequency() -> GridFrequency:
    """Return the grid frequency measuring point."""
    return _get().frequency()

frequenz.sdk.microgrid.grid

grid() -> Grid

Return the grid measuring point.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def grid() -> Grid:
    """Return the grid measuring point."""
    return _get().grid()

frequenz.sdk.microgrid.initialize async

initialize(
    server_url: str,
    resampler_config: ResamplerConfig,
    *,
    api_power_request_timeout: timedelta = timedelta(
        seconds=5.0
    ),
    battery_power_manager_algorithm: PowerManagerAlgorithm = SHIFTING_MATRYOSHKA,
    component_graph_config: (
        ComponentGraphConfig | None
    ) = None
) -> None

Initialize the microgrid connection manager and the data pipeline.

PARAMETER	DESCRIPTION
server_url	The location of the microgrid API server in the form of a URL. The following format is expected: grpc://hostname{:port}{?ssl=ssl}, where the port should be an int between 0 and 65535 (defaulting to 9090) and ssl should be a boolean (defaulting to false). For example: grpc://localhost:1090?ssl=true. TYPE: str
resampler_config	Configuration for the resampling actor. TYPE: ResamplerConfig
api_power_request_timeout	Timeout to use when making power requests to the microgrid API. When requests to components timeout, they will be marked as blocked for a short duration, during which time they will be unavailable from the corresponding component pools. TYPE: timedelta DEFAULT: timedelta(seconds=5.0)
battery_power_manager_algorithm	The power manager algorithm to use for batteries. TYPE: PowerManagerAlgorithm DEFAULT: SHIFTING_MATRYOSHKA
component_graph_config	The configuration for building the component graph. Use it, for example, to make the per-category formulas (like the battery or PV formulas) read from the meter first (prefer_meters_in_component_formulas), or to set per-formula overrides through FormulaOverrides. When None, the library's default configuration is used. TYPE: ComponentGraphConfig | None DEFAULT: None

Source code in src/frequenz/sdk/microgrid/__init__.py

async def initialize(
    server_url: str,
    resampler_config: ResamplerConfig,
    *,
    api_power_request_timeout: timedelta = timedelta(seconds=5.0),
    # pylint: disable-next: line-too-long
    battery_power_manager_algorithm: PowerManagerAlgorithm = PowerManagerAlgorithm.SHIFTING_MATRYOSHKA,  # noqa: E501
    component_graph_config: ComponentGraphConfig | None = None,
) -> None:
    """Initialize the microgrid connection manager and the data pipeline.

    Args:
        server_url: The location of the microgrid API server in the form of a URL.
            The following format is expected: `grpc://hostname{:port}{?ssl=ssl}`,
            where the port should be an int between `0` and `65535` (defaulting to
            `9090`) and ssl should be a boolean (defaulting to false). For example:
            `grpc://localhost:1090?ssl=true`.
        resampler_config: Configuration for the resampling actor.
        api_power_request_timeout: Timeout to use when making power requests to
            the microgrid API.  When requests to components timeout, they will
            be marked as blocked for a short duration, during which time they
            will be unavailable from the corresponding component pools.
        battery_power_manager_algorithm: The power manager algorithm to use for
            batteries.
        component_graph_config: The configuration for building the component
            graph.  Use it, for example, to make the per-category formulas
            (like the battery or PV formulas) read from the meter first
            (`prefer_meters_in_component_formulas`), or to set per-formula
            overrides through `FormulaOverrides`.  When `None`, the library's
            default configuration is used.
    """
    await connection_manager.initialize(
        server_url,
        component_graph_config=component_graph_config,
    )
    await _data_pipeline.initialize(
        resampler_config,
        api_power_request_timeout=api_power_request_timeout,
        battery_power_manager_algorithm=battery_power_manager_algorithm,
    )

frequenz.sdk.microgrid.logical_meter

logical_meter() -> LogicalMeter

Return the logical meter of the microgrid.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def logical_meter() -> LogicalMeter:
    """Return the logical meter of the microgrid."""
    return _get().logical_meter()

frequenz.sdk.microgrid.new_battery_pool

new_battery_pool(
    *,
    priority: int,
    component_ids: Set[ComponentId] | None = None,
    name: str | None = None
) -> BatteryPool

Return a new BatteryPool instance for the given parameters.

The priority value is used to resolve conflicts when multiple actors are trying to propose different power values for the same set of batteries.

Note

When specifying priority, bigger values indicate higher priority.

It is recommended to reuse the same instance of the BatteryPool within the same actor, unless they are managing different sets of batteries.

In deployments with multiple actors managing the same set of batteries, it is recommended to use different priorities to distinguish between them. If not, a random prioritization will be imposed on them to resolve conflicts, which may lead to unexpected behavior like longer duration to converge on the desired power.

PARAMETER	DESCRIPTION
priority	The priority of the actor making the call. TYPE: int
component_ids	Optional set of IDs of batteries to be managed by the BatteryPool. If not specified, all batteries available in the component graph are used. TYPE: Set[ComponentId] | None DEFAULT: None
name	An optional name used to identify this instance of the pool or a corresponding actor in the logs. TYPE: str | None DEFAULT: None

RETURNS	DESCRIPTION
BatteryPool	A BatteryPool instance.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def new_battery_pool(
    *,
    priority: int,
    component_ids: abc.Set[ComponentId] | None = None,
    name: str | None = None,
) -> BatteryPool:
    """Return a new `BatteryPool` instance for the given parameters.

    The priority value is used to resolve conflicts when multiple actors are trying to
    propose different power values for the same set of batteries.

    !!! note
        When specifying priority, bigger values indicate higher priority.

        It is recommended to reuse the same instance of the `BatteryPool` within the
        same actor, unless they are managing different sets of batteries.

        In deployments with multiple actors managing the same set of batteries, it is
        recommended to use different priorities to distinguish between them.  If not,
        a random prioritization will be imposed on them to resolve conflicts, which may
        lead to unexpected behavior like longer duration to converge on the desired
        power.

    Args:
        priority: The priority of the actor making the call.
        component_ids: Optional set of IDs of batteries to be managed by the
            `BatteryPool`.  If not specified, all batteries available in the component
            graph are used.
        name: An optional name used to identify this instance of the pool or a
            corresponding actor in the logs.

    Returns:
        A `BatteryPool` instance.
    """
    return _get().new_battery_pool(
        priority=priority, component_ids=component_ids, name=name
    )

frequenz.sdk.microgrid.new_ev_charger_pool

new_ev_charger_pool(
    *,
    priority: int,
    component_ids: Set[ComponentId] | None = None,
    name: str | None = None
) -> EVChargerPool

Return a new EVChargerPool instance for the given parameters.

The priority value is used to resolve conflicts when multiple actors are trying to propose different power values for the same set of EV chargers.

Note

When specifying priority, bigger values indicate higher priority.

It is recommended to reuse the same instance of the EVChargerPool within the same actor, unless they are managing different sets of EV chargers.

In deployments with multiple actors managing the same set of EV chargers, it is recommended to use different priorities to distinguish between them. If not, a random prioritization will be imposed on them to resolve conflicts, which may lead to unexpected behavior like longer duration to converge on the desired power.

PARAMETER	DESCRIPTION
priority	The priority of the actor making the call. TYPE: int
component_ids	Optional set of IDs of EV Chargers to be managed by the EVChargerPool. If not specified, all EV Chargers available in the component graph are used. TYPE: Set[ComponentId] | None DEFAULT: None
name	An optional name used to identify this instance of the pool or a corresponding actor in the logs. TYPE: str | None DEFAULT: None

RETURNS	DESCRIPTION
EVChargerPool	An EVChargerPool instance.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def new_ev_charger_pool(
    *,
    priority: int,
    component_ids: abc.Set[ComponentId] | None = None,
    name: str | None = None,
) -> EVChargerPool:
    """Return a new `EVChargerPool` instance for the given parameters.

    The priority value is used to resolve conflicts when multiple actors are trying to
    propose different power values for the same set of EV chargers.

    !!! note
        When specifying priority, bigger values indicate higher priority.

        It is recommended to reuse the same instance of the `EVChargerPool` within the
        same actor, unless they are managing different sets of EV chargers.

        In deployments with multiple actors managing the same set of EV chargers, it is
        recommended to use different priorities to distinguish between them.  If not,
        a random prioritization will be imposed on them to resolve conflicts, which may
        lead to unexpected behavior like longer duration to converge on the desired
        power.

    Args:
        priority: The priority of the actor making the call.
        component_ids: Optional set of IDs of EV Chargers to be managed by the
            EVChargerPool.  If not specified, all EV Chargers available in the
            component graph are used.
        name: An optional name used to identify this instance of the pool or a
            corresponding actor in the logs.

    Returns:
        An `EVChargerPool` instance.
    """
    return _get().new_ev_charger_pool(
        priority=priority, component_ids=component_ids, name=name
    )

frequenz.sdk.microgrid.new_pv_pool

new_pv_pool(
    *,
    priority: int,
    component_ids: Set[ComponentId] | None = None,
    name: str | None = None
) -> PVPool

Return a new PVPool instance for the given parameters.

The priority value is used to resolve conflicts when multiple actors are trying to propose different power values for the same set of PV inverters.

Note

When specifying priority, bigger values indicate higher priority.

It is recommended to reuse the same instance of the PVPool within the same actor, unless they are managing different sets of PV inverters.

In deployments with multiple actors managing the same set of PV inverters, it is recommended to use different priorities to distinguish between them. If not, a random prioritization will be imposed on them to resolve conflicts, which may lead to unexpected behavior like longer duration to converge on the desired power.

PARAMETER	DESCRIPTION
priority	The priority of the actor making the call. TYPE: int
component_ids	Optional set of IDs of PV inverters to be managed by the PVPool. If not specified, all PV inverters available in the component graph are used. TYPE: Set[ComponentId] | None DEFAULT: None
name	An optional name used to identify this instance of the pool or a corresponding actor in the logs. TYPE: str | None DEFAULT: None

RETURNS	DESCRIPTION
PVPool	A PVPool instance.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def new_pv_pool(
    *,
    priority: int,
    component_ids: abc.Set[ComponentId] | None = None,
    name: str | None = None,
) -> PVPool:
    """Return a new `PVPool` instance for the given parameters.

    The priority value is used to resolve conflicts when multiple actors are trying to
    propose different power values for the same set of PV inverters.

    !!! note
        When specifying priority, bigger values indicate higher priority.

        It is recommended to reuse the same instance of the `PVPool` within the same
        actor, unless they are managing different sets of PV inverters.

        In deployments with multiple actors managing the same set of PV inverters, it is
        recommended to use different priorities to distinguish between them.  If not,
        a random prioritization will be imposed on them to resolve conflicts, which may
        lead to unexpected behavior like longer duration to converge on the desired
        power.

    Args:
        priority: The priority of the actor making the call.
        component_ids: Optional set of IDs of PV inverters to be managed by the
            `PVPool`. If not specified, all PV inverters available in the component
            graph are used.
        name: An optional name used to identify this instance of the pool or a
            corresponding actor in the logs.

    Returns:
        A `PVPool` instance.
    """
    return _get().new_pv_pool(priority=priority, component_ids=component_ids, name=name)

frequenz.sdk.microgrid.producer

producer() -> Producer

Return the Production measuring point.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def producer() -> Producer:
    """Return the [`Production`][frequenz.sdk.timeseries.producer.Producer] measuring point."""
    return _get().producer()

frequenz.sdk.microgrid.voltage_per_phase

voltage_per_phase() -> VoltageStreamer

Return the per-phase voltage measuring point.

Source code in src/frequenz/sdk/microgrid/_data_pipeline.py

def voltage_per_phase() -> VoltageStreamer:
    """Return the per-phase voltage measuring point."""
    return _get().voltage_per_phase()