Ocpp

OCPP — AI Agent Reference

You are assisting a developer working on EV charging infrastructure using OCPP. This skill covers OCPP 2.1, OCPP 2.0.1, and OCPP 1.6J. Use it to provide accurate schema references, implementation guidance, and to flag areas where the spec is silent.

Version Detection

Detect the OCPP version from the developer's code:

• 1.6J indicators: StartTransaction, StopTransaction, RemoteStartTransaction, RemoteStopTransaction, Charge Point, Central System, idTag (string), connectorId without evseId, .req / .conf naming
• 2.0.1 indicators: TransactionEvent, RequestStartTransaction, RequestStopTransaction, Charging Station, CSMS, IdTokenType (object), evseId, Request / Response naming
• 2.1 indicators: SetDERControl, GetTariffs, OpenPeriodicEventStream, BatterySwap, RequestBatterySwap, NotifyPeriodicEventStream, AFRRSignal, PullDynamicScheduleUpdate, UpdateDynamicSchedule, OCPP-J subprotocol string ocpp2.1, JSON schema $id URNs containing :2:2025: (e.g. urn:OCPP:Cp:2:2025:1:SetDERControlRequest)

If unclear, ask the developer which version they're using.

Quick Reference

What is OCPP: Open Charge Point Protocol — communication between EV Charging Stations and a management backend over WebSocket + JSON. The station initiates the connection. Both sides can send messages.

OCPP 2.1

• Roles: Charging Station (CS) ↔ CSMS
• Device Model: Same as 2.0.1 — Charging Station → EVSE(s) → Connector(s). evseId=0 means the whole station.
• 91 messages = 2.0.1's 64 messages + 27 new messages (see below)
• New capabilities: DER control, V2X/bidirectional power transfer, tariff management, battery swap, periodic event stream, dynamic charging profile updates, priority charging, web payment

OCPP 2.0.1

• Roles: Charging Station (CS) ↔ CSMS
• Device Model: Charging Station → EVSE(s) → Connector(s). evseId and connectorId are 1-indexed. evseId=0 means the whole station.
• 64 messages, organized by Functional Block

OCPP 1.6J

• Roles: Charge Point (CP) ↔ Central System (CS)
• Device Model: Charge Point → Connector(s). connectorId is 1-indexed. connectorId=0 means the whole Charge Point. No EVSE concept.
• 28 messages, organized by Feature Profile (Core, Smart Charging, Firmware, Local Auth List, Reservation, Remote Trigger)

Message Frame (both versions): JSON-RPC-like. Three types:

• CALL — [2, messageId, action, payload]
• CALLRESULT — [3, messageId, payload]
• CALLERROR — [4, messageId, errorCode, errorDescription, errorDetails]

All 64 OCPP 2.0.1 Messages

Provisioning & Lifecycle

• BootNotification (CS→CSMS) — Station registers on connect
• Heartbeat (CS→CSMS) — Keepalive
• StatusNotification (CS→CSMS) — Connector/EVSE status changes
• GetVariables (CSMS→CS) — Read configuration
• SetVariables (CSMS→CS) — Write configuration
• GetBaseReport (CSMS→CS) — Request full variable inventory
• NotifyReport (CS→CSMS) — Variable inventory response (paginated)
• SetNetworkProfile (CSMS→CS) — Configure network connection profiles
• Reset (CSMS→CS) — Reboot station

Authorization

• Authorize (CS→CSMS) — Validate ID token
• ClearCache (CSMS→CS) — Clear authorization cache
• SendLocalList (CSMS→CS) — Push local auth list
• GetLocalListVersion (CSMS→CS) — Query local auth list version

Transactions

• TransactionEvent (CS→CSMS) — Started/Updated/Ended events
• RequestStartTransaction (CSMS→CS) — Remote start
• RequestStopTransaction (CSMS→CS) — Remote stop
• GetTransactionStatus (CSMS→CS) — Query outstanding transaction messages
• MeterValues (CS→CSMS) — Send meter values outside transaction context

Remote Control

• TriggerMessage (CSMS→CS) — Request CS to send a specific message
• UnlockConnector (CSMS→CS) — Physically unlock connector
• ChangeAvailability (CSMS→CS) — Set EVSE operative/inoperative

Smart Charging

• SetChargingProfile (CSMS→CS) — Install charging profile
• GetChargingProfiles (CSMS→CS) — Query installed profiles
• ClearChargingProfile (CSMS→CS) — Remove profiles
• ClearedChargingLimit (CS→CSMS) — External limit cleared
• NotifyChargingLimit (CS→CSMS) — External limit notification
• ReportChargingProfiles (CS→CSMS) — Profile query response
• GetCompositeSchedule (CSMS→CS) — Calculate effective schedule
• NotifyEVChargingSchedule (CS→CSMS) — EV-proposed schedule (ISO 15118)
• NotifyEVChargingNeeds (CS→CSMS) — Report EV charging needs (ISO 15118)

Firmware

• UpdateFirmware (CSMS→CS) — Trigger firmware update
• FirmwareStatusNotification (CS→CSMS) — Update progress
• PublishFirmware (CSMS→CS) — Make firmware available to local network
• PublishFirmwareStatusNotification (CS→CSMS) — Publish progress
• UnpublishFirmware (CSMS→CS) — Remove published firmware

Security & Certificates

• Get15118EVCertificate (CS→CSMS) — EV certificate request
• GetCertificateStatus (CS→CSMS) — OCSP status check
• SignCertificate (CS→CSMS) — CSR for station certificate
• CertificateSigned (CSMS→CS) — Signed certificate delivery
• InstallCertificate (CSMS→CS) — Install CA certificate
• DeleteCertificate (CSMS→CS) — Remove certificate
• GetInstalledCertificateIds (CSMS→CS) — List installed certs
• SecurityEventNotification (CS→CSMS) — Report security-related event

Diagnostics & Monitoring

• GetLog (CSMS→CS) — Request log upload
• LogStatusNotification (CS→CSMS) — Log upload progress
• NotifyEvent (CS→CSMS) — Component/variable events
• SetMonitoringBase (CSMS→CS) — Set monitoring baseline
• SetVariableMonitoring (CSMS→CS) — Configure variable monitors
• SetMonitoringLevel (CSMS→CS) — Set monitoring severity level
• GetMonitoringReport (CSMS→CS) — Query active monitors
• ClearVariableMonitoring (CSMS→CS) — Remove monitors
• NotifyMonitoringReport (CS→CSMS) — Monitor query response
• CustomerInformation (CSMS→CS) — Request customer data
• NotifyCustomerInformation (CS→CSMS) — Customer data response

Display Messages

• CostUpdated (CSMS→CS) — Update displayed cost
• SetDisplayMessage (CSMS→CS) — Show message on display
• GetDisplayMessages (CSMS→CS) — Query displayed messages
• ClearDisplayMessage (CSMS→CS) — Remove displayed message
• NotifyDisplayMessages (CS→CSMS) — Display message query response

Reservation

• ReserveNow (CSMS→CS) — Create reservation
• CancelReservation (CSMS→CS) — Cancel reservation
• ReservationStatusUpdate (CS→CSMS) — Reservation expired/removed

Data Transfer

• DataTransfer (CS↔CSMS) — Bidirectional vendor extension

OCPP 2.1 — 27 New Messages (added to 2.0.1's 64)

OCPP 2.1 retains all 64 OCPP 2.0.1 messages and adds the following 27. Headings match the functional block each message's schema lives under (see the schema file map below).

DER Control (Distributed Energy Resources)

• SetDERControl (CSMS→CS) — Install DER control setpoint (frequency response, power limits, reactive power)
• GetDERControl (CSMS→CS) — Query installed DER control settings
• ClearDERControl (CSMS→CS) — Remove DER control settings
• ReportDERControl (CS→CSMS) — DER control query response
• NotifyDERAlarm (CS→CSMS) — Report DER-related alarm condition
• NotifyDERStartStop (CS→CSMS) — Notify DER function start/stop

Bidirectional / V2X

• NotifyAllowedEnergyTransfer (CSMS→CS) — Inform CS which energy transfer directions are allowed
• AFRRSignal (CSMS→CS) — Automatic Frequency Restoration Reserve signal (frequency support for V2X)

Battery Swap

• BatterySwap (CS→CSMS) — Notify battery swap event at station
• RequestBatterySwap (CSMS→CS) — Request battery swap operation

Tariff & Cost

• GetTariffs (CSMS→CS) — Query tariffs installed on station
• SetDefaultTariff (CSMS→CS) — Set the default tariff for an EVSE
• ChangeTransactionTariff (CSMS→CS) — Change tariff mid-transaction
• ClearTariffs (CSMS→CS) — Remove tariffs from station
• NotifySettlement (CS→CSMS) — Notify settlement result for a payment
• NotifyWebPaymentStarted (CS→CSMS) — Notify web-based payment initiation
• VatNumberValidation (CS→CSMS) — Request VAT number validation

Dynamic Smart Charging

• PullDynamicScheduleUpdate (CS→CSMS) — Request updated schedule for dynamic profile
• UpdateDynamicSchedule (CSMS→CS) — Push schedule update for dynamic profile
• NotifyPriorityCharging (CS→CSMS) — Notify that priority charging has started/stopped
• UsePriorityCharging (CSMS→CS) — Request CS to use priority charging

Periodic Event Stream

• OpenPeriodicEventStream (CSMS→CS) — Open a stream for periodic event reporting
• ClosePeriodicEventStream (CSMS→CS) — Close a periodic event stream
• GetPeriodicEventStream (CSMS→CS) — Query open periodic event streams
• AdjustPeriodicEventStream (CSMS→CS) — Modify parameters of an open stream
• NotifyPeriodicEventStream (CS→CSMS, one-way SEND) — Push periodic event data to CSMS

Certificates

• GetCertificateChainStatus (CS→CSMS) — Query certificate chain OCSP status

All 28 OCPP 1.6J Messages

Core (required profile)

• Authorize (CP→CS) — Validate idTag
• BootNotification (CP→CS) — Charge Point registers after (re)boot
• ChangeAvailability (CS→CP) — Set connector operative/inoperative
• ChangeConfiguration (CS→CP) — Set a configuration key
• ClearCache (CS→CP) — Clear authorization cache
• DataTransfer (CP↔CS) — Vendor-specific data exchange
• GetConfiguration (CS→CP) — Read configuration keys
• Heartbeat (CP→CS) — Keepalive
• MeterValues (CP→CS) — Periodic meter readings
• RemoteStartTransaction (CS→CP) — Remote start
• RemoteStopTransaction (CS→CP) — Remote stop
• Reset (CS→CP) — Reboot Charge Point
• StartTransaction (CP→CS) — Transaction started
• StatusNotification (CP→CS) — Connector status/error change
• StopTransaction (CP→CS) — Transaction ended
• UnlockConnector (CS→CP) — Physically unlock connector

Smart Charging

• SetChargingProfile (CS→CP) — Install charging profile
• ClearChargingProfile (CS→CP) — Remove profiles
• GetCompositeSchedule (CS→CP) — Get effective schedule

Firmware Management

• GetDiagnostics (CS→CP) — Request diagnostic log upload
• DiagnosticsStatusNotification (CP→CS) — Upload progress
• UpdateFirmware (CS→CP) — Trigger firmware update
• FirmwareStatusNotification (CP→CS) — Update progress

Local Auth List Management

• SendLocalList (CS→CP) — Push local authorization list
• GetLocalListVersion (CS→CP) — Query list version

Reservation

• ReserveNow (CS→CP) — Reserve a connector
• CancelReservation (CS→CP) — Cancel reservation

Remote Trigger

• TriggerMessage (CS→CP) — Request CP to send a specific message

Key Data Types (OCPP 2.0.1)

• IdTokenType — User identification (eMAID, RFID, etc.) with optional groupIdToken
• ChargingProfileType — Charging limits: id, stackLevel, purpose, kind, chargingSchedule
• MeterValueType — Timestamped array of SampledValue (energy, power, current, voltage, SoC)
• EVSEType — EVSE identifier (id + optional connectorId)
• StatusInfoType — Reason code + additional info for status responses
• TransactionType — Transaction state: transactionId, chargingState, stoppedReason
• ChargingScheduleType — Time-based power/current limits with periods
• IdTokenInfoType — Authorization result: status, cacheExpiryDateTime, groupIdToken

Escalation Model

When implementing OCPP behavior, you will encounter areas where the specification does not fully define what to do. These are categorized as:

SPEC-SILENT

The OCPP specification does not define behavior for this case. You MUST flag this to the developer. Do NOT silently pick a default.

VENDOR-DEPENDENT

Behavior depends on the Charging Station hardware or firmware. Ask which hardware/firmware is targeted.

POLICY-DEPENDENT

Behavior depends on business rules, site configuration, or grid operator requirements. Ask about the business/operational context.

Escalation Strictness

Check the developer's project CLAUDE.md for escalation preferences. They may write something like:

For OCPP: use pragmatic escalation mode.

or:

OCPP escalation: strict — always ask before assuming spec-silent behavior.

Two modes:

• strict (default): Stop and ask the developer before proceeding. Present specific options. Do not write code for the ambiguous area until answered.
• pragmatic: Flag the ambiguity but pick a reasonable default. Leave a visible annotation:

  // OCPP SPEC-SILENT: [description of assumption]. Verify this matches your requirements.
  

If no escalation preference is found in CLAUDE.md, default to strict.

Documentation File Map

When you need detailed field-level schemas, sequence diagrams, or worked examples, read the relevant file from the plugin's docs/ directory. Use ${CLAUDE_PLUGIN_ROOT} to resolve the path.

How to use the file map

1. Identify the topic from the developer's question
2. Read the relevant file(s) using the Read tool
3. Cite specific fields, constraints, and enum values from the docs
4. Flag any ESCALATE markers you encounter in the docs

Topic argument routing

If invoked with /ocpp <topic>, immediately read the relevant files:

OCPP 2.1 topics:

• /ocpp 2.1 or /ocpp 2.1 overview → read OCPP-2.1.md overview
• /ocpp 2.1 migration → read OCPP-2.1.md (contains migration guide from 2.0.1)
• /ocpp 2.1 der or /ocpp 2.1 der-control → read OCPP-2.1-DERControl/OCPP-2.1-DERControl.md + OCPP-2.1-Schemas/OCPP-2.1-Schemas-DERControl.md
• /ocpp 2.1 v2x or /ocpp 2.1 bidirectional → read OCPP-2.1-Bidirectional/OCPP-2.1-Bidirectional.md + OCPP-2.1-Schemas/OCPP-2.1-Schemas-Bidirectional.md
• /ocpp 2.1 tariff or /ocpp 2.1 cost → read OCPP-2.1-TariffCost/OCPP-2.1-TariffCost.md + OCPP-2.1-Schemas/OCPP-2.1-Schemas-TariffAndCost.md
• /ocpp 2.1 device-model → read OCPP-2.1-DeviceModel/OCPP-2.1-DeviceModel.md
• /ocpp 2.1 enums or /ocpp 2.1 enumerations → read OCPP-2.1-Enumerations/OCPP-2.1-Enumerations.md
• /ocpp 2.1 use-cases → read OCPP-2.1-UseCases/OCPP-2.1-UseCases.md
• /ocpp 2.1 certification → read OCPP-2.1-Certification/OCPP-2.1-Certification.md
• /ocpp 2.1 schemas → read all 19 files in OCPP-2.1-Schemas/
• /ocpp 2.1 smart-charging → read OCPP-2.1-SmartCharging/OCPP-2.1-SmartCharging.md + OCPP-2.1-Schemas/OCPP-2.1-Schemas-SmartCharging.md
• /ocpp 2.1 sequences → read OCPP-2.1-Sequences/OCPP-2.1-Sequences.md
• /ocpp 2.1 types or /ocpp 2.1 data-types → read OCPP-2.1-DataTypes.md

OCPP 1.6J topics:

• /ocpp 1.6 or /ocpp 1.6j → read OCPP-1.6J.md overview
• /ocpp 1.6 smart-charging → read 1.6J SmartCharging schemas + deep-dive
• /ocpp 1.6 schemas → read all 1.6J Schema files
• /ocpp 1.6 sequences → read 1.6J Sequences file
• /ocpp 1.6 core → read 1.6J Core schemas
• /ocpp 1.6 firmware → read 1.6J Firmware schemas
• /ocpp 1.6 auth-list → read 1.6J LocalAuthList schemas
• /ocpp 1.6 reservation → read 1.6J Reservation schemas

OCPP 2.0.1 topics (default):

• /ocpp smart-charging → read all 3 SmartCharging files
• /ocpp authorize or /ocpp authorization → read Authorization schemas
• /ocpp transactions → read Transaction schemas + Sequences
• /ocpp provisioning or /ocpp boot → read Provisioning schemas + Sequences
• /ocpp schemas → read all Schema files
• /ocpp sequences → read both Sequence files
• /ocpp types or /ocpp data-types → read DataTypes
• /ocpp device-model → read OCPP-2.0.1-DeviceModel/OCPP-2.0.1-DeviceModel.md
• /ocpp enums or /ocpp enumerations → read OCPP-2.0.1-Enumerations/OCPP-2.0.1-Enumerations.md
• /ocpp firmware → read Firmware schemas + Operational sequences
• /ocpp diagnostics → read Diagnostics schemas + Operational sequences
• /ocpp reservation → read Reservation schemas
• /ocpp display → read Display schemas
• /ocpp security or /ocpp certificates → read Security schemas
• /ocpp availability → read Availability schemas
• Any other topic → search across all docs using grep

Behavioral Guidelines

1. Always cite the source. When referencing a field, type, or constraint, mention which doc it comes from. Distinguish schema-derived facts (high confidence) from AI interpretation (lower confidence).

2. Respect the escalation model. When you encounter an > **ESCALATE:** marker in the docs, follow the escalation strictness rules above.

3. Detect version from context. Use the version detection rules above. If the code uses StartTransaction/StopTransaction, it's 1.6J — read 1.6J docs. If it uses SetDERControl, GetTariffs, BatterySwap, OpenPeriodicEventStream, the subprotocol ocpp2.1, or schema URNs containing :2:2025:, it's 2.1 — read 2.1 docs. If it uses TransactionEvent without 2.1 indicators, it's 2.0.1. If no version indicators are present, assume 2.0.1 and mention the assumption.

4. Don't invent protocol behavior. If you're unsure whether something is spec-defined, check the docs first. If the docs don't cover it, say so explicitly rather than guessing.

5. Use the schemas for validation. When the developer writes OCPP message payloads, validate field names, types, required/optional status, and constraints against the schema docs.