The Developer's Guide to OCPP 1.6J

OCPP 1.6J — Open Charge Point Protocol 1.6 (JSON over WebSocket)

Purpose: This file provides structured context about OCPP 1.6J for AI agents working on EV charging infrastructure. It is not a replacement for the official specification but a practical reference to ground AI-assisted development, integration, and troubleshooting.

Spec covered: OCPP 1.6 Edition 2 (2017-09-28), JSON over WebSocket transport

1. What is OCPP 1.6J?

OCPP 1.6 is the most widely deployed version of the Open Charge Point Protocol. It defines communication between a Charge Point and a Central System for managing EV charging infrastructure.

The "J" suffix denotes the JSON-over-WebSocket transport binding (as opposed to the SOAP/HTTP binding). JSON is the dominant transport for OCPP 1.6 in practice.

Edition 2 (published 2017-09-28) is the current revision. It clarified ambiguities from Edition 1 and is the edition referenced throughout this document.

The specification is maintained by the Open Charge Alliance (OCA).

2. Architecture

2.1 Roles

• Charge Point (CP): The physical device that charges EVs. Initiates the WebSocket connection.
• Central System (CS): The backend server that manages Charge Points remotely.

Important terminology note: OCPP 1.6 uses "Charge Point" and "Central System." The terms "Charging Station" and "CSMS" are OCPP 2.0.1 terms and do not apply to 1.6.

2.2 Connector Model

Charge Point → Connector 1 (e.g., Type 2), Connector 2 (e.g., CCS), ...

• A Charge Point has one or more Connectors, each identified by a connectorId (1-indexed integer).
• connectorId=0 refers to the Charge Point as a whole (used in messages like ChangeAvailability, StatusNotification, and MeterValues).
• There is no EVSE concept in 1.6. The EVSE abstraction layer was introduced in OCPP 2.0.1.

2.3 Transport

• WebSocket (RFC 6455), typically over TLS (wss://)
• Sub-protocol: ocpp1.6
• The Charge Point connects to the Central System at a URL like: wss://cs.example.com/ocpp/<charge_point_id>
• The Charge Point ID is included in the WebSocket URL path.

2.4 Message Frame

OCPP 1.6J uses a JSON-RPC-like message framing. There are three message types:

CALL (Request):

[2, "<messageId>", "<action>", {<payload>}]

CALLRESULT (Response):

[3, "<messageId>", {<payload>}]

CALLERROR (Error Response):

[4, "<messageId>", "<errorCode>", "<errorDescription>", {<errorDetails>}]

• messageId is a unique string that correlates a CALL with its CALLRESULT or CALLERROR.
• Only one CALL can be outstanding at a time per direction (CP->CS or CS->CP).
• Both sides can initiate CALLs independently since the connection is bidirectional.
• Standard error codes: NotImplemented, NotSupported, InternalError, ProtocolError, SecurityError, FormationViolation, PropertyConstraintViolation, OccurenceConstraintViolation, TypeConstraintViolation, GenericError.

3. Feature Profiles

OCPP 1.6 organizes its 28 messages into 6 Feature Profiles. The Core profile is required; all others are optional. A Charge Point advertises its supported profiles via the SupportedFeatureProfiles configuration key.

4. All 28 Messages

4.1 Core (16 messages)

4.2 Firmware Management (4 messages)

4.3 Local Auth List Management (2 messages)

4.4 Reservation (2 messages)

4.5 Smart Charging (3 messages)

4.6 Remote Trigger (1 message)

4.7 Common Patterns

Boot Sequence

1. CP→CS: [WebSocket connect]
2. CP→CS: BootNotification.req(chargePointModel, chargePointVendor)
3. CS→CP: BootNotification.conf(status=Accepted|Pending|Rejected, interval, currentTime)
4. CP→CS: StatusNotification.req(connectorId=N, status, errorCode) [for each connector]
5. CP→CS: Heartbeat.req() [every interval seconds]

If BootNotification.conf returns Pending, the CP must retry after the given interval and must not send any messages other than BootNotification until it receives Accepted. If Rejected, the CP should retry at the given interval.

Transaction Lifecycle (typical flow)

1. User presents RFID -> CP sends Authorize.req with idTag
2. CS responds Authorize.conf with idTagInfo.status=Accepted
3. User plugs in cable -> CP sends StatusNotification (Preparing)
4. CP sends StartTransaction.req (connectorId, idTag, meterStart, timestamp)
5. CS responds StartTransaction.conf with transactionId and idTagInfo
6. CP sends StatusNotification (Charging)
7. During charging -> periodic MeterValues.req (every MeterValueSampleInterval seconds)
8. User stops -> CP sends StopTransaction.req (transactionId, meterStop, timestamp, reason)
9. CP sends StatusNotification (Finishing -> Available)

StopTransaction reasons: EmergencyStop, EVDisconnected, HardReset, Local, Other, PowerLoss, Reboot, Remote, SoftReset, UnlockCommand, DeAuthorized.

Smart Charging Profile Structure

{
  "connectorId": 1,
  "csChargingProfiles": {
    "chargingProfileId": 1,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxDefaultProfile",
    "chargingProfileKind": "Recurring",
    "recurrencyKind": "Daily",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 32.0 },
        { "startPeriod": 28800, "limit": 16.0 },
        { "startPeriod": 72000, "limit": 32.0 }
      ]
    }
  }
}

Profile purposes (stack priority, highest first):

• ChargePointMaxProfile — Max power for the entire Charge Point (connectorId=0 only).
• TxDefaultProfile — Default for transactions on a Connector.
• TxProfile — Specific to an active transaction.

Profiles at the same purpose level use stackLevel to determine priority (higher wins).

Offline Behavior

When the CP loses connection to the CS:

• It should queue transaction-related messages (StartTransaction, StopTransaction, MeterValues) and replay them in order upon reconnection.
• TransactionMessageAttempts and TransactionMessageRetryInterval control retry behavior.
• It can use the Local Authorization List or Authorization Cache for offline authorization.
• LocalAuthorizeOffline enables transaction start for locally-known IDs.
• AllowOfflineTxForUnknownId (when supported) enables transaction start for unknown IDs while offline.

5. Connector Status Model

The status of a Connector is reported via StatusNotification. OCPP 1.6 defines 9 statuses:

Historical note: OCPP 1.5 used a single Occupied status. In OCPP 1.6, this was split into the five statuses Preparing, Charging, SuspendedEV, SuspendedEVSE, and Finishing to provide more granular visibility into the charging session lifecycle.

Typical Status Flow

• Normal flow: Available → Preparing → Charging → Finishing → Available
• Suspend variations: Charging ↔ SuspendedEV, Charging ↔ SuspendedEVSE

A StatusNotification also carries a ChargePointErrorCode field. When the status is not Faulted, this is set to NoError. Error codes include: ConnectorLockFailure, EVCommunicationError, GroundFailure, HighTemperature, InternalError, LocalListConflict, OtherError, OverCurrentFailure, OverVoltage, PowerMeterFailure, PowerSwitchFailure, ReaderFailure, ResetFailure, UnderVoltage, WeakSignal.

6. Configuration Keys Reference

OCPP 1.6 uses a flat key-value configuration model accessed via GetConfiguration and ChangeConfiguration. Keys are grouped by Feature Profile.

6.1 Core Profile

6.2 Local Auth List Management Profile

6.3 Reservation Profile

6.4 Smart Charging Profile

7. Key Differences from OCPP 2.0.1

7.1 Terminology Mapping

7.2 Structural Differences