# metrics_pb2

##
`frequenz.api.common.metrics_pb2`

¤

Generated protocol buffer code.

### Classes¤

####
`frequenz.api.common.metrics_pb2.Bounds`

¤

Bases: `google.protobuf.message.Message`

A set of lower and upper bounds for any metric. The units of the bounds are always the same as the related metric.

## Source code in `/opt/hostedtoolcache/Python/3.11.4/x64/lib/python3.11/site-packages/frequenz/api/common/metrics_pb2.py`

####
`frequenz.api.common.metrics_pb2.Metric`

¤

Bases: `google.protobuf.message.Message`

A metric's value, with optional limits.

##### Attributes¤

######
`component_bounds: global___Bounds`

`property`

¤

The current bounds of the metric, as imposed by the component this metric originates from.

######
`rated_bounds: global___Bounds`

`property`

¤

The manufacturer's rated bounds of the metric. This may differ from
`system_bounds`

as it does not take into account the current state of the
overall system.

######
`system_exclusion_bounds: global___Bounds`

`property`

¤

These bounds indicate the range of values that are disallowed for the
metric.
If these bounds for a metric are [`lower`

, `upper`

], then this metric's
`value`

needs to comply with the constraints
`value <= lower`

OR `upper <= value`

.

It is important to note that these bounds work together with
`system_inclusion_bounds`

.

E.g., for the system to accept a charge command,
clients need to request power values within the bounds
`[system_inclusion_bounds.lower, system_exclusion_bounds.lower]`

.
This means that clients can only request charge commands with values that
are within the `system_inclusion_bounds`

, but not within
`system_exclusion_bounds`

.
Similarly, for the system to accept a discharge command,
clients need to request power values within the bounds
`[system_exclusion_bounds.upper, system_inclusion_bounds.upper]`

.

The following diagram illustrates the relationship between the bounds.

---- values here are disallowed and wil be rejected ==== vales here are allowed and will be accepted######
`system_inclusion_bounds: global___Bounds`

`property`

¤

These bounds indicate the range of values that are allowed for the metric.
If these bounds for a metric are [`lower`

, `upper`

], then this metric's
`value`

needs to comply with the constraint `lower <= value <= upper`

It is important to note that these bounds work together with
`system_exclusion_bounds`

.

E.g., for the system to accept a charge command,
clients need to request power values within the bounds
`[system_inclusion_bounds.lower, system_exclusion_bounds.lower]`

.
This means that clients can only request charge commands with values that
are within the `system_inclusion_bounds`

, but not within
`system_exclusion_bounds`

.
Similarly, for the system to accept a discharge command,
clients need to request power values within the bounds
`[system_exclusion_bounds.upper, system_inclusion_bounds.upper]`

.

The following diagram illustrates the relationship between the bounds.

---- values here are disallowed and wil be rejected ==== vales here are allowed and will be accepted######
`value: builtins.float`

`instance-attribute`

¤

The current value of the metric.

####
`frequenz.api.common.metrics_pb2.MetricAggregation`

¤

Bases: `google.protobuf.message.Message`

Metrics depicted as a collection of statistical summaries.

Useful when a component has to report multiple values for the same metric. E.g., a battery is a collection of several blocks, and each block has a temperature sensor. The battery can report a summary of the values provided by all these sensors, like, min, max, avg, etc., and if possible, the entire array of temperature values.

##### Attributes¤

######
`avg: builtins.float`

`instance-attribute`

¤

The average value of the metric.

######
`component_bounds: global___Bounds`

`property`

¤

The current bounds of the metric, as imposed by the component this metric originates from.

######
`max: builtins.float`

`instance-attribute`

¤

The maximum value of the metric.

######
`min: builtins.float`

`instance-attribute`

¤

The minimum value of the metric.

######
`rated_bounds: global___Bounds`

`property`

¤

The manufacturer's rated bounds of the metric. This may differ from
`system_bounds`

as it does not take into account the current state of the
overall system.

######
`raw_values: google.protobuf.internal.containers.RepeatedScalarFieldContainer[builtins.float]`

`property`

¤

The array of all the metric values.

######
`system_exclusion_bounds: global___Bounds`

`property`

¤

These bounds indicate the range of values that are disallowed for the
metric.
If these bounds for a metric are [`lower`

, `upper`

], then this metric's
`value`

needs to comply with the constraints
`value <= lower`

OR `upper <= value`

.

It is important to note that these bounds work together with
`system_inclusion_bounds`

.

E.g., for the system to accept a charge command,
clients need to request power values within the bounds
`[system_inclusion_bounds.lower, system_exclusion_bounds.lower]`

.
This means that clients can only request charge commands with power values
that are within the `system_inclusion_bounds`

, but not within
`system_exclusion_bounds`

.
Similarly, for the system to accept a discharge command,
clients need to request power values within the bounds
`[system_exclusion_bounds.upper, system_inclusion_bounds.upper]`

.

The following diagram illustrates the relationship between the bounds.

---- values here are disallowed and wil be rejected ==== vales here are allowed and will be accepted######
`system_inclusion_bounds: global___Bounds`

`property`

¤

These bounds indicate the range of values that are allowed for the metric.
If these bounds for a metric are [`lower`

, `upper`

], then this metric's
`value`

needs to comply with the constraint `lower <= value <= upper`

It is important to note that these bounds work together with
`system_exclusion_bounds`

.

E.g., for the system to accept a charge command,
clients need to request power values within the bounds
`[system_inclusion_bounds.lower, system_exclusion_bounds.lower]`

.
This means that clients can only request charge commands with power values
that are within the `system_inclusion_bounds`

, but not within
`system_exclusion_bounds`

.
Similarly, for the system to accept a discharge command,
clients need to request power values within the bounds
`[system_exclusion_bounds.upper, system_inclusion_bounds.upper]`

.

The following diagram illustrates the relationship between the bounds.

---- values here are disallowed and wil be rejected ==== vales here are allowed and will be accepted