pub struct Client<E: ProtocolError> { /* private fields */ }Expand description
The OCPP client engine, generic over one version’s protocol error type. OCPP1_6Client
and OCPP2_0_1Client are just Client<OCPP1_6Error> / Client<OCPP2_0_1Error> - the
dispatch/timeout/error machinery below is written once and shared by every version.
Implementations§
Source§impl<E: ProtocolError> Client<E>
impl<E: ProtocolError> Client<E>
Sourcepub fn from_transport(
sink: Box<dyn TransportSink>,
stream: Box<dyn TransportStream>,
timeout: Duration,
executor: Box<dyn Executor>,
timer: Box<dyn Timer>,
) -> Self
pub fn from_transport( sink: Box<dyn TransportSink>, stream: Box<dyn TransportStream>, timeout: Duration, executor: Box<dyn Executor>, timer: Box<dyn Timer>, ) -> Self
Build a client over any transport - the WebSocket adapter used by connect_1_6 is
just one implementation of TransportSink/TransportStream; tests and non-WebSocket
transports (an embedded framed link, an in-memory fake for unit tests) construct a
client the same way. executor/timer are likewise pluggable: the tokio-runtime
feature provides TokioExecutor/TokioTimer; embedded users supply their own (e.g.
backed by embassy-executor/embassy-time).
Sourcepub fn from_transport_with_reconnect(
sink: Box<dyn TransportSink>,
stream: Box<dyn TransportStream>,
timeout: Duration,
executor: Box<dyn Executor>,
timer: Box<dyn Timer>,
reconnector: Option<Box<dyn Reconnector>>,
reconnect_policy: ReconnectPolicy,
) -> Self
pub fn from_transport_with_reconnect( sink: Box<dyn TransportSink>, stream: Box<dyn TransportStream>, timeout: Duration, executor: Box<dyn Executor>, timer: Box<dyn Timer>, reconnector: Option<Box<dyn Reconnector>>, reconnect_policy: ReconnectPolicy, ) -> Self
Same as Client::from_transport, but with automatic reconnect: when the transport
closes (TransportStream::recv returns Ok(None)/Err(_)), the background read loop
calls reconnector.connect() (backing off per reconnect_policy between failed
attempts) instead of exiting, and swaps in the new transport once one succeeds.
reconnector: None reproduces from_transport’s behavior - the read loop exits on
disconnect and the client goes quiet. connect_1_6/connect_2_0_1/connect_2_1 use
this constructor with a WebSocket-backed Reconnector.
Sourcepub async fn call<A: Action>(
&self,
request: A::Request,
) -> Result<A::Response, ClientError<E>>
pub async fn call<A: Action>( &self, request: A::Request, ) -> Result<A::Response, ClientError<E>>
Send a CALL for A and wait for the matching CALLRESULT/CALLERROR.
Sourcepub async fn on<A, F, FF>(&self, callback: F)
pub async fn on<A, F, FF>(&self, callback: F)
Register a handler for CALLs the other side sends for action A. Replaces any
previously registered handler for the same action.
Sourcepub async fn send_notification<A: SendAction>(
&self,
payload: A::Payload,
) -> Result<(), ClientError<E>>
pub async fn send_notification<A: SendAction>( &self, payload: A::Payload, ) -> Result<(), ClientError<E>>
Send a SEND (OCPP-J 2.1 only) fire-and-forget message: writes the frame and returns as
soon as the transport accepts it - no waiter, no timeout, since the spec forbids the
receiver from ever replying to a SEND.
Sourcepub async fn on_notification<A, F, FF>(&self, callback: F)
pub async fn on_notification<A, F, FF>(&self, callback: F)
Register a handler for SEND (OCPP-J 2.1 only) messages of action A. Unlike
Client::on, callback returns nothing - the spec forbids replying to a SEND, so
there’s no response to send back. Replaces any previously registered handler for the
same action.
pub async fn send_ping(&self) -> Result<(), ClientError<E>>
pub async fn on_ping<F: FnMut(Self) -> FF + Send + Sync + 'static, FF: Future<Output = ()> + Send>( &self, callback: F, )
Sourcepub async fn on_reconnect<F: FnMut(Self) -> FF + Send + Sync + 'static, FF: Future<Output = ()> + Send>(
&self,
callback: F,
)
pub async fn on_reconnect<F: FnMut(Self) -> FF + Send + Sync + 'static, FF: Future<Output = ()> + Send>( &self, callback: F, )
Register a callback that fires every time the background read loop redials
successfully after a disconnect (see Client::from_transport_with_reconnect). Never
fires for the initial connection, only for later reconnects - the initial Client is
already handed back post-connect, so callers run their own post-connect setup (e.g.
BootNotification) right after connect_1_6/from_transport_with_reconnect returns.
This is the hook for redoing that setup (or resyncing any other session state) after a
dropped-and-restored connection; this crate does not re-run BootNotification or replay
any state on its own.