Deploy or connect to an OCPP-compliant Central System (CS) that accepts WebSocket connections from charge points; establish the WebSocket connection from the EVSE using the endpoint URL format ws://<CS_HOST>/ocpp/<CHARGE_POINT_ID> with subprotocol 'ocpp1.6' or 'ocpp2.0.1'.
After the charge point sends a BootNotification and the CS responds with Accepted, send a SetChargingProfile request from the CS to the charge point specifying the connectorId (0 for station-wide, or a specific connector number).
Construct the ChargingProfile object with chargingProfileId, stackLevel, chargingProfilePurpose (e.g., TxDefaultProfile for default transaction limits or TxProfile for a specific transaction), chargingProfileKind (Absolute, Recurring, or Relative), and a ChargingSchedule.
In the ChargingSchedule, set chargingRateUnit (A for amperes or W for watts), optionally a duration, and a chargingSchedulePeriod array where each period has startPeriod (seconds from schedule start) and limit (max current in A or power in W).
Handle the SetChargingProfile response: a status of 'Accepted' confirms the profile is active; implement ClearChargingProfile to remove profiles and GetCompositeSchedule to inspect what the charge point will actually follow given all stacked profiles.
Known gotchas
OCPP profile stacking uses stackLevel to resolve conflicts; a higher stackLevel overrides lower ones for the same connectorId and purpose — failing to clear old profiles before setting new ones can result in unexpected effective limits if old profiles with higher stackLevel remain active.
The chargingRateUnit must match what the charge point supports; many charge points only support amperes (A) and will reject or ignore watt-based profiles — check the charge point's capabilities via the ChangeConfiguration or GetConfiguration message if uncertain.
OCPP 1.6 and 2.0.1 have different message formats and some different field names for charging profiles; a CS designed for 1.6 will not correctly interoperate with a 2.0.1 charge point without a protocol-aware bridge — verify protocol version during the BootNotification handshake.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp