v2_1

OCPP 2.1 bindings for the protocol machines.

Thin config constructors that bind the version-generic machines — ocpp/protocol/endpoint, ocpp/protocol/station and ocpp/protocol/csms — to the OCPP 2.1 message unions and codecs in ocpp/v2_1/dispatch. The machines themselves know nothing about any OCPP version; everything version-specific enters through the values built here:

endpoint_config wires the dispatch module’s encoders/decoders into the generic RPC endpoint, so req/res are dispatch.Request/dispatch.Response.
station_config adds the charging-station lifecycle bindings: the BootNotification request to (re)send, how to read the CSMS’s registration decision out of a response, and how to build a Heartbeat request.
csms_config adds the CSMS-side bindings: recognising an inbound BootNotification and reading the registration decision out of the application’s reply to one.

The wire carries the boot response’s interval in seconds (per the 2.1 spec); the machines measure time in milliseconds, so the readers here multiply by 1000.

2.1-specific semantics

OCPP 2.1 introduces the SEND and CALLRESULTERROR frames, and with them send-only (fire-and-forget) actions such as NotifyPeriodicEventStream. The dispatch module carries those Send payloads in the same Request union as ordinary requests, and request_to_json/request_decoder handle them like any other action — the codec does not distinguish CALL from SEND. Which frame goes on the wire is decided by the machine input instead: SendRequested emits a SEND frame, CallRequested a CALL. An application bound through this module MUST issue send-only actions via SendRequested — a CallRequested carrying one would put a CALL on the wire that the peer cannot answer.

Values

csms_config

</>

pub fn csms_config(
  call_timeout_ms call_timeout_ms: Int,
  enforcement enforcement: csms.RegistrationEnforcement,
) -> csms.CsmsConfig(dispatch.Request, dispatch.Response)

A csms.CsmsConfig speaking OCPP 2.1: inbound BootNotification CALLs are the boot requests, and the registration decision is the status of the application’s BootNotification response. With enforcement: csms.RejectUnregistered, non-boot CALLs from a station whose boot has not been accepted are answered with a CALLERROR SecurityError instead of being delivered.

endpoint_config

</>

pub fn endpoint_config(
  call_timeout_ms call_timeout_ms: Int,
) -> endpoint.Config(dispatch.Request, dispatch.Response)

An endpoint.Config speaking OCPP 2.1: requests and responses are the ocpp/v2_1/dispatch unions, with that module’s codecs doing the action mapping. call_timeout_ms is how long an outgoing CALL may remain unanswered before it fails with TimedOut.

station_config

</>

pub fn station_config(
  call_timeout_ms call_timeout_ms: Int,
  boot_request boot_request: boot_notification.Request,
  boot_retry_ms boot_retry_ms: Int,
) -> station.StationConfig(dispatch.Request, dispatch.Response)

A station.StationConfig speaking OCPP 2.1. boot_request is the BootNotification payload the station introduces itself with (resent verbatim on every retry); heartbeats are bare Heartbeat requests. boot_retry_ms is the fallback wait before re-booting when the CSMS supplies no usable interval — see the station module for the full rules.