OCPP 1.6 Edition 2

Messages (PDU Field Definitions)

Based on Open Charge Point Protocol 1.6, Edition 2 FINAL (2017-09-28). Section 6 defines the field-level structure of every request (.req) and response (.conf) PDU in OCPP 1.6. This is the authoritative reference for what fields appear on the wire in each JSON message payload.

6 Sections

56 Message Definitions

28 Operations

1. Overview & Framing

Section 6

The payloads documented in this reference are the {Payload} portion of the OCPP-J RPC wrapper. This section summarizes transport-level context from the OCPP-J 1.6 Implementation Guide.

Cardinality notation: 1..1 = required (exactly one), 0..1 = optional (zero or one), 0..* = optional list, 1..* = required list (at least one).

OCPP-J RPC Message Framing

Every OCPP-J message on the wire is a JSON array in one of three forms:

CALL (Request)

MessageTypeId: 2

[2, "<UniqueId>", "<Action>", {...}]

CALLRESULT (Response)

MessageTypeId: 3

[3, "<UniqueId>", {...}]

CALLERROR (Error)

MessageTypeId: 4

[4, "<UniqueId>", "<ErrorCode>", ...]

Field	Rules
`UniqueId`	String, max 36 characters. Must be unique per CALL sender per connection. CALLRESULT/CALLERROR must echo the CALL's UniqueId.
`Action`	Case-sensitive OCPP operation name (e.g. "BootNotification", "Authorize"). Same as the SOAP Action without the leading /.
`ErrorDescription`	Human-readable string. Use "" (empty string) if not available.
`ErrorDetails`	JSON object. Must be {} if no details.

Important: Application-level rejections (e.g. status: "Rejected" in a BootNotification response) are valid CALLRESULT payloads — not CALLERRORs. CALLERROR is reserved for transport/protocol-level failures only.

Full CALL + CALLRESULT Exchange

// CP → CS: BootNotification CALL
[2, "19223201", "BootNotification", {"chargePointVendor":"VendorX","chargePointModel":"SingleSocketCharger"}]

// CS → CP: CALLRESULT
[3, "19223201", {"status":"Accepted","currentTime":"2025-01-15T10:30:00Z","interval":300}]

Note: Charge Point identity is NOT included in individual messages. It is established during the WebSocket handshake as part of the connection URL path (e.g. ws://server/ocpp/CP001) and is a property of the connection itself.

Synchronicity

A sender SHOULD NOT send a new CALL until all its previous CALLs have been responded to or timed out.

Timeout intervals are implementation-defined (mobile networks warrant longer timeouts than fixed-line).

A party can receive a CALL from the other side while waiting for a CALLRESULT/CALLERROR — implementations must handle this concurrent scenario.

When a message with an unknown MessageTypeNumber is received, it SHALL be ignored.

CALLERROR Error Codes

When a message cannot be processed due to transport or protocol issues, a CALLERROR is returned instead of a CALLRESULT:

Error Code	Description
`NotImplemented`	Requested Action is not known by the receiver.
`NotSupported`	Requested Action is recognized but not supported by the receiver.
`InternalError`	An internal error occurred; receiver could not process the Action.
`ProtocolError`	Payload for Action is incomplete.
`SecurityError`	A security issue occurred preventing the Action from completing.
`FormationViolation`	Payload is syntactically incorrect or does not conform to the PDU structure for the Action.
`PropertyConstraintViolation`	Payload is syntactically correct but at least one field contains an invalid value.
`OccurenceConstraintViolation`	Payload is syntactically correct but at least one field violates occurrence constraints.
`TypeConstraintViolation`	Payload is syntactically correct but at least one field violates data type constraints (e.g. "somestring": 12).
`GenericError`	Any other error not covered by the above.

JSON Schema Validation Rules

All OCPP 1.6 message payloads are validated against JSON Schema (draft-04). Key rules from the official schemas:

No additional properties

Every schema specifies "additionalProperties": false. Payloads MUST NOT include fields beyond those defined for the message. Unknown fields cause schema validation failure.

Empty payloads

Use {} (empty JSON object), not null.

Character encoding

The entire message (wrapper + payload) MUST be valid JSON encoded in UTF-8 (RFC 3629). Non-ASCII characters SHOULD only be used for natural-language text fields.

DateTime format

Fields marked dateTime use ISO 8601 format (e.g. "2025-01-15T10:30:00Z"), enforced by "format": "date-time" in the schema.

URI format

Fields marked anyURI (e.g. location in GetDiagnostics, UpdateFirmware) are enforced by "format": "uri" in the schema.

Decimal precision

Numeric fields with "multipleOf": 0.1 constraint (e.g. limit, minChargingRate in ChargingSchedule) enforce one-decimal-digit precision.

2. CP → CS Messages

Charge Point Initiated

These messages are initiated by the Charge Point and sent to the Central System. They cover authorization, boot notification, diagnostics, firmware status, heartbeat, metering, transactions, and status reporting.

Authorize

Section 4.1

Authorize.req

CP → CS

Field	Type	Card.	Constraints	Description
`idTag`	string	1..1	maxLength: 20	The identifier that needs to be authorized.

Authorize.req Example

{
  "idTag": "ABC12345"
}

Authorize.conf

CS → CP

Field	Type	Card.	Description
`idTagInfo`	IdTagInfo	1..1	Authorization status information.
`idTagInfo.status`	string (enum)	1..1	Authorization status.
`idTagInfo.expiryDate`	dateTime	0..1	Date/time after which the idTag expires.
`idTagInfo.parentIdTag`	string (max 20)	0..1	Parent identifier (for group authorization).

idTagInfo.status enum values:

Value	Description
`Accepted`	Identifier is allowed for charging.
`Blocked`	Identifier has been blocked. Not allowed for charging.
`Expired`	Identifier has expired. Not allowed for charging.
`Invalid`	Identifier is unknown. Not allowed for charging.
`ConcurrentTx`	Identifier is already involved in another transaction and multiple transactions are not allowed.

Authorize.conf Example

{
  "idTagInfo": {
    "status": "Accepted",
    "expiryDate": "2025-12-31T23:59:59Z",
    "parentIdTag": "PARENT001"
  }
}

BootNotification

Section 4.2

BootNotification.req

CP → CS

Field	Type	Card.	Constraints	Description
`chargePointModel`	string	1..1	maxLength: 20	Model of the Charge Point.
`chargePointVendor`	string	1..1	maxLength: 20	Vendor of the Charge Point.
`chargeBoxSerialNumber`	string	0..1	maxLength: 25	Serial number of the charge box. Deprecated.
`chargePointSerialNumber`	string	0..1	maxLength: 25	Serial number of the Charge Point.
`firmwareVersion`	string	0..1	maxLength: 50	Firmware version of the Charge Point.
`iccid`	string	0..1	maxLength: 20	ICCID of the modem's SIM card.
`imsi`	string	0..1	maxLength: 20	IMSI of the modem's SIM card.
`meterSerialNumber`	string	0..1	maxLength: 25	Serial number of the main power meter.
`meterType`	string	0..1	maxLength: 25	Type of the main power meter.

BootNotification.req Example

{
  "chargePointModel": "ModelX",
  "chargePointVendor": "VendorY",
  "chargePointSerialNumber": "SN123456",
  "firmwareVersion": "1.2.3"
}

BootNotification.conf

CS → CP

Field	Type	Card.	Description
`currentTime`	dateTime	1..1	Central System's current time.
`interval`	integer	1..1	Heartbeat/retry interval in seconds.
`status`	RegistrationStatus	1..1	Registration status.

RegistrationStatus enum values:

Value	Description
`Accepted`	Charge Point is accepted. Normal operation can begin.
`Pending`	CS is not yet ready to accept the CP. CP should retry after interval.
`Rejected`	Charge Point is not accepted. CP should retry after interval.

BootNotification.conf Example

{
  "currentTime": "2025-01-15T10:30:00Z",
  "interval": 300,
  "status": "Accepted"
}

Reconnect behavior: When a CP reconnects after a connection drop, it SHOULD NOT send a BootNotification unless one or more of the BootNotification fields have changed since the last successful connection.

DataTransfer (CP → CS)

Section 4.3

DataTransfer.req

CP → CS

Field	Type	Card.	Constraints	Description
`vendorId`	string	1..1	maxLength: 255	Identifies the vendor-specific implementation.
`messageId`	string	0..1	maxLength: 50	Additional identification for the message.
`data`	string	0..1	Unbounded	Vendor-specific data payload.

DataTransfer.req Example

{
  "vendorId": "com.example",
  "messageId": "GetCustomData",
  "data": "{\"foo\": \"bar\"}"
}

DataTransfer.conf

CS → CP

Field	Type	Card.	Description
`status`	DataTransferStatus	1..1	Status of the data transfer.
`data`	string	0..1	Response data (unbounded).

DataTransferStatus enum values:

Value	Description
`Accepted`	Message accepted and data processed.
`Rejected`	Message rejected by the recipient.
`UnknownMessageId`	The messageId is not recognized.
`UnknownVendorId`	The vendorId is not recognized.

DataTransfer.conf Example

{
  "status": "Accepted",
  "data": "{\"result\": \"ok\"}"
}

Note: DataTransfer is bidirectional -- it can be initiated by either the Charge Point or the Central System.

DiagnosticsStatusNotification

Section 4.4

DiagnosticsStatusNotification.req

CP → CS

Field	Type	Card.	Description
`status`	DiagnosticsStatus	1..1	Status of the diagnostics upload.

DiagnosticsStatus enum values:

Value	Description
`Idle`	Only used in response to TriggerMessage.
`Uploaded`	Diagnostics file has been uploaded successfully.
`UploadFailed`	Uploading of diagnostics file has failed.
`Uploading`	Diagnostics file is being uploaded.

DiagnosticsStatusNotification.req Example

{
  "status": "Uploaded"
}

DiagnosticsStatusNotification.conf

CS → CP

No fields. The response is an empty object.

DiagnosticsStatusNotification.conf Example

{}

FirmwareStatusNotification

Section 4.5

FirmwareStatusNotification.req

CP → CS

Field	Type	Card.	Description
`status`	FirmwareStatus	1..1	Status of the firmware update.

FirmwareStatus enum values:

Value	Description
`Downloaded`	Firmware has been downloaded successfully.
`DownloadFailed`	Firmware download has failed.
`Downloading`	Firmware is being downloaded.
`Idle`	Only used in response to TriggerMessage.
`InstallationFailed`	Firmware installation has failed.
`Installing`	Firmware is being installed.
`Installed`	Firmware has been installed successfully.

FirmwareStatusNotification.req Example

{
  "status": "Installed"
}

FirmwareStatusNotification.conf

CS → CP

No fields. The response is an empty object.

FirmwareStatusNotification.conf Example

{}

Heartbeat

Section 4.6

Heartbeat.req

CP → CS

No fields. The request is an empty object.

Heartbeat.req Example

{}

Heartbeat.conf

CS → CP

Field	Type	Card.	Description
`currentTime`	dateTime	1..1	Central System's current time (ISO 8601).

Heartbeat.conf Example

{
  "currentTime": "2025-01-15T10:30:00Z"
}

Note: WebSocket Ping/Pong frames can check connection liveness and keep NAT mappings alive, but they cannot replace the OCPP Heartbeat because only the Heartbeat response includes the Central System's current time for clock synchronization. Even when using WebSocket Ping/Pong, at least one OCPP Heartbeat per day is recommended.

MeterValues

Section 4.7

MeterValues.req

CP → CS

Field	Type	Card.	Constraints	Description
`connectorId`	integer	1..1	>= 0	Connector ID. 0 = main energy meter.
`transactionId`	integer	0..1		Transaction these values relate to.
`meterValue`	MeterValue[]	1..*		One or more sets of meter readings.

MeterValue class:

Field	Type	Card.	Description
`timestamp`	dateTime	1..1	When the values were captured.
`sampledValue`	SampledValue[]	1..*	One or more measured values at this point in time.

SampledValue class:

Field	Type	Card.	Default	Description
`value`	string	1..1	—	The measured value as a string.
`context`	ReadingContext	0..1	Sample.Periodic	Reason/event that triggered the reading.
`format`	ValueFormat	0..1	Raw	Raw = numeric, SignedData = signed binary.
`measurand`	Measurand	0..1	Energy.Active.Import.Register	Type of value being measured.
`phase`	Phase	0..1	—	Phase of the electric installation.
`location`	Location	0..1	Outlet	Where the measurement is taken.
`unit`	UnitOfMeasure	0..1	Wh	Unit of measure.

MeterValues.req Example

{
  "connectorId": 1,
  "transactionId": 12345,
  "meterValue": [
    {
      "timestamp": "2025-01-15T10:30:00Z",
      "sampledValue": [
        {
          "value": "1500",
          "measurand": "Energy.Active.Import.Register",
          "unit": "Wh"
        },
        {
          "value": "230.1",
          "measurand": "Voltage",
          "phase": "L1-N",
          "unit": "V"
        }
      ]
    }
  ]
}

MeterValues.conf

CS → CP

No fields. The response is an empty object.

MeterValues.conf Example

{}

StartTransaction

Section 4.8

StartTransaction.req

CP → CS

Field	Type	Card.	Constraints	Description
`connectorId`	integer	1..1	> 0	Connector where the transaction started.
`idTag`	string	1..1	maxLength: 20	Identifier that authorized the transaction.
`meterStart`	integer	1..1	Wh	Meter value in Wh at the start of the transaction.
`reservationId`	integer	0..1		ID of the reservation this transaction ends.
`timestamp`	dateTime	1..1		When the transaction started.

StartTransaction.req Example

{
  "connectorId": 1,
  "idTag": "ABC12345",
  "meterStart": 15000,
  "timestamp": "2025-01-15T10:30:00Z"
}

StartTransaction.conf

CS → CP

Field	Type	Card.	Description
`idTagInfo`	IdTagInfo	1..1	Authorization status information.
`transactionId`	integer	1..1	CS-assigned transaction ID.

StartTransaction.conf Example

{
  "idTagInfo": {
    "status": "Accepted"
  },
  "transactionId": 12345
}

StatusNotification

Section 4.9

StatusNotification.req

CP → CS

Field	Type	Card.	Constraints	Description
`connectorId`	integer	1..1	>= 0	Connector ID. 0 = main controller.
`errorCode`	ChargePointErrorCode	1..1		Error code reported by the Charge Point.
`info`	string	0..1	maxLength: 50	Additional free-format information.
`status`	ChargePointStatus	1..1		Current status of the connector.
`timestamp`	dateTime	0..1		Time of status change.
`vendorId`	string	0..1	maxLength: 255	Vendor-specific identifier.
`vendorErrorCode`	string	0..1	maxLength: 50	Vendor-specific error code.

ChargePointErrorCode enum values:

Value	Description
`ConnectorLockFailure`	Failure to lock or unlock connector.
`EVCommunicationError`	Communication failure with the EV.
`GroundFailure`	Ground fault circuit interrupter has been activated.
`HighTemperature`	Temperature inside Charge Point is too high.
`InternalError`	Error in internal hardware or software component.
`LocalListConflict`	The authorization information received is in conflict with the Local Authorization List.
`NoError`	No error to report.
`OtherError`	Other type of error.
`OverCurrentFailure`	Over current protection device has tripped.
`OverVoltage`	Voltage has risen above an acceptable level.
`PowerMeterFailure`	Failure to read power meter.
`PowerSwitchFailure`	Failure to control power switch.
`ReaderFailure`	Failure with idTag reader.
`ResetFailure`	Unable to perform a reset.
`UnderVoltage`	Voltage has dropped below an acceptable level.
`WeakSignal`	Wireless communication device reports a weak signal.

ChargePointStatus enum values:

Value	Category	Description
`Available`	Operative	Connector is available for a new user.
`Preparing`	Operative	Connector is preparing for charging (e.g., user is authorized but not yet plugged in).
`Charging`	Operative	Connector is actively charging an EV.
`SuspendedEVSE`	Operative	Charging has been suspended by the EVSE.
`SuspendedEV`	Operative	Charging has been suspended by the EV.
`Finishing`	Operative	Transaction has stopped but connector is not yet available.
`Reserved`	Operative	Connector is reserved for a particular idTag.
`Unavailable`	Inoperative	Connector is not available for charging (e.g., maintenance).
`Faulted`	Inoperative	Connector has encountered an error and is not available.

StatusNotification.req Example

{
  "connectorId": 1,
  "errorCode": "NoError",
  "status": "Available",
  "timestamp": "2025-01-15T10:30:00Z"
}

StatusNotification.conf

CS → CP

No fields. The response is an empty object.

StatusNotification.conf Example

{}

Note: For the CP main controller (connectorId = 0), the valid statuses are a subset: Available, Unavailable, and Faulted.

StopTransaction

Section 4.10

StopTransaction.req

CP → CS

Field	Type	Card.	Constraints	Description
`idTag`	string	0..1	maxLength: 20	Identifier that requested stop. Optional if stopped locally or by CS.
`meterStop`	integer	1..1	Wh	Meter value in Wh at the end of the transaction.
`timestamp`	dateTime	1..1		When the transaction was stopped.
`transactionId`	integer	1..1		Transaction ID of the transaction to stop.
`reason`	Reason	0..1		Reason for stopping the transaction.
`transactionData`	MeterValue[]	0..*		Detailed meter data collected during the transaction.

Reason enum values:

Value	Description
`DeAuthorized`	The transaction was stopped because of deauthorization.
`EmergencyStop`	Emergency stop button was used.
`EVDisconnected`	EV disconnected from the charging station.
`HardReset`	A hard reset command was received.
`Local`	Stopped locally on request of the user at the Charge Point.
`Other`	Any other reason.
`PowerLoss`	Complete loss of power.
`Reboot`	A locally initiated reboot/restart.
`Remote`	Stopped remotely on request of the user via the Central System.
`SoftReset`	A soft reset command was received.
`UnlockCommand`	Central System sent an Unlock Connector command.

StopTransaction.req Example

{
  "transactionId": 12345,
  "idTag": "ABC12345",
  "meterStop": 16500,
  "timestamp": "2025-01-15T11:30:00Z",
  "reason": "Local",
  "transactionData": [
    {
      "timestamp": "2025-01-15T11:00:00Z",
      "sampledValue": [
        {
          "value": "15700",
          "measurand": "Energy.Active.Import.Register",
          "unit": "Wh"
        }
      ]
    }
  ]
}

StopTransaction.conf

CS → CP

Field	Type	Card.	Description
`idTagInfo`	IdTagInfo	0..1	Authorization status information. Only present if an idTag was provided in the request.

StopTransaction.conf Example

{
  "idTagInfo": {
    "status": "Accepted"
  }
}

3. CS → CP Messages

Central System Initiated

These messages are initiated by the Central System and sent to the Charge Point. The Charge Point processes the request and returns a confirmation response.

CancelReservation

6.5 - 6.6

CancelReservation.req

CS → CP

Field	Type	Card.	Description
`reservationId`	integer	1..1	Id of the reservation to cancel.

CancelReservation.req Example

{
  "reservationId": 42
}

CancelReservation.conf

CP → CS

Field	Type	Card.	Description
`status`	CancelReservationStatus	1..1	Whether the cancellation succeeded.

CancelReservationStatus enum:

Value	Description
`Accepted`	Reservation has been cancelled.
`Rejected`	Reservation could not be cancelled.

CancelReservation.conf Example

{
  "status": "Accepted"
}

ChangeAvailability

6.7 - 6.8

ChangeAvailability.req

CS → CP

Field	Type	Card.	Description
`connectorId`	integer (>= 0)	1..1	Connector to change. Id 0 = entire Charge Point and all connectors.
`type`	AvailabilityType	1..1	The type of availability change to perform.

AvailabilityType enum:

Value	Description
`Inoperative`	Charge point is not available for charging.
`Operative`	Charge point is available for charging.

ChangeAvailability.req Example

{
  "connectorId": 1,
  "type": "Operative"
}

ChangeAvailability.conf

CP → CS

AvailabilityStatus enum:

Value	Description
`Accepted`	Request accepted and will be executed.
`Rejected`	Request not accepted.
`Scheduled`	Request accepted; will execute when transaction(s) in progress finish.

ChangeAvailability.conf Example

{
  "status": "Accepted"
}

ChangeConfiguration

6.9 - 6.10

ChangeConfiguration.req

CS → CP

Field	Type	Card.	Description
`key`	string (max 50)	1..1	Name of the configuration setting to change.
`value`	string (max 500)	1..1	New value for the setting.

ChangeConfiguration.req Example

{
  "key": "HeartbeatInterval",
  "value": "300"
}

ChangeConfiguration.conf

CP → CS

ConfigurationStatus enum:

Value	Description
`Accepted`	Configuration key is supported and setting has been changed.
`Rejected`	Configuration key is supported, but setting could not be changed.
`RebootRequired`	Setting changed, but only takes effect after reboot.
`NotSupported`	Configuration key is not supported.

ChangeConfiguration.conf Example

{
  "status": "Accepted"
}

AuthorizationKey handling: The configuration key AuthorizationKey is special — its value is a 40-character hexadecimal representation of the 20-byte authentication key used for HTTP Basic Auth. The CP SHOULD NOT return the actual AuthorizationKey value in response to GetConfiguration. After a successful key change, the Central System closes the WebSocket connection and the CP reconnects using the new credentials.

ClearCache

6.11 - 6.12

ClearCache.req

CS → CP

No fields defined. The payload is an empty object.

ClearCache.req Example

{}

ClearCache.conf

CP → CS

ClearCacheStatus enum:

Value	Description
`Accepted`	Command has been executed.
`Rejected`	Command has not been executed.

ClearCache.conf Example

{
  "status": "Accepted"
}

ClearChargingProfile

6.13 - 6.14

ClearChargingProfile.req

CS → CP

Field	Type	Card.	Description
`id`	integer	0..1	The ID of the charging profile to clear.
`connectorId`	integer	0..1	Connector for which to clear profiles. 0 = overall Charge Point.
`chargingProfilePurpose`	ChargingProfilePurposeType	0..1	Filter by purpose.
`stackLevel`	integer	0..1	Filter by stack level.

ClearChargingProfile.req Example

{
  "id": 5
}

ClearChargingProfile.conf

CP → CS

ClearChargingProfileStatus enum:

Value	Description
`Accepted`	Request accepted and will be executed.
`Unknown`	No Charging Profile(s) found matching the request.

ClearChargingProfile.conf Example

{
  "status": "Accepted"
}

DataTransfer (CS → CP)

6.15 - 6.16

Note: DataTransfer is the only action that can be initiated by either side. The message structure is identical to the CP-initiated variant.

DataTransfer.req

CS → CP

Field	Type	Card.	Description
`vendorId`	string (max 255)	1..1	Identifies the Vendor specific implementation.
`messageId`	string (max 50)	0..1	Additional identification field.
`data`	string	0..1	Data without specified length or format.

DataTransfer.req Example

{
  "vendorId": "com.example",
  "messageId": "CustomCommand",
  "data": "{\"action\": \"reboot_modem\"}"
}

DataTransfer.conf

CP → CS

DataTransferStatus enum:

Value	Description
`Accepted`	Message accepted and request is accepted.
`Rejected`	Message accepted but request is rejected.
`UnknownMessageId`	Message could not be interpreted due to unknown messageId.
`UnknownVendorId`	Message could not be interpreted due to unknown vendorId.

DataTransfer.conf Example

{
  "status": "Accepted",
  "data": "{\"result\": \"ok\"}"
}

GetCompositeSchedule

6.21 - 6.22

GetCompositeSchedule.req

CS → CP

Field	Type	Card.	Description
`connectorId`	integer	1..1	Connector ID. 0 = calculate for grid connection.
`duration`	integer	1..1	Time in seconds — length of requested schedule.
`chargingRateUnit`	ChargingRateUnitType	0..1	Force power (W) or current (A) profile.

GetCompositeSchedule.req Example

{
  "connectorId": 1,
  "duration": 3600
}

GetCompositeSchedule.conf

CP → CS

Field	Type	Card.	Description
`status`	GetCompositeScheduleStatus	1..1	Whether the CP could process the request.
`connectorId`	integer	0..1	The connector the schedule applies to.
`scheduleStart`	dateTime	0..1	Start point for schedule periods.
`chargingSchedule`	ChargingSchedule	0..1	Planned Composite Charging Schedule.

GetCompositeSchedule.conf Example

{
  "status": "Accepted",
  "connectorId": 1,
  "scheduleStart": "2025-01-15T10:00:00Z",
  "chargingSchedule": {
    "chargingRateUnit": "W",
    "chargingSchedulePeriod": [
      { "startPeriod": 0, "limit": 11000.0 },
      { "startPeriod": 1800, "limit": 7400.0 }
    ]
  }
}

GetConfiguration

6.23 - 6.24

GetConfiguration.req

CS → CP

Field	Type	Card.	Description
`key`	string[] (max 50 each)	0..*	List of keys to retrieve. If absent, all keys are returned.

GetConfiguration.req Example

{
  "key": ["HeartbeatInterval", "MeterValueSampleInterval"]
}

GetConfiguration.conf

CP → CS

Field	Type	Card.	Description
`configurationKey`	KeyValue[]	0..*	List of requested or known keys.
`unknownKey`	string[] (max 50)	0..*	Requested keys that are unknown.

KeyValue class:

Field	Type	Card.	Description
`key`	string (max 50)	1..1	Configuration key name.
`readonly`	boolean	1..1	false if the value can be set with ChangeConfiguration.
`value`	string (max 500)	0..1	The configuration value. May be absent if not set.

GetConfiguration.conf Example

{
  "configurationKey": [
    { "key": "HeartbeatInterval", "readonly": false, "value": "300" },
    { "key": "NumberOfConnectors", "readonly": true, "value": "2" }
  ],
  "unknownKey": ["NonExistentKey"]
}

GetDiagnostics

6.25 - 6.26

GetDiagnostics.req

CS → CP

Field	Type	Card.	Description
`location`	anyURI	1..1	URI where the diagnostics file shall be uploaded.
`retries`	integer	0..1	How many times to retry uploading.
`retryInterval`	integer	0..1	Interval in seconds between retry attempts.
`startTime`	dateTime	0..1	Oldest logging information to include.
`stopTime`	dateTime	0..1	Latest logging information to include.

GetDiagnostics.req Example

{
  "location": "ftp://diagnostics.example.com/uploads/",
  "retries": 3,
  "retryInterval": 60
}

GetDiagnostics.conf

CP → CS

Field	Type	Card.	Description
`fileName`	string (max 255)	0..1	Name of the diagnostics file to be uploaded. Absent when no diagnostics available.

GetDiagnostics.conf Example

{
  "fileName": "diagnostics-20250115.log"
}

GetLocalListVersion

6.27 - 6.28

GetLocalListVersion.req

CS → CP

No fields defined. The payload is an empty object.

GetLocalListVersion.req Example

{}

GetLocalListVersion.conf

CP → CS

Field	Type	Card.	Description
`listVersion`	integer	1..1	Current version number of the local authorization list.

GetLocalListVersion.conf Example

{
  "listVersion": 5
}

RemoteStartTransaction

6.33 - 6.34

RemoteStartTransaction.req

CS → CP

Field	Type	Card.	Description
`connectorId`	integer	0..1	Connector on which to start. SHALL be > 0.
`idTag`	string (max 20)	1..1	Identifier for the transaction.
`chargingProfile`	ChargingProfile	0..1	Charging Profile to use. Purpose MUST be TxProfile.

RemoteStartTransaction.req Example

{
  "connectorId": 1,
  "idTag": "ABC12345"
}

RemoteStartTransaction.conf

CP → CS

RemoteStartStopStatus enum:

Value	Description
`Accepted`	Command will be executed.
`Rejected`	Command will not be executed.

RemoteStartTransaction.conf Example

{
  "status": "Accepted"
}

RemoteStopTransaction

6.35 - 6.36

RemoteStopTransaction.req

CS → CP

Field	Type	Card.	Description
`transactionId`	integer	1..1	The transaction to stop.

RemoteStopTransaction.req Example

{
  "transactionId": 12345
}

RemoteStopTransaction.conf

CP → CS

RemoteStopTransaction.conf Example

{
  "status": "Accepted"
}

ReserveNow

6.37 - 6.38

ReserveNow.req

CS → CP

Field	Type	Card.	Description
`connectorId`	integer (>= 0)	1..1	Connector to reserve. 0 = reserve the CP itself.
`expiryDate`	dateTime	1..1	When the reservation ends.
`idTag`	string (max 20)	1..1	Identifier for which to reserve.
`parentIdTag`	string (max 20)	0..1	The parent idTag.
`reservationId`	integer	1..1	Unique id for this reservation.

ReserveNow.req Example

{
  "connectorId": 1,
  "expiryDate": "2025-01-15T12:00:00Z",
  "idTag": "ABC12345",
  "reservationId": 42
}

ReserveNow.conf

CP → CS

ReservationStatus enum:

Value	Description
`Accepted`	Reservation has been made.
`Faulted`	Connectors or specified connector are in a faulted state.
`Occupied`	All connectors or the specified connector are occupied.
`Rejected`	Charge Point is not configured to accept reservations.
`Unavailable`	Connectors or specified connector are in an unavailable state.

ReserveNow.conf Example

{
  "status": "Accepted"
}

Reset

6.39 - 6.40

Reset.req

CS → CP

Field	Type	Card.	Description
`type`	ResetType	1..1	The type of reset to perform.

ResetType enum:

Value	Description
`Hard`	Full reboot of the Charge Point (like a power cycle).
`Soft`	Restart the application software only.

Reset.req Example

{
  "type": "Soft"
}

Reset.conf

CP → CS

ResetStatus enum:

Value	Description
`Accepted`	CP will perform the reset.
`Rejected`	CP is unable to perform the reset.

Reset.conf Example

{
  "status": "Accepted"
}

SendLocalList

6.41 - 6.42

SendLocalList.req

CS → CP

Field	Type	Card.	Description
`listVersion`	integer	1..1	Version number of the list after update.
`localAuthorizationList`	AuthorizationData[]	0..*	List of authorization data entries.
`updateType`	UpdateType	1..1	Type of update (Full or Differential).

AuthorizationData class:

Field	Type	Card.	Description
`idTag`	string (max 20)	1..1	The identifier to which this authorization applies.
`idTagInfo`	IdTagInfo	0..1	Required when updateType is Full. For Differential: if present, add/update; if absent, delete.

UpdateType enum:

Value	Description
`Differential`	Only changes (additions/updates/deletions) are sent.
`Full`	The complete list is sent; replaces the entire local list.

SendLocalList.req Example

{
  "listVersion": 6,
  "updateType": "Full",
  "localAuthorizationList": [
    {
      "idTag": "ABC12345",
      "idTagInfo": { "status": "Accepted" }
    }
  ]
}

SendLocalList.conf

CP → CS

UpdateStatus enum:

Value	Description
`Accepted`	Local Authorization List successfully updated.
`Failed`	Failed to update the Local Authorization List.
`NotSupported`	Update of Local Authorization List is not supported.
`VersionMismatch`	Version mismatch for differential update.

SendLocalList.conf Example

{
  "status": "Accepted"
}

Note: If no (empty) localAuthorizationList is given and updateType is Full, all identifications are removed from the list. Requesting a Differential update without localAuthorizationList will have no effect. All idTags in the list MUST be unique.

SetChargingProfile

6.43 - 6.44

SetChargingProfile.req

CS → CP

Field	Type	Card.	Description
`connectorId`	integer	1..1	Connector to apply the profile to. 0 = overall limit.
`csChargingProfiles`	ChargingProfile	1..1	The charging profile to set.

SetChargingProfile.req Example

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

SetChargingProfile.conf

CP → CS

ChargingProfileStatus enum:

Value	Description
`Accepted`	Request accepted and will be executed.
`Rejected`	Request not accepted and will not be executed.
`NotSupported`	Charge Point indicates the request is not supported.

SetChargingProfile.conf Example

{
  "status": "Accepted"
}

TriggerMessage

6.51 - 6.52

TriggerMessage.req

CS → CP

Field	Type	Card.	Description
`requestedMessage`	MessageTrigger	1..1	The message to trigger.
`connectorId`	integer (> 0)	0..1	Only for connector-specific requests.

MessageTrigger enum:

Value	Description
`BootNotification`	Trigger a BootNotification request.
`DiagnosticsStatusNotification`	Trigger a DiagnosticsStatusNotification request.
`FirmwareStatusNotification`	Trigger a FirmwareStatusNotification request.
`Heartbeat`	Trigger a Heartbeat request.
`MeterValues`	Trigger a MeterValues request.
`StatusNotification`	Trigger a StatusNotification request.

TriggerMessage.req Example

{
  "requestedMessage": "StatusNotification",
  "connectorId": 1
}

TriggerMessage.conf

CP → CS

TriggerMessageStatus enum:

Value	Description
`Accepted`	Requested notification will be sent.
`Rejected`	Requested notification will not be sent.
`NotImplemented`	Requested notification is not implemented.

TriggerMessage.conf Example

{
  "status": "Accepted"
}

UnlockConnector

6.53 - 6.54

UnlockConnector.req

CS → CP

Field	Type	Card.	Description
`connectorId`	integer (> 0)	1..1	Identifier of the connector to be unlocked.

UnlockConnector.req Example

{
  "connectorId": 1
}

UnlockConnector.conf

CP → CS

UnlockStatus enum:

Value	Description
`Unlocked`	Connector has been unlocked.
`UnlockFailed`	Failed to unlock the connector.
`NotSupported`	Charge Point has no connector lock.

UnlockConnector.conf Example

{
  "status": "Unlocked"
}

UpdateFirmware

6.55 - 6.56

UpdateFirmware.req

CS → CP

Field	Type	Card.	Description
`location`	anyURI	1..1	URI pointing to the firmware location.
`retries`	integer	0..1	How many times to retry downloading.
`retrieveDate`	dateTime	1..1	Date/time after which to retrieve the firmware.
`retryInterval`	integer	0..1	Interval in seconds between retry attempts.

UpdateFirmware.req Example

{
  "location": "https://firmware.example.com/cp-firmware-v2.0.bin",
  "retrieveDate": "2025-01-16T02:00:00Z",
  "retries": 3,
  "retryInterval": 300
}

UpdateFirmware.conf

CP → CS

No fields defined. The payload is an empty object.

UpdateFirmware.conf Example

{}

4. Shared Complex Types

Reference

Several OCPP 1.6 messages reference the same complex data types. This section documents each shared type, its fields, and the enumeration values they use.

IdTagInfo

Complex Type

Contains status information about an identifier. Returned in Authorize, StartTransaction, and StopTransaction responses.

Fields

Field	Type	Card.	Description
`status`	AuthorizationStatus	1..1	Current status of the identifier.
`expiryDate`	dateTime	0..1	Date/time after which the idTag should be considered expired.
`parentIdTag`	string	0..1	Parent identifier for group authorization. Max 20 characters.

AuthorizationStatus enum values

Value	Description
`Accepted`	Identifier is allowed for charging.
`Blocked`	Identifier has been blocked. Not allowed for charging.
`Expired`	Identifier has expired. Not allowed for charging.
`Invalid`	Identifier is unknown. Not allowed for charging.
`ConcurrentTx`	Identifier is already in another transaction and multiple transactions are not allowed. Only relevant for StartTransaction.

Note: The ConcurrentTx status is only relevant in the context of a StartTransaction.conf. If the Charge Point supports the Authorization Cache, it should update its cache entry with the received IdTagInfo.

ChargingProfile

Complex Type

A ChargingProfile consists of a charging schedule, a stacking level, and optional validity period boundaries. Used in SetChargingProfile, RemoteStartTransaction, and GetCompositeSchedule operations.

Fields

Field	Type	Card.	Description
`chargingProfileId`	integer	1..1	Unique identifier for this charging profile.
`transactionId`	integer	0..1	Only valid if chargingProfilePurpose is TxProfile.
`stackLevel`	integer	1..1	Value >= 0. Higher stackLevel has higher priority when profiles of the same purpose overlap.
`chargingProfilePurpose`	ChargingProfilePurposeType	1..1	Defines the purpose of the charging profile.
`chargingProfileKind`	ChargingProfileKindType	1..1	Indicates the kind of schedule.
`recurrencyKind`	RecurrencyKindType	0..1	Indicates the start point of a recurrence.
`validFrom`	dateTime	0..1	Point in time at which the profile starts to be valid.
`validTo`	dateTime	0..1	Point in time at which the profile stops being valid.
`chargingSchedule`	ChargingSchedule	1..1	Contains limits for the available power or current over time.

ChargingProfilePurposeType enum values

Value	Description
`ChargePointMaxProfile`	Max power or current for an entire Charge Point.
`TxDefaultProfile`	Default profile for new transactions.
`TxProfile`	Profile for a specific transaction. Ceases to be valid when the transaction terminates.

ChargingProfileKindType enum values

Value	Description
`Absolute`	Schedule periods are relative to a fixed point in time defined in the schedule.
`Recurring`	The schedule restarts periodically at the first schedule period.
`Relative`	Schedule periods are relative to a situation-specific start point e.g. start of a Transaction.

RecurrencyKindType enum values

Value	Description
`Daily`	The schedule restarts every 24 hours.
`Weekly`	The schedule restarts every 7 days.

Note: When multiple profiles of the same purpose overlap, the profile with the highest stackLevel takes precedence. A TxProfile is automatically invalidated when its associated transaction terminates.

ChargingSchedule

Complex Type

Defines the charging schedule with a list of time-based periods. Each period specifies a power or current limit that applies from its start until the next period begins.

Fields

Field	Type	Card.	Description
`duration`	integer	0..1	Duration of the charging schedule in seconds.
`startSchedule`	dateTime	0..1	Starting point of an absolute schedule.
`chargingRateUnit`	ChargingRateUnitType	1..1	The unit of measure for limit values.
`chargingSchedulePeriod`	ChargingSchedulePeriod[]	1..*	List of charging schedule periods defining power or current limits.
`minChargingRate`	number	0..1	Minimum charging rate supported by the EV. multipleOf 0.1. In the unit defined by chargingRateUnit.

ChargingRateUnitType enum values

Value	Description
`W`	Watts - power. Total allowed charging power. More convenient for DC charging.
`A`	Amperes - current. Per phase, not sum of all phases. More convenient for AC charging.

Important: The startPeriod of the first ChargingSchedulePeriod element SHALL always be 0.

ChargingSchedulePeriod

Complex Type

Defines a single period within a ChargingSchedule, specifying the power or current limit and the number of phases to use during that period.

Fields

Field	Type	Card.	Description
`startPeriod`	integer	1..1	Start of the period, in seconds from the start of schedule. The startPeriod of the first element SHALL always be 0.
`limit`	number	1..1	Charging rate limit during the schedule period, in the unit defined by chargingRateUnit (W or A). multipleOf 0.1.
`numberPhases`	integer	0..1	The number of phases that can be used for charging. Default: 3.

Note: When numberPhases is absent, the Charge Point assumes 3-phase charging. The limit value is expressed in Watts (W) or Amperes (A) depending on the chargingRateUnit defined in the parent ChargingSchedule.

5. Metering Enumerations

Reference

This section documents all metering enumerations used in SampledValue fields within MeterValue objects in OCPP 1.6. Each enumeration constrains the allowed values for a specific field of the SampledValue type.

Measurand

Defines what is being measured. Default: Energy.Active.Import.Register.

Value	Description
`Current.Export`	Instantaneous current flow from EV.
`Current.Import`	Instantaneous current flow to EV.
`Current.Offered`	Maximum current offered to EV.
`Energy.Active.Export.Register`	Active energy exported Wh/kWh — register value.
`Energy.Active.Import.Register`	Active energy imported Wh/kWh — register value. DEFAULT.
`Energy.Reactive.Export.Register`	Reactive energy exported VARh/kVARh — register value.
`Energy.Reactive.Import.Register`	Reactive energy imported VARh/kVARh — register value.
`Energy.Active.Export.Interval`	Active energy exported during interval.
`Energy.Active.Import.Interval`	Active energy imported during interval.
`Energy.Reactive.Export.Interval`	Reactive energy exported during interval.
`Energy.Reactive.Import.Interval`	Reactive energy imported during interval.
`Frequency`	Powerline frequency, always in Hertz.
`Power.Active.Export`	Instantaneous active power exported by EV (W or kW).
`Power.Active.Import`	Instantaneous active power imported by EV (W or kW).
`Power.Factor`	Instantaneous power factor.
`Power.Offered`	Maximum power offered to EV.
`Power.Reactive.Export`	Instantaneous reactive power exported by EV (var or kvar).
`Power.Reactive.Import`	Instantaneous reactive power imported by EV (var or kvar).
`RPM`	Fan speed in RPM.
`SoC`	State of charge of vehicle in percentage.
`Temperature`	Temperature reading inside Charge Point.
`Voltage`	Instantaneous AC RMS supply voltage.

Important: All "Register" values MUST be monotonically increasing in time. "Import" refers to energy flow from Grid to Charge Point / EV. "Export" refers to energy flow from EV to Charge Point / Grid.

ReadingContext

Describes why the value was sampled. Default: Sample.Periodic.

Value	Description
`Interruption.Begin`	Value taken at start of interruption.
`Interruption.End`	Value taken when resuming after interruption.
`Sample.Clock`	Value taken at clock aligned interval.
`Sample.Periodic`	Value taken as periodic sample relative to start of transaction. DEFAULT.
`Transaction.Begin`	Value taken at start of transaction.
`Transaction.End`	Value taken at end of transaction.
`Trigger`	Value taken in response to a TriggerMessage.req.
`Other`	Value for any other situations.

ValueFormat

Specifies how the measured value is encoded in the value field.

Value	Description
`Raw`	Data is a regular string containing a decimal value.
`SignedData`	Data is represented as a signed binary data block encoded as hex.

Location

Indicates where the measurement was taken. Default: Outlet.

Value	Description
`Body`	Measurement inside body of Charge Point (e.g. Temperature).
`Cable`	Measurement taken from cable between EV and Charge Point.
`EV`	Measurement taken by EV.
`Inlet`	Measurement at network "grid" inlet connection.
`Outlet`	Measurement at a Connector. DEFAULT.

Phase

Indicates which phase of the electrical installation the value was measured on. If absent, the value represents the overall aggregate across all phases.

Value	Description
`L1`	Measured on L1.
`L2`	Measured on L2.
`L3`	Measured on L3.
`N`	Measured on Neutral.
`L1-N`	Measured on L1 with respect to Neutral.
`L2-N`	Measured on L2 with respect to Neutral.
`L3-N`	Measured on L3 with respect to Neutral.
`L1-L2`	Measured between L1 and L2.
`L2-L3`	Measured between L2 and L3.
`L3-L1`	Measured between L3 and L1.

UnitOfMeasure

Specifies the unit of the measured value. Default: Wh.

Value	Description
`Wh`	Watt-hours energy. DEFAULT.
`kWh`	Kilowatt-hours energy.
`varh`	Var-hours reactive energy.
`kvarh`	Kilovar-hours reactive energy.
`W`	Watts power.
`kW`	Kilowatts power.
`VA`	Volt-Amperes apparent power.
`kVA`	Kilovolt-Amperes apparent power.
`var`	Vars reactive power.
`kvar`	Kilovars reactive power.
`A`	Amperes current.
`V`	Volts voltage.
`K`	Kelvin temperature.
`Celcius`	Degrees Celsius temperature. Note: This is the original OCPP 1.6 spelling, a known typo.
`Celsius`	Degrees Celsius temperature. Added as corrected spelling; both forms are valid per the JSON schema.
`Fahrenheit`	Degrees Fahrenheit temperature.
`Percent`	Percentage.

Note: The value Celcius (missing an 's') is the original spelling in the OCPP 1.6 specification and is a known typo. The corrected spelling Celsius was added later. Both forms are valid per the JSON schema and implementations SHOULD accept either.

6. Quick Reference

Summary

Empty Payloads

Messages with no fields defined (empty {} payload):

Message	Direction
`ClearCache.req`	CS → CP
`GetLocalListVersion.req`	CS → CP
`Heartbeat.req`	CP → CS
`DiagnosticsStatusNotification.conf`	CS → CP
`FirmwareStatusNotification.conf`	CS → CP
`MeterValues.conf`	CS → CP
`StatusNotification.conf`	CS → CP
`UpdateFirmware.conf`	CP → CS

All Actions by Direction

Charge Point → Central System (CP-initiated)

Action	Request	Response
Authorize	`Authorize.req`	`Authorize.conf`
BootNotification	`BootNotification.req`	`BootNotification.conf`
DataTransfer	`DataTransfer.req`	`DataTransfer.conf`
DiagnosticsStatusNotification	`DiagnosticsStatusNotification.req`	`DiagnosticsStatusNotification.conf`
FirmwareStatusNotification	`FirmwareStatusNotification.req`	`FirmwareStatusNotification.conf`
Heartbeat	`Heartbeat.req`	`Heartbeat.conf`
MeterValues	`MeterValues.req`	`MeterValues.conf`
StartTransaction	`StartTransaction.req`	`StartTransaction.conf`
StatusNotification	`StatusNotification.req`	`StatusNotification.conf`
StopTransaction	`StopTransaction.req`	`StopTransaction.conf`

Central System → Charge Point (CS-initiated)

Action	Request	Response
CancelReservation	`CancelReservation.req`	`CancelReservation.conf`
ChangeAvailability	`ChangeAvailability.req`	`ChangeAvailability.conf`
ChangeConfiguration	`ChangeConfiguration.req`	`ChangeConfiguration.conf`
ClearCache	`ClearCache.req`	`ClearCache.conf`
ClearChargingProfile	`ClearChargingProfile.req`	`ClearChargingProfile.conf`
DataTransfer	`DataTransfer.req`	`DataTransfer.conf`
GetCompositeSchedule	`GetCompositeSchedule.req`	`GetCompositeSchedule.conf`
GetConfiguration	`GetConfiguration.req`	`GetConfiguration.conf`
GetDiagnostics	`GetDiagnostics.req`	`GetDiagnostics.conf`
GetLocalListVersion	`GetLocalListVersion.req`	`GetLocalListVersion.conf`
RemoteStartTransaction	`RemoteStartTransaction.req`	`RemoteStartTransaction.conf`
RemoteStopTransaction	`RemoteStopTransaction.req`	`RemoteStopTransaction.conf`
ReserveNow	`ReserveNow.req`	`ReserveNow.conf`
Reset	`Reset.req`	`Reset.conf`
SendLocalList	`SendLocalList.req`	`SendLocalList.conf`
SetChargingProfile	`SetChargingProfile.req`	`SetChargingProfile.conf`
TriggerMessage	`TriggerMessage.req`	`TriggerMessage.conf`
UnlockConnector	`UnlockConnector.req`	`UnlockConnector.conf`
UpdateFirmware	`UpdateFirmware.req`	`UpdateFirmware.conf`

Note: DataTransfer is the only action that can be initiated by either side.