ocpp

OCPP — Open Charge Point Protocol message models for Gleam.

Supports OCPP 1.6, 2.0.1 and 2.1 over the JSON/WebSocket (OCPP-J) transport.

Each version namespaces one module per spec entity, mirroring how the spec is organised:

ocpp/v2_1/message/<action> — the action’s Request/Response payload types with their OCPP-J codecs (boot_notification.Request, boot_notification.response_decoder()).
ocpp/v2_1/datatype/<type> — one shared datatype with bare new/to_json/decoder (composite_schedule.new(...)).
ocpp/v2_1/enum/<enum> — one enumeration with bare constructors (authorization_status.Accepted) and its token codecs.
ocpp/v2_1/dispatch — the action-string ↔ typed-payload mapping.

One module per entity is deliberate, not fragmentation: many OCPP enums share member names (Accepted, Rejected, Failed, …), and two types in one Gleam module cannot both define an Accepted constructor. Consolidating would force prefixed variants like RegistrationStatusAccepted; per-entity modules are the only layout that gives bare, collision-free names that mirror the spec.

The OCPP-J wire framing lives in ocpp/transport/json/frame. Payload types are transport-agnostic: a future SOAP transport can reuse them behind parallel codecs without touching the type layer.

The sans-IO protocol layer — the OCPP-J RPC endpoint machine, the charging-station and CSMS role machines, and their per-version bindings — lives under ocpp/protocol. It is pure (no processes, sockets, or clocks); see that module’s docs for the machine shape.

This root module holds the Version type plus the WebSocket subprotocol helpers (subprotocol, from_subprotocol, negotiate) used to negotiate the OCPP version during the OCPP-J handshake.

Types

Version

</>

The OCPP protocol versions modelled by this library. Gleam forbids underscores in variant names, so the variants compress the dots; the v1_6/v2_0_1/v2_1 constants below mirror the version namespaces exactly for construction sites (patterns still use the variants).

pub type Version {
  V16
  V201
  V21
}

Constructors

```
V16
```
```
V201
```
```
V21
```

Values

from_subprotocol

</>

pub fn from_subprotocol(token: String) -> Result(Version, Nil)

Parses a WebSocket subprotocol name back to its version. Tokens for versions this library does not model ("ocpp1.2", "ocpp1.5", "ocpp2.0") and unknown strings return Error(Nil).

negotiate

</>

pub fn negotiate(
  offered offered: List(String),
  supported supported: List(Version),
) -> Result(Version, Nil)

Picks the OCPP version for a WebSocket handshake: the first version in supported whose subprotocol name appears in offered wins.

The client lists the names it supports in Sec-WebSocket-Protocol in its order of preference (part 4 §3.1.2), but per RFC 6455 §1.3 the server is free to select any offered subprotocol — so supported is the server’s preference order and the client’s ordering carries no weight here. Echo subprotocol of the winner back in the handshake response.

Error(Nil) means no offered name matches a supported version. Part 4 §3.2 then requires the server to complete the handshake without a Sec-WebSocket-Protocol header and immediately close the connection.

subprotocol

</>

pub fn subprotocol(version: Version) -> String

The IANA-registered WebSocket subprotocol name for a version, as sent in the Sec-WebSocket-Protocol header (part 4 §3.1.2 of the 2.x specs): "ocpp1.6", "ocpp2.0.1", "ocpp2.1".

v1_6

</>

pub const v1_6: Version

OCPP 1.6 (ocpp/v1_6).

v2_0_1

</>

pub const v2_0_1: Version

OCPP 2.0.1 (ocpp/v2_0_1).

v2_1

</>

pub const v2_1: Version

OCPP 2.1 (ocpp/v2_1).