ocpp

---
name: "ocpp"
description: "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."
license: "Apache-2.0"
---

# 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.

| Topic | File to read |
|-------|-------------|
| **All shared data types (enums + composites)** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-DataTypes.md` |
| **Device model (components + variables catalog)** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-DeviceModel/OCPP-2.0.1-DeviceModel.md` |
| **Open enumerations (units, security events, reason codes)** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Enumerations/OCPP-2.0.1-Enumerations.md` |
| **Authorization schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Authorization.md` |
| **Availability schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Availability.md` |
| **Diagnostics schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Diagnostics.md` |
| **Display schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Display.md` |
| **Firmware schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Firmware.md` |
| **Provisioning schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Provisioning.md` |
| **Reservation schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Reservation.md` |
| **Security schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Security.md` |
| **Smart Charging schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-SmartCharging.md` |
| **Transaction schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Schemas/OCPP-2.0.1-Schemas-Transactions.md` |
| **Boot, auth, transaction sequences** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Sequences/OCPP-2.0.1-Sequences.md` |
| **Offline, firmware, diagnostics sequences** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-Sequences/OCPP-2.0.1-Sequences-Operational.md` |
| **Smart Charging deep-dive** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-SmartCharging/OCPP-2.0.1-SmartCharging.md` |
| **Smart Charging worked examples** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-SmartCharging/OCPP-2.0.1-SmartCharging-Examples.md` |
| **ISO 15118 + Smart Charging** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1-SmartCharging/OCPP-2.0.1-SmartCharging-ISO15118.md` |
| **OCPP 2.0.1 overview + migration guide** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.0.1.md` |
| **Documentation methodology + trust model** | `${CLAUDE_PLUGIN_ROOT}/docs/METHODOLOGY.md` |
| | |
| **OCPP 2.1 overview + migration from 2.0.1** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1.md` |
| **OCPP 2.1 data types** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-DataTypes.md` |
| **OCPP 2.1 enumerations** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Enumerations/OCPP-2.1-Enumerations.md` |
| **OCPP 2.1 device model** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-DeviceModel/OCPP-2.1-DeviceModel.md` |
| **OCPP 2.1 DER control deep-dive** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-DERControl/OCPP-2.1-DERControl.md` |
| **OCPP 2.1 bidirectional / V2X deep-dive** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Bidirectional/OCPP-2.1-Bidirectional.md` |
| **OCPP 2.1 tariff & cost deep-dive** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-TariffCost/OCPP-2.1-TariffCost.md` |
| **OCPP 2.1 smart charging deep-dive** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-SmartCharging/OCPP-2.1-SmartCharging.md` |
| **OCPP 2.1 message sequences** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Sequences/OCPP-2.1-Sequences.md` |
| **OCPP 2.1 use cases** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-UseCases/OCPP-2.1-UseCases.md` |
| **OCPP 2.1 certification** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Certification/OCPP-2.1-Certification.md` |
| **OCPP 2.1 Authorization schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Authorization.md` |
| **OCPP 2.1 Availability schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Availability.md` |
| **OCPP 2.1 BatterySwap schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-BatterySwap.md` |
| **OCPP 2.1 Bidirectional schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Bidirectional.md` |
| **OCPP 2.1 Certificates schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Certificates.md` |
| **OCPP 2.1 DERControl schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-DERControl.md` |
| **OCPP 2.1 DataTransfer schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-DataTransfer.md` |
| **OCPP 2.1 Diagnostics schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Diagnostics.md` |
| **OCPP 2.1 Display schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Display.md` |
| **OCPP 2.1 Firmware schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Firmware.md` |
| **OCPP 2.1 LocalAuthList schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-LocalAuthList.md` |
| **OCPP 2.1 MeterValues schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-MeterValues.md` |
| **OCPP 2.1 Provisioning schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Provisioning.md` |
| **OCPP 2.1 RemoteControl schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-RemoteControl.md` |
| **OCPP 2.1 Reservation schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Reservation.md` |
| **OCPP 2.1 Security schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Security.md` |
| **OCPP 2.1 SmartCharging schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-SmartCharging.md` |
| **OCPP 2.1 TariffAndCost schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-TariffAndCost.md` |
| **OCPP 2.1 Transactions schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-2.1-Schemas/OCPP-2.1-Schemas-Transactions.md` |
| | |
| **OCPP 1.6J overview + config keys** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J.md` |
| **1.6J Core schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Schemas/OCPP-1.6J-Schemas-Core.md` |
| **1.6J Smart Charging schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Schemas/OCPP-1.6J-Schemas-SmartCharging.md` |
| **1.6J Firmware schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Schemas/OCPP-1.6J-Schemas-Firmware.md` |
| **1.6J Local Auth List schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Schemas/OCPP-1.6J-Schemas-LocalAuthList.md` |
| **1.6J Reservation schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Schemas/OCPP-1.6J-Schemas-Reservation.md` |
| **1.6J Remote Trigger schemas** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Schemas/OCPP-1.6J-Schemas-RemoteTrigger.md` |
| **1.6J Message sequences** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-Sequences/OCPP-1.6J-Sequences.md` |
| **1.6J Smart Charging deep-dive** | `${CLAUDE_PLUGIN_ROOT}/docs/OCPP-1.6J-SmartCharging/OCPP-1.6J-SmartCharging.md` |

### 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.