Trait Microgrid 

pub trait Microgrid:
    Send
    + Sync
    + 'static {
    type ReceiveElectricalComponentTelemetryStreamStream: Stream<Item = Result<ReceiveElectricalComponentTelemetryStreamResponse, Status>> + Send + 'static;
    type ReceiveSensorTelemetryStreamStream: Stream<Item = Result<ReceiveSensorTelemetryStreamResponse, Status>> + Send + 'static;
    type SetElectricalComponentPowerStream: Stream<Item = Result<SetElectricalComponentPowerResponse, Status>> + Send + 'static;

    // Required methods
    fn get_microgrid<'life0, 'async_trait>(
        &'life0 self,
        request: Request<Empty>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<GetMicrogridResponse>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn list_electrical_components<'life0, 'async_trait>(
        &'life0 self,
        request: Request<ListElectricalComponentsRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<ListElectricalComponentsResponse>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn list_sensors<'life0, 'async_trait>(
        &'life0 self,
        request: Request<ListSensorRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<ListSensorsResponse>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn list_electrical_component_connections<'life0, 'async_trait>(
        &'life0 self,
        request: Request<ListElectricalComponentConnectionsRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<ListElectricalComponentConnectionsResponse>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn receive_electrical_component_telemetry_stream<'life0, 'async_trait>(
        &'life0 self,
        request: Request<ReceiveElectricalComponentTelemetryStreamRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Self::ReceiveElectricalComponentTelemetryStreamStream>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn receive_sensor_telemetry_stream<'life0, 'async_trait>(
        &'life0 self,
        request: Request<ReceiveSensorTelemetryStreamRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Self::ReceiveSensorTelemetryStreamStream>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn augment_electrical_component_bounds<'life0, 'async_trait>(
        &'life0 self,
        request: Request<AugmentElectricalComponentBoundsRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<AugmentElectricalComponentBoundsResponse>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn set_electrical_component_power<'life0, 'async_trait>(
        &'life0 self,
        request: Request<SetElectricalComponentPowerRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Self::SetElectricalComponentPowerStream>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn start_electrical_component<'life0, 'async_trait>(
        &'life0 self,
        request: Request<StartElectricalComponentRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn put_electrical_component_in_standby<'life0, 'async_trait>(
        &'life0 self,
        request: Request<PutElectricalComponentInStandbyRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn stop_electrical_component<'life0, 'async_trait>(
        &'life0 self,
        request: Request<StopElectricalComponentRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn ack_electrical_component_error<'life0, 'async_trait>(
        &'life0 self,
        request: Request<AckElectricalComponentErrorRequest>,
    ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
}

Generated trait containing gRPC methods that should be implemented for use with MicrogridServer.

Required Associated Types

type ReceiveElectricalComponentTelemetryStreamStream: Stream<Item = Result<ReceiveElectricalComponentTelemetryStreamResponse, Status>> + Send + 'static

Server streaming response type for the ReceiveElectricalComponentTelemetryStream method.

type ReceiveSensorTelemetryStreamStream: Stream<Item = Result<ReceiveSensorTelemetryStreamResponse, Status>> + Send + 'static

Server streaming response type for the ReceiveSensorTelemetryStream method.

type SetElectricalComponentPowerStream: Stream<Item = Result<SetElectricalComponentPowerResponse, Status>> + Send + 'static

Server streaming response type for the SetElectricalComponentPower method.

Required Methods

fn get_microgrid<'life0, 'async_trait>( &'life0 self, request: Request<Empty>, ) -> Pin<Box<dyn Future<Output = Result<Response<GetMicrogridResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Returns information about the local microgrid. This information that describes the overall microgrid, as opposed to its electrical components or sensors, e.g., the microgrid ID, location.

fn list_electrical_components<'life0, 'async_trait>( &'life0 self, request: Request<ListElectricalComponentsRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<ListElectricalComponentsResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

List electrical components in the local microgrid, optionally filtered by a given list of electrical component IDs and their categories.

Electrical components are a part of a microgrid’s electrical infrastructure are can be connected to each other to form an electrical circuit, which can then be represented as a graph.

If provided, the filters for electrical component IDs and categories have an AND relationship with one another, meaning that they are applied serially, but the elements within a single filter list have an OR relationship with each other. E.g., if ids = [1, 2, 3], and categories = [ ElectricalComponentCategory::ELECTRICAL_COMPONENT_CATEGORY_INVERTER, ElectricalComponentCategory::ELECTRICAL_COMPONENT_CATEGORY_BATTERY], then the results will consist of elements that have the IDs 1, OR 2, OR 3, AND are of the categories ElectricalComponentCategory::ELECTRICAL_COMPONENT_CATEGORY_INVERTER OR ElectricalComponentCategory::ELECTRICAL_COMPONENT_CATEGORY_BATTERY.

If a filter list is empty, then that filter is not applied.

fn list_sensors<'life0, 'async_trait>( &'life0 self, request: Request<ListSensorRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<ListSensorsResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Returns a list of sensors in the local microgrid, optionally filtered by a given list of sensor IDs.

Sensors measure physical metrics in the microgrid’s surroundings, and are not classified as electrical components.

If provided, the filters for sensor IDs and categories have an AND relationship with one another, meaning that they are applied serially, but the elements within a single filter list have an OR relationship with each other. E.g., if ids = [1, 2, 3], then the results will consist of elements that have the IDs 1, OR 2, OR 3,

If a filter list is empty, then that filter is not applied.

fn list_electrical_component_connections<'life0, 'async_trait>( &'life0 self, request: Request<ListElectricalComponentConnectionsRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<ListElectricalComponentConnectionsResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Electrical components are a part of a microgrid’s electrical infrastructure are can be connected to each other to form an electrical circuit, which can then be represented as a graph.

This RPC return a list of the connections between two electrical components, denoted by (start, end). The direction of a connection is always away from the grid endpoint, i.e. aligned with the direction of positive current according to the passive sign convention: https://en.wikipedia.org/wiki/Passive_sign_convention

The request may be filtered by start/end electrical component(s) of individual connections. If provided, the start and end filters have an AND relationship between each other, meaning that they are applied serially, but an OR relationship with other elements in the same list. For example, if start = [1, 2, 3], and end = [4, 5, 6], then the result should have all the connections where

• each start electrical component ID is either 1, 2, OR 3, AND
• each end electrical component ID is either 4, 5, OR 6.

fn receive_electrical_component_telemetry_stream<'life0, 'async_trait>( &'life0 self, request: Request<ReceiveElectricalComponentTelemetryStreamRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Self::ReceiveElectricalComponentTelemetryStreamStream>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Returns a stream containing data from a electrical component with a given ID.

fn receive_sensor_telemetry_stream<'life0, 'async_trait>( &'life0 self, request: Request<ReceiveSensorTelemetryStreamRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Self::ReceiveSensorTelemetryStreamStream>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Returns a stream containing data from a sensor with a given ID.

fn augment_electrical_component_bounds<'life0, 'async_trait>( &'life0 self, request: Request<AugmentElectricalComponentBoundsRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<AugmentElectricalComponentBoundsResponse>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Augments the overall bounds for a given metric of a given electrical component with the provided bounds. Returns the UTC time at which the provided bounds will expire and its effects will no longer be visible in the overall bounds for the given metric.

The request parameters allows users to select a duration until which the bounds will stay in effect. If no duration is provided, then the bounds will be removed after a default duration of 5 seconds.

Inclusion bounds give the range that the system will try to keep the metric within. If the metric goes outside of these bounds, the system will try to bring it back within the bounds. If the bounds for a metric are [`lower_1, upper_1], [lower_2, upper_2](<lower_1, upper_1], [lower_2, upper_2>), then this metric's valueneeds to comply with the constraintslower_1 <= value <= upper_1ORlower_2 <= value <= upper_2`.

If multiple inclusion bounds have been provided for a metric, then the overlapping bounds are merged into a single bound, and non-overlapping bounds are kept separate. E.g. if the bounds are [0, 10], [5, 15], 20, 30, then the resulting bounds will be [0, 15], 20, 30.

The following diagram illustrates how bounds are applied:

 lower_1  upper_1
<----|========|--------|========|-------->
                   lower_2  upper_2

The bounds in this example are [[lower_1, upper_1], [lower_2, upper_2]]. –– values here are considered out of range. ==== values here are considered within range.

Note that for power metrics, regardless of the bounds, 0W is always allowed.

fn set_electrical_component_power<'life0, 'async_trait>( &'life0 self, request: Request<SetElectricalComponentPowerRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Self::SetElectricalComponentPowerStream>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Sets the active or reactive power output of a electrical component to a specified target. This RPC allows setting either active or reactive power in a single request. Setting both simultaneously is not supported; clients must issue separate requests for each power type.

Clients are expected to provide the target power in the request parameters. The target power is specified in watts (W) for active power, and in volt-amperes reactive (VAR) for reactive power. The sign-convention for the target power is as follows:

For active power:

• Negative values (-) indicate discharge towards the grid.
• Positive values (+) indicate charge from the direction of the grid.

For reactive power:

• Negative values (-) indicate capacitive reactive power, where the current leads the voltage.
• Positive values (+) indicate inductive reactive power, where the current lags the voltage.

Note that the target electrical component may have a resolution of more than 1 W or 1 VAr. E.g., an inverter may have a resolution of 88 W. In such cases, the target power’s magnitude will be floored to the nearest multiple of the resolution.

The server provides a stream of responses in return. Each response will contain the current status of the request. Initial response: The initial response will be sent immediately after the request is received, and will indicate whether the request was accepted or rejected. If the request was accepted, this response will also contain the timestamp until which the given power command will stay in effect, after which the electrical component will be returned to its default state. Subsequent response: After the initial response, the server will send another response in the stream, which will be the final response. It will indicate whether the request was successful, failed, or overridden by another request. If the request was successful, it will also contain the timestamp until which the given power command will stay in effect, after which the electrical component will be returned to its default state.

This command is supported for the following electrical component categories, provided the specific model also supports it:

• ELECTRICAL_COMPONENT_CATEGORY_CAPACITOR_BANK
• ELECTRICAL_COMPONENT_CATEGORY_CHP
• ELECTRICAL_COMPONENT_CATEGORY_ELECTROLYZER
• ELECTRICAL_COMPONENT_CATEGORY_EV_CHARGER
• ELECTRICAL_COMPONENT_CATEGORY_INVERTER
• ELECTRICAL_COMPONENT_CATEGORY_WIND_TURBINE

fn start_electrical_component<'life0, 'async_trait>( &'life0 self, request: Request<StartElectricalComponentRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Starts the electrical component, and brings it into a state where it is immediately operational.

Performs the following sequence of actions for the following electrical component categories:

• Inverter:

• closes DC relays, if the feature is available

• closes AC relays

• sets power output to 0

• Battery: Checks if DC relays are open, then

• closes DC relays

• Relays:

• closes relays

• Precharge Modules:

• starts the precharge process, and eventually closes the DC relays.

If any of the above mentioned actions for a given electrical component has already been performed, then this method call effectively skips that action.

If a feature required to perform an action is missing, then that action is skipped.

fn put_electrical_component_in_standby<'life0, 'async_trait>( &'life0 self, request: Request<PutElectricalComponentInStandbyRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Sets the given electrical component into a standby state, from which it can take a few minutes to return to an operational state. A transition to an operational state can be triggered by calling the StartElectricalComponent RPC, or the SetElectricalComponentPowerActive RPC.

Performs the following sequence actions for the following electrical component categories:

• Inverter: Checks if AC and DC relays are closed, then
• sets power to 0, and
• opens AC relays

If any of the checks mentioned above fails, then the method call returns an error.

If any of the above mentioned actions for a given electrical component has already been performed, then this method call effectively skips that action.

fn stop_electrical_component<'life0, 'async_trait>( &'life0 self, request: Request<StopElectricalComponentRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Stops the electrical component completely, potentially disengaging its power electronics controller(s).

Performs the following sequence actions for the following electrical component categories:

• Inverter:

• Brings electrical component to the cold-standby state

• opens DC relays

• Battery: Checks if the power output is 0, then

• opens DC relays

• Relays:

• opens relays

• Precharge Modules:

• opens the DC relays.

If any of the checks mentioned above fails, then the method call returns an error.

If any of the above mentioned actions for a given electrical component has already been performed, then this method call effectively skips that action.

If a feature required to perform an action is missing, then that action is skipped.

fn ack_electrical_component_error<'life0, 'async_trait>( &'life0 self, request: Request<AckElectricalComponentErrorRequest>, ) -> Pin<Box<dyn Future<Output = Result<Response<Empty>, Status>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Acknowledges any recoverable error reported by the electrical component, and brings it back to the stopped or cold-standby state.

Implementors