OCPP 1.6 Edition 2

Operations Initiated by Central System

Based on OCPP 1.6 Edition 2 Specification (Section 5). This guide covers all operations that the Central System (CSMS) initiates and sends to the Charge Point, including configuration, remote control, reservations, smart charging, and firmware management.

19 Operations

6 Feature Profiles

Section 5.1 - 5.19

1. Overview

Section 5

All operations in this section are initiated by the Central System (CSMS) and sent to the Charge Point. The Central System sends a CALL [2, messageId, action, payload] and the Charge Point responds with a CALLRESULT [3, messageId, payload].

This section covers 19 operations organized across multiple OCPP 1.6 Feature Profiles including Core, Smart Charging, Firmware Management, Local Auth List Management, Reservation, and Remote Trigger.

#	Operation	Feature Profile
`5.1`	Cancel Reservation	Reservation
`5.2`	Change Availability	Core
`5.3`	Change Configuration	Core
`5.4`	Clear Cache	Core
`5.5`	Clear Charging Profile	Smart Charging
`5.6`	Data Transfer	Core
`5.7`	Get Composite Schedule	Smart Charging
`5.8`	Get Configuration	Core
`5.9`	Get Diagnostics	Firmware Management
`5.10`	Get Local List Version	Local Auth List Management
`5.11`	Remote Start Transaction	Core
`5.12`	Remote Stop Transaction	Core
`5.13`	Reserve Now	Reservation
`5.14`	Reset	Core
`5.15`	Send Local List	Local Auth List Management
`5.16`	Set Charging Profile	Smart Charging
`5.17`	Trigger Message	Remote Trigger
`5.18`	Unlock Connector	Core
`5.19`	Update Firmware	Firmware Management

2. Cancel Reservation

5.1 Reservation

Cancel an existing reservation on a Charge Point.

Central System --> CancelReservation.req --> Charge Point --> CancelReservation.conf --> Central System

Request: CancelReservation.req

Field	Type	Required	Description
`reservationId`	integer	Yes	ID of the reservation to cancel

Response: CancelReservation.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected	Whether the CP had a matching reservation

Behavior

If the Charge Point has a reservation matching the reservationId, it SHALL return Accepted.
Otherwise it SHALL return Rejected.
When a reservation is cancelled successfully, the Charge Point SHALL make the connector available again and send a StatusNotification.req to the Central System indicating the connector's new status (typically Available).

JSON Examples

Request

[2, "msg-001", "CancelReservation", {
  "reservationId": 42
}]

Response

[3, "msg-001", {
  "status": "Accepted"
}]

3. Change Availability

5.2 Core

Request a Charge Point to change its availability. A Charge Point is considered available ("operative") when it is charging or ready for charging. A Charge Point is considered unavailable when it does not allow any charging.

Central System --> ChangeAvailability.req --> Charge Point --> ChangeAvailability.conf --> Central System

Request: ChangeAvailability.req

Field	Type	Required	Values	Description
`connectorId`	integer	Yes	0 = entire CP, >0 = specific	The connector to change. 0 applies to entire Charge Point
`type`	string	Yes	Inoperative Operative	Operative = available for charging, Inoperative = unavailable

Response: ChangeAvailability.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected Scheduled	Whether the change was applied or will be applied

Behavior

Accepted: The CP can change to the requested availability immediately.
Rejected: The CP cannot change availability.
Scheduled: A transaction is in progress on the connector (or on one of the connectors when connectorId = 0); the change will apply after the transaction finishes.
If the CP is already in the requested state, it SHALL respond with Accepted.
When connectorId = 0, the status change applies to the entire Charge Point and all its Connectors. If a transaction is in progress on any connector, the CP SHALL respond with Scheduled for the whole request.
The Unavailable/Inoperative status MUST be persistent across reboots (the CP SHALL remember this state after a reset).
After availability changes, the Charge Point SHALL send a StatusNotification.req to inform the Central System.
When a connector is made Inoperative while it is in the Preparing state (cable plugged in but no transaction started), the Charge Point SHOULD report the connector as Available when the cable is unplugged, and then transition to Unavailable.
An individual connector set to Inoperative SHALL NOT be considered available for new transactions, even when the Charge Point as a whole is Operative.

JSON Examples

Request

[2, "msg-002", "ChangeAvailability", {
  "connectorId": 1,
  "type": "Inoperative"
}]

Response

[3, "msg-002", {
  "status": "Accepted"
}]

4. Change Configuration

5.3 Core

Change a configuration parameter on the Charge Point.

Central System --> ChangeConfiguration.req --> Charge Point --> ChangeConfiguration.conf --> Central System

Request: ChangeConfiguration.req

Field	Type	Required	Max Length	Description
`key`	string	Yes	50	Name of the configuration key
`value`	string	Yes	500	New value for the configuration

Response: ChangeConfiguration.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected RebootRequired NotSupported	Result of the configuration change

Behavior

Content of "key" and "value" is not prescribed by the specification.
Accepted: The change was applied successfully and is effective immediately.
RebootRequired: The change was applied successfully, but a reboot is needed to make it effective.
NotSupported: The "key" does not correspond to a configuration setting supported by the Charge Point.
Rejected: The Charge Point did not set the configuration. Examples include out-of-range values, values that do not conform to an expected format, or attempting to change a read-only key.
If a key is defined as a CSL (comma-separated list), it MAY be accompanied with a [KeyName]MaxLength key indicating the max length of the list. If this key is not set, a safe value of 1 item SHOULD be assumed.
If the configuration value exceeds the maximum length (500 characters), the Charge Point SHALL return Rejected.

JSON Examples

Request

[2, "msg-003", "ChangeConfiguration", {
  "key": "HeartbeatInterval",
  "value": "300"
}]

Response

[3, "msg-003", {
  "status": "Accepted"
}]

5. Clear Cache

5.4 Core

Clear the Charge Point's Authorization Cache.

Central System --> ClearCache.req --> Charge Point --> ClearCache.conf --> Central System

Request: ClearCache.req

No fields. Empty payload {}.

Response: ClearCache.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected	Whether the CP was able to clear the cache

Behavior

This clears the Authorization Cache on the Charge Point (not the Local Authorization List).
Accepted: The CP successfully cleared the authorization cache.
Rejected: The CP was unable to clear the cache, or does not implement an Authorization Cache.
When the Authorization Cache is not implemented and the CP receives a ClearCache.req, the CP SHALL respond with status Rejected (errata v4.0).
After clearing the cache, the next authorization attempt will require an Authorize.req to the Central System.
This does NOT affect the Local Authorization List (use SendLocalList with Full and an empty list for that).

JSON Examples

Request

[2, "msg-004", "ClearCache", {}]

Response

[3, "msg-004", {
  "status": "Accepted"
}]

6. Clear Charging Profile

5.5 Smart Charging

Clear some or all charging profiles that were previously sent to the Charge Point.

Central System --> ClearChargingProfile.req --> Charge Point --> ClearChargingProfile.conf --> Central System

Request: ClearChargingProfile.req

All fields are optional. At least one should be provided to identify which profiles to clear.

Field	Type	Required	Values	Description
`id`	integer	No		ID of the charging profile to clear
`connectorId`	integer	No		Connector for which to clear profiles
`chargingProfilePurpose`	string	No	ChargePointMaxProfile, TxDefaultProfile, TxProfile	Purpose of the profiles to clear
`stackLevel`	integer	No		Stack level of the profiles to clear

Response: ClearChargingProfile.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Unknown	Whether the CP was able to process the request

Behavior

If id is provided, the Charge Point SHALL clear the specific charging profile with that ID. All other filter fields are ignored (errata v4.0).
If id is not provided and one or more filter fields are specified, the Charge Point SHALL clear all charging profiles that match (logical AND) ALL of the provided filter criteria.
If no fields are specified at all, the Charge Point SHALL clear ALL charging profiles (errata v4.0).
Accepted: One or more matching charging profiles were cleared.
Unknown: No charging profile(s) matching the given criteria were found on the Charge Point.

JSON Examples

Request

[2, "msg-005", "ClearChargingProfile", {
  "connectorId": 1,
  "chargingProfilePurpose": "TxProfile"
}]

Response

[3, "msg-005", {
  "status": "Accepted"
}]

7. Data Transfer

5.6 Core

Send vendor-specific data to a Charge Point for functionality not covered by OCPP.

Central System --> DataTransfer.req --> Charge Point --> DataTransfer.conf --> Central System

Request: DataTransfer.req

Field	Type	Required	Max Length	Description
`vendorId`	string	Yes	255	Identifies the vendor-specific extension
`messageId`	string	No	50	Additional identification for the message
`data`	string	No	-	Data without specified length or format

Response: DataTransfer.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected UnknownMessageId UnknownVendorId	Result of the data transfer
`data`	string	No		Optional response data

Behavior

Identical message structure to the CP-initiated Data Transfer operation (section 4.3), but the direction is reversed (CSMS to CP).
The same JSON schemas (DataTransfer.json / DataTransferResponse.json) apply to both the CP-initiated and CS-initiated variants.
If the CP does not recognize the vendorId, it SHALL respond with UnknownVendorId.
If the CP recognizes the vendorId but not the messageId, it SHALL respond with UnknownMessageId.
The data field has no prescribed format or length limit in the schema; contents are vendor-specific.

JSON Examples

Request

[2, "msg-006", "DataTransfer", {
  "vendorId": "com.example",
  "messageId": "CustomCommand",
  "data": "{\"action\": \"reboot_modem\"}"
}]

Response

[3, "msg-006", {
  "status": "Accepted",
  "data": "{\"result\": \"ok\"}"
}]

8. Get Composite Schedule

5.7 Smart Charging

Request the Charge Point to report its Composite Charging Schedule for a given time period.

Central System --> GetCompositeSchedule.req --> Charge Point --> GetCompositeSchedule.conf --> Central System

Request: GetCompositeSchedule.req

Field	Type	Required	Values	Description
`connectorId`	integer	Yes		Connector to get the schedule for. 0 = entire CP consumption
`duration`	integer	Yes		Duration in seconds to report the schedule for
`chargingRateUnit`	string	No	A, W	Unit for the schedule: Amps or Watts

Response: GetCompositeSchedule.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted, Rejected	Whether the CP can report the schedule
`connectorId`	integer	No		The connector the schedule applies to
`scheduleStart`	string	No	dateTime	Start time of the schedule
`chargingSchedule`	object	No		The composite charging schedule (see below)

ChargingSchedule object

Field	Type	Required	Values	Description
`duration`	integer	No		Duration of the schedule in seconds
`startSchedule`	string	No	dateTime	Starting point of the schedule
`chargingRateUnit`	string	Yes	A, W	Unit of the charging rate limit
`chargingSchedulePeriod`	array	Yes		Array of ChargingSchedulePeriod objects
`minChargingRate`	number	No	0.1 step	Minimum charging rate supported

ChargingSchedulePeriod object

Field	Type	Required	Description
`startPeriod`	integer	Yes	Start of the period as offset from schedule start (seconds)
`limit`	number	Yes	Charging rate limit during this period (0.1 step)
`numberPhases`	integer	No	Number of phases to use for charging (default: 3)

Behavior

The schedule is calculated from the moment the request is received: Time X to X + Duration.
If connectorId is 0, the CP SHALL report total expected power/current from the grid for the period.
If the CP is not able to report the schedule (e.g., unknown connectorId), it SHALL respond with Rejected.
The charging schedule sent by the Charge Point is only indicative for that point in time. This schedule might change over time due to external causes.
The reported schedule is the result of the calculation of all active schedules and possible local limits present in the Charge Point.
If the optional chargingRateUnit is provided, the CP SHALL convert the schedule to the requested unit if possible. If it cannot convert, the CP MAY return Rejected.
If an invalid value for chargingRateUnit is used, the CP SHALL respond with a CALLERROR: PropertyConstraintViolation (errata v4.0).
The response fields connectorId, scheduleStart, and chargingSchedule SHALL only be present when status is Accepted.

JSON Examples

Request

[2, "msg-007", "GetCompositeSchedule", {
  "connectorId": 1,
  "duration": 3600,
  "chargingRateUnit": "A"
}]

Response

[3, "msg-007", {
  "status": "Accepted",
  "connectorId": 1,
  "scheduleStart": "2024-01-15T10:00:00Z",
  "chargingSchedule": {
    "chargingRateUnit": "A",
    "chargingSchedulePeriod": [
      {
        "startPeriod": 0,
        "limit": 32.0,
        "numberPhases": 3
      },
      {
        "startPeriod": 1800,
        "limit": 16.0,
        "numberPhases": 3
      }
    ]
  }
}]

9. Get Configuration

5.8 Core

Retrieve configuration settings from the Charge Point.

Central System --> GetConfiguration.req --> Charge Point --> GetConfiguration.conf --> Central System

Request: GetConfiguration.req

Field	Type	Required	Max Length	Description
`key`	array[string]	No	50 per item	List of keys to retrieve. If empty/omitted, return all

Response: GetConfiguration.conf

Field	Type	Required	Description
`configurationKey`	array[object]	No	List of known configuration keys with values
`unknownKey`	array[string]	No	List of requested keys that were not recognized

ConfigurationKey object

Field	Type	Required	Max Length	Description
`key`	string	Yes	50	The configuration key name
`readonly`	boolean	Yes		Whether the key is read-only
`value`	string	No	500	The current value (may be absent for write-only keys)

Behavior

If the key list in the request is empty or missing, the CP SHALL return ALL configuration settings.
Otherwise the CP SHALL return only the recognized keys with their values and read-only state.
Unrecognized keys go into the unknownKey list.
The maximum number of keys in a single PDU may be limited by the CP (see GetConfigurationMaxKeys config key).

JSON Examples

Request

[2, "msg-008", "GetConfiguration", {
  "key": [
    "HeartbeatInterval",
    "MeterValueSampleInterval",
    "UnknownKey"
  ]
}]

Response

[3, "msg-008", {
  "configurationKey": [
    {
      "key": "HeartbeatInterval",
      "readonly": false,
      "value": "300"
    },
    {
      "key": "MeterValueSampleInterval",
      "readonly": false,
      "value": "60"
    }
  ],
  "unknownKey": ["UnknownKey"]
}]

10. Get Diagnostics

5.9 Firmware Management

Request the Charge Point to upload its diagnostics to a specified location.

Central System --> GetDiagnostics.req --> Charge Point --> GetDiagnostics.conf --> Central System

Then: Charge Point uploads diagnostics file and sends DiagnosticsStatusNotification.req (status: Uploading, then Uploaded)

Request: GetDiagnostics.req

Field	Type	Required	Format	Description
`location`	string	Yes	uri	URI where the diagnostics file should be uploaded (e.g., FTP, HTTP, HTTPS)
`retries`	integer	No		Number of retries for the upload
`retryInterval`	integer	No		Interval in seconds between upload retries
`startTime`	string	No	dateTime	Start of the diagnostics period to collect
`stopTime`	string	No	dateTime	End of the diagnostics period to collect

Response: GetDiagnostics.conf

Field	Type	Required	Max Length	Description
`fileName`	string	No	255	Name of the file that will be uploaded. Empty if no diagnostics available

Behavior

If diagnostics info is available, the CP SHALL respond with the file name and begin uploading.
If no diagnostics file is available, the response SHALL NOT contain a file name.
During upload, the CP MUST send DiagnosticsStatusNotification.req PDUs to keep the Central System updated.
The CP SHALL upload a single file. Format is not prescribed.
If the upload fails after all retries, the CP SHALL send a DiagnosticsStatusNotification.req with status UploadFailed.
The DiagnosticsStatusNotification status values are: Idle, Uploaded, UploadFailed, Uploading.
The CP SHOULD NOT stop normal operations (like charging) while uploading diagnostics.

JSON Examples

Request

[2, "msg-009", "GetDiagnostics", {
  "location": "ftp://server.example.com/diagnostics/",
  "retries": 3,
  "retryInterval": 60,
  "startTime": "2024-01-14T00:00:00Z",
  "stopTime": "2024-01-15T00:00:00Z"
}]

Response

[3, "msg-009", {
  "fileName": "diagnostics-CP001-20240115.zip"
}]

11. Get Local List Version

5.10 Local Auth List Mgmt

Request the version number of the Local Authorization List on a Charge Point.

Central System --> GetLocalListVersion.req --> Charge Point --> GetLocalListVersion.conf --> Central System

Request: GetLocalListVersion.req

No fields. Empty payload {}.

Response: GetLocalListVersion.conf

Field	Type	Required	Description
`listVersion`	integer	Yes	Version of the local auth list. 0 = empty, -1 = not supported

Behavior

Version 0 means the local authorization list is empty.
Version -1 means the Charge Point does not support Local Authorization Lists.
Any positive integer indicates the version number of the currently installed list.
The Central System typically calls this before SendLocalList.req to determine if an update is needed and what listVersion to use.

JSON Examples

Request

[2, "msg-010", "GetLocalListVersion", {}]

Response

[3, "msg-010", {
  "listVersion": 5
}]

12. Remote Start Transaction

5.11 Core

Remotely start a charging transaction on a Charge Point.

Central System --> RemoteStartTransaction.req --> Charge Point --> RemoteStartTransaction.conf --> Central System

Request: RemoteStartTransaction.req

Field	Type	Required	Max Length	Description
`idTag`	string	Yes	20	The identifier to start the transaction with
`connectorId`	integer	No		Connector to start the transaction on (SHALL be > 0). If omitted, CP decides
`chargingProfile`	object	No		Charging profile to use for this transaction (see below)

ChargingProfile object (optional)

Field	Type	Required	Values	Description
`chargingProfileId`	integer	Yes		Unique identifier for this profile
`transactionId`	integer	No		Only for existing transactions (NOT set here)
`stackLevel`	integer	Yes		Priority level of this profile (higher = more priority)
`chargingProfilePurpose`	string	Yes	ChargePointMaxProfile, TxDefaultProfile, TxProfile	MUST be TxProfile for RemoteStart
`chargingProfileKind`	string	Yes	Absolute, Recurring, Relative	How the schedule is interpreted
`recurrencyKind`	string	No	Daily, Weekly	Required when kind is Recurring
`validFrom`	string	No	dateTime	Start of profile validity
`validTo`	string	No	dateTime	End of profile validity
`chargingSchedule`	object	Yes		The schedule (see ChargingSchedule)

Response: RemoteStartTransaction.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected	Whether the CP will attempt to start a transaction

Behavior

The CP SHALL reply indicating whether it has accepted the request and will attempt to start.
The effect depends on the AuthorizeRemoteTxRequests configuration key:

AuthorizeRemoteTxRequests = true

The CP SHALL behave as if in response to a local action. This means the CP will first try to authorize the idTag using the Local Authorization List, Authorization Cache and/or an Authorize.req request. A transaction will only be started after authorization was obtained.

AuthorizeRemoteTxRequests = false

The CP SHALL immediately try to start a transaction for the idTag. The Central System will check the authorization status of the idTag when processing the StartTransaction request.

The request SHALL contain an identifier (idTag), which the CP SHALL use to send a StartTransaction.req to Central System.
The request MAY contain a connector id. When no connector id is provided, the Charge Point is in control of the connector selection. A CP MAY reject a request without a connector id.
The Central System MAY include a ChargingProfile. The purpose SHALL be set to TxProfile. If accepted, the CP SHALL use this profile for the transaction.
If a CP without support for Smart Charging receives a request with a Charging Profile, this parameter SHOULD be ignored.

Use Cases

Enable a CPO operator to help an EV driver that has problems starting a transaction.
Enable mobile apps to control charging transactions via the Central System.
Enable the use of SMS to control charging transactions via the Central System.

JSON Examples

Request

[2, "msg-011", "RemoteStartTransaction", {
  "idTag": "RFID-TAG-001",
  "connectorId": 1
}]

Response

[3, "msg-011", {
  "status": "Accepted"
}]

Request with Charging Profile

[2, "msg-012", "RemoteStartTransaction", {
  "idTag": "RFID-TAG-001",
  "connectorId": 1,
  "chargingProfile": {
    "chargingProfileId": 100,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Relative",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 32.0 }
      ]
    }
  }
}]

13. Remote Stop Transaction

5.12 Core

Remotely stop an ongoing charging transaction.

Central System --> RemoteStopTransaction.req --> Charge Point --> RemoteStopTransaction.conf --> Central System

Request: RemoteStopTransaction.req

Field	Type	Required	Description
`transactionId`	integer	Yes	ID of the transaction to stop

Response: RemoteStopTransaction.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected	Whether the CP has the transaction and will stop it

Behavior

The CP SHALL reply indicating whether it has accepted the request and has an ongoing transaction with the given transactionId.
If the CP does not have a transaction with the given transactionId, it SHALL return Rejected.
This remote request to stop a transaction is equal to a local action to stop a transaction. Therefore, the transaction SHALL be stopped, the CP SHALL send a StopTransaction.req and, if applicable, unlock the connector.

Use Cases

Enable a CPO operator to help an EV driver that has problems stopping a transaction.
Enable mobile apps to control charging transactions via the Central System.

JSON Examples

Request

[2, "msg-013", "RemoteStopTransaction", {
  "transactionId": 12345
}]

Response

[3, "msg-013", {
  "status": "Accepted"
}]

14. Reserve Now

5.13 Reservation

Reserve a connector on a Charge Point for a specific idTag.

Central System --> ReserveNow.req --> Charge Point --> ReserveNow.conf --> Central System

Request: ReserveNow.req

Field	Type	Required	Max Length	Description
`connectorId`	integer	Yes		Connector to reserve. 0 = any connector (see behavior)
`expiryDate`	string	Yes		dateTime when the reservation expires
`idTag`	string	Yes	20	The identifier for which the connector is reserved
`parentIdTag`	string	No	20	Parent identifier (optional group token)
`reservationId`	integer	Yes		Unique identifier for this reservation

Response: ReserveNow.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Faulted Occupied Rejected Unavailable	Result of the reservation request

Behavior

Response status meanings:

Accepted: Reservation successfully made.
Occupied: The CP or specified connector is occupied, or already reserved for a different idTag.
Faulted: The CP or connector is in the Faulted state.
Unavailable: The CP or connector is in the Unavailable state.
Rejected: The CP is configured not to accept reservations.

ConnectorId = 0 (any connector):

Requires config key ReserveConnectorZeroSupported to be true.
The CP SHALL NOT reserve a specific connector, but SHALL ensure one connector remains available for the reserved idTag during the reservation validity.
If ReserveConnectorZeroSupported is not set or is false, the CP SHALL return Rejected.

Reservation enforcement:

Once a reservation is accepted, the CP SHALL refuse charging for all incoming idTags on the reserved connector, EXCEPT when the incoming idTag (or its parent idTag) matches the reservation.

Reservation termination conditions:

A transaction is started for the reserved idTag/parentIdTag on the reserved connector.
The expiryDate is reached.
The Charge Point or connector is set to Faulted or Unavailable.

If reservationId matches an existing reservation, the CP SHALL replace that reservation with the new one.
If a parentIdTag is provided, the CP MAY look it up in its Local Authorization List or Authorization Cache. If not found, it SHALL send an Authorize.req.
When a reservation expires, the CP SHALL terminate the reservation, make the connector available, and send a StatusNotification.req.
If a transaction starts for the reserved idTag, the CP SHALL include the reservationId in the StartTransaction.req.

JSON Examples

Request

[2, "msg-014", "ReserveNow", {
  "connectorId": 1,
  "expiryDate": "2024-01-15T12:00:00Z",
  "idTag": "RFID-TAG-001",
  "reservationId": 100
}]

Response

[3, "msg-014", {
  "status": "Accepted"
}]

15. Reset

5.14 Core

Request a Charge Point to reset itself (soft or hard).

Central System --> Reset.req --> Charge Point --> Reset.conf --> Central System

Request: Reset.req

Field	Type	Required	Values	Description
`type`	string	Yes	Hard Soft	Type of reset to perform

Response: Reset.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected	Whether the CP will attempt to reset itself

Behavior

Soft Reset

The CP SHALL gracefully stop ongoing transactions and send StopTransaction.req for each.
Then restart the application software (if possible) or restart the processor/controller.

Hard Reset

The CP SHALL restart all hardware.
Not required to gracefully stop ongoing transactions.
If possible, the CP sends StopTransaction.req for previously ongoing transactions after restarting and being accepted by the Central System via BootNotification.conf.
This is a last-resort solution. A "hard" reset may cause queued information to be lost.

After receiving Reset.req, the CP SHALL send StopTransaction.req for any ongoing transaction BEFORE performing the reset.
If the CP fails to receive StopTransaction.conf, it shall queue the StopTransaction.req.
Persistent states shall persist (e.g., connector set to Unavailable/Inoperative stays Unavailable/Inoperative).
After a reset, the CP SHALL send a BootNotification.req to re-establish the connection with the Central System.
A CP SHALL respond with Accepted when it can perform the reset. It SHALL respond with Rejected if it cannot.

JSON Examples

Request

[2, "msg-015", "Reset", {
  "type": "Soft"
}]

Response

[3, "msg-015", {
  "status": "Accepted"
}]

16. Send Local List

5.15 Local Auth List Mgmt

Send a Local Authorization List to the Charge Point for offline authorization of idTags.

Central System --> SendLocalList.req --> Charge Point --> SendLocalList.conf --> Central System

Request: SendLocalList.req

Field	Type	Required	Values	Description
`listVersion`	integer	Yes		Version number the CP MUST associate with the list after update
`updateType`	string	Yes	Differential, Full	Whether to replace the full list or apply a diff
`localAuthorizationList`	array[object]	No		List of authorization entries

AuthorizationData object

Field	Type	Required	Max Length	Description
`idTag`	string	Yes	20	The identifier
`idTagInfo`	object	No		Authorization info for this idTag (see below)

IdTagInfo object

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted, Blocked, Expired, Invalid, ConcurrentTx	Authorization status
`expiryDate`	string	No	dateTime	When the authorization expires
`parentIdTag`	string	No	max 20	Parent identifier for grouping

Response: SendLocalList.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Failed NotSupported VersionMismatch	Whether the CP accepted the list update

Behavior

Full update type replaces the entire current list on the CP.
Full update with an empty localAuthorizationList (or the field omitted) SHALL clear the entire local authorization list on the CP.
Differential update type applies changes to the current list:

An entry with both idTag and idTagInfo SHALL be added or updated.
An entry with only idTag (without idTagInfo) SHALL cause that idTag to be deleted.
A Differential update without localAuthorizationList will have no effect on the list.

All idTag values in the localAuthorizationList MUST be unique.
The CP MUST associate the list with the provided listVersion after a successful update.
If status is Failed or VersionMismatch and the updateType was Differential, the Central System SHOULD retry with updateType = Full.
The maximum number of entries is determined by the SendLocalListMaxLength configuration key.
NotSupported: The CP does not support Local Authorization Lists.
VersionMismatch: The version number provided is not sequential (for Differential: new = old + 1; for Full: new > old).

JSON Examples

Request (Full update)

[2, "msg-016", "SendLocalList", {
  "listVersion": 6,
  "updateType": "Full",
  "localAuthorizationList": [
    {
      "idTag": "RFID-001",
      "idTagInfo": {
        "status": "Accepted",
        "expiryDate": "2025-12-31T23:59:59Z"
      }
    },
    {
      "idTag": "RFID-002",
      "idTagInfo": {
        "status": "Blocked"
      }
    }
  ]
}]

Response

[3, "msg-016", {
  "status": "Accepted"
}]

17. Set Charging Profile

5.16 Smart Charging

Send a charging profile to a Charge Point to control the charging rate.

Central System --> SetChargingProfile.req --> Charge Point --> SetChargingProfile.conf --> Central System

Request: SetChargingProfile.req

Field	Type	Required	Description
`connectorId`	integer	Yes	Connector to apply the profile to. 0 = entire CP
`csChargingProfiles`	object	Yes	The charging profile to set (see below)

ChargingProfile object (csChargingProfiles)

Field	Type	Required	Values	Description
`chargingProfileId`	integer	Yes		Unique identifier for this profile
`transactionId`	integer	No		Transaction ID if profile is for a specific transaction
`stackLevel`	integer	Yes		Priority level
`chargingProfilePurpose`	string	Yes	ChargePointMaxProfile, TxDefaultProfile, TxProfile	Purpose of the profile
`chargingProfileKind`	string	Yes	Absolute, Recurring, Relative	How to interpret the schedule
`recurrencyKind`	string	No	Daily, Weekly	Required when kind is Recurring
`validFrom`	string	No	dateTime	Start of profile validity
`validTo`	string	No	dateTime	End of profile validity
`chargingSchedule`	object	Yes		The schedule (see ChargingSchedule)

ChargingSchedule object

Field	Type	Required	Values	Description
`duration`	integer	No		Duration of the schedule in seconds
`startSchedule`	string	No	dateTime	Starting point (required for Absolute kind)
`chargingRateUnit`	string	Yes	A, W	Unit of the charging rate limit
`chargingSchedulePeriod`	array	Yes		Array of ChargingSchedulePeriod objects
`minChargingRate`	number	No	0.1 step	Minimum charging rate supported

Response: SetChargingProfile.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected NotSupported	Whether the CP accepted the profile

Behavior

Response status meanings:

Accepted: The CP has accepted the charging profile and will apply it.
Rejected: The CP cannot accept this profile (e.g., invalid combination of connectorId and purpose, exceeds MaxChargingProfilesInstalled, invalid stackLevel, etc.).
NotSupported: The CP does not support Smart Charging (per errata v4.0, the CP SHOULD respond with a CALLERROR: NotSupported).

ConnectorId constraints per purpose:

ChargePointMaxProfile: connectorId MUST be 0. Limits total power/current from the grid.
TxDefaultProfile: Can be connectorId 0 (default for all connectors) or a specific connector.
TxProfile: Must be on a specific connector (> 0) that has an active transaction.

Profile replacement rules:

If a profile with the same chargingProfileId exists, the new one SHALL replace it.
If a profile with the same combination of stackLevel / ChargingProfilePurpose exists, the new one SHALL replace it.
Otherwise the new profile SHALL be added.

Important notes:

It is NOT possible to set a TxProfile without presence of an active transaction, or in advance of a transaction.
ChargingProfiles set via SetChargingProfile.req SHALL be persistent across reboots/power cycles (errata v4.0).
The maximum number of charging profiles is determined by the MaxChargingProfilesInstalled configuration key.
The stackLevel value range is 0 to the value of the ChargeProfileMaxStackLevel configuration key. Higher = more priority.
For Absolute kind: startSchedule is required. For Relative kind: startSchedule SHALL NOT be used. For Recurring kind: recurrencyKind MUST be set.
The first chargingSchedulePeriod.startPeriod SHALL always be 0.

Profile Scenarios

5.16.1

Setting a charging profile at start of transaction

If the CSMS receives a StartTransaction.req, it SHALL respond with StartTransaction.conf. If a charging profile is needed, the CSMS MAY send a SetChargingProfile.req.
It is RECOMMENDED to check the timestamp in the StartTransaction.req to verify the transaction is likely still ongoing (it might have been cached during an offline period).

5.16.2

Setting a charging profile in a RemoteStartTransaction request

The CSMS MAY include a charging profile in a RemoteStartTransaction request.
The ChargingProfilePurpose MUST be set to TxProfile and transactionId SHALL NOT be set.
The CP SHALL apply the profile to the newly started transaction.
When the CP receives a SetChargingProfile.req with the transactionId for this transaction and the same StackLevel, it SHALL replace the existing profile.

5.16.3

Setting a charging profile during a transaction

The CSMS MAY send a charging profile to update the profile for an ongoing transaction.
The chargingProfilePurpose MUST be set to TxProfile.
If a profile with the same chargingProfileId or same stackLevel/purpose exists, the new one SHALL replace it; otherwise it SHALL be added.
When a new or updated TxDefaultProfile is received, the transaction SHALL continue but switch to the new profile (errata v4.0).

5.16.4

Setting a charging profile outside of a transaction

The CSMS MAY send charging profiles to be used as default profiles. Such profiles MAY be sent at any time.
Same replacement rules apply: matching chargingProfileId or stackLevel/purpose replaces; otherwise the profile is added.

JSON Examples

Request

[2, "msg-017", "SetChargingProfile", {
  "connectorId": 1,
  "csChargingProfiles": {
    "chargingProfileId": 200,
    "transactionId": 12345,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Relative",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        {
          "startPeriod": 0,
          "limit": 32.0,
          "numberPhases": 3
        },
        {
          "startPeriod": 1800,
          "limit": 16.0,
          "numberPhases": 3
        }
      ]
    }
  }
}]

Response

[3, "msg-017", {
  "status": "Accepted"
}]

18. Trigger Message

5.17 Remote Trigger

Request the Charge Point to send a specific message that it would normally send during operation. This solves timing issues where the Central System has reason to doubt the last known state of the Charge Point.

Central System --> TriggerMessage.req --> Charge Point --> TriggerMessage.conf --> Central System

Request: TriggerMessage.req

Field	Type	Required	Values	Description
`requestedMessage`	string	Yes	BootNotification DiagnosticsStatusNotification FirmwareStatusNotification Heartbeat MeterValues StatusNotification	The message the CS wants the CP to send
`connectorId`	integer	No		Connector for which to send the message

Response: TriggerMessage.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Accepted Rejected NotImplemented	Whether the CP will send the requested message

Behavior

The CP SHALL first send the TriggerMessage.conf response, then send the requested message.
Accepted: The CP will send the requested message.
Rejected: The CP accepts the request type but declines to send it.
NotImplemented: The requested message is unknown or not implemented.
If the same message gets sent because of normal operations between accepting and sending, that message MAY be considered as complying with the request.
The connectorId is optional. If relevant but absent, the message should be sent for all connectors.
This mechanism is NOT for retrieving historic data; triggered messages SHALL contain current information only.
StartTransaction and StopTransaction are excluded from this mechanism (they describe transitions, not state).
A triggered MeterValues.req SHALL return the most recent measurements for all measurands configured in MeterValuesSampledData.
A triggered BootNotification.req SHALL contain the same parameters as the previous (or initial) BootNotification.req.
After the CP has been accepted via BootNotification.conf, the CP is RECOMMENDED to Reject a TriggerMessage.req for BootNotification (errata v4.0).
A triggered StatusNotification.req for connectorId 0 SHALL cause the CP to send a StatusNotification for the CP itself, plus one for each connector.
A triggered DiagnosticsStatusNotification.req SHALL return the current status of any diagnostics upload in progress (Idle if none).
A triggered FirmwareStatusNotification.req SHALL return the current status of any firmware update in progress (Idle if none).

JSON Examples

Request

[2, "msg-018", "TriggerMessage", {
  "requestedMessage": "StatusNotification",
  "connectorId": 1
}]

Response

[3, "msg-018", {
  "status": "Accepted"
}]

Then the CP sends

[2, "cp-msg-099", "StatusNotification", {
  "connectorId": 1,
  "errorCode": "NoError",
  "status": "Charging"
}]

19. Unlock Connector

5.18 Core

Unlock a connector's cable retention lock to help EV drivers unplug their cable.

Central System --> UnlockConnector.req --> Charge Point --> UnlockConnector.conf --> Central System

Request: UnlockConnector.req

Field	Type	Required	Description
`connectorId`	integer	Yes	The connector to unlock. MUST be > 0 (cannot be 0)

Response: UnlockConnector.conf

Field	Type	Required	Values	Description
`status`	string	Yes	Unlocked UnlockFailed NotSupported	Whether the connector was successfully unlocked

Behavior

This is intended ONLY for unlocking the cable retention lock, NOT for unlocking a connector access door.
UnlockConnector.req SHOULD NOT be used to remotely stop a running transaction; use RemoteStopTransaction instead.
Upon receipt, the CP SHALL respond indicating whether it could unlock the connector.
If there was a transaction in progress on the connector, the CP SHALL finish the transaction first by sending a StopTransaction.req with reason UnlockCommand, and then unlock the connector.
Unlocked: The connector cable lock was successfully unlocked.
UnlockFailed: The connector cable lock could not be unlocked (e.g., hardware failure).
NotSupported: The CP does not have a cable lock for the specified connector, or the connector does not exist.

Use Cases

Help EV drivers that have problems unplugging their cable due to cable retention lock malfunction.

JSON Examples

Request

[2, "msg-019", "UnlockConnector", {
  "connectorId": 1
}]

Response

[3, "msg-019", {
  "status": "Unlocked"
}]

20. Update Firmware

5.19 Firmware Management

Instruct a Charge Point to download and install new firmware.

Central System --> UpdateFirmware.req --> Charge Point --> UpdateFirmware.conf --> Central System

Then: CP waits until retrieveDate, downloads and installs firmware, sending FirmwareStatusNotification.req updates throughout.

Request: UpdateFirmware.req

Field	Type	Required	Format	Description
`location`	string	Yes	uri	URI from which to download the firmware (e.g., HTTP, HTTPS, FTP)
`retrieveDate`	string	Yes	dateTime	Date and time after which the CP should retrieve the firmware
`retries`	integer	No		Number of retries for the download
`retryInterval`	integer	No		Interval in seconds between download retries

Response: UpdateFirmware.conf

No fields. Empty payload {}.

Behavior

Firmware update sequence:

CP responds with UpdateFirmware.conf (empty).
CP waits until retrieveDate.
CP sends FirmwareStatusNotification.req with status Downloading.
CP downloads the firmware.
CP sends FirmwareStatusNotification.req with status Downloaded.
CP waits for ongoing transactions to finish (RECOMMENDED to wait until idle).
CP sends FirmwareStatusNotification.req with status Installing.
CP installs the firmware.
CP reboots (if needed) and sends BootNotification.req.
CP sends FirmwareStatusNotification.req with status Installed.

FirmwareStatusNotification status values:

DownloadedDownloadFailedDownloadingIdleInstallationFailedInstallingInstalled

Important notes:

The CP SHOULD start retrieving firmware as soon as possible after retrieveDate.
During download and installation, the CP MUST send FirmwareStatusNotification.req PDUs.
If the download fails after all retries, the CP SHALL send a FirmwareStatusNotification.req with status DownloadFailed.
If the firmware installation fails, the CP SHALL send InstallationFailed.
If charging cannot continue during installation, it is RECOMMENDED to wait until the CP is idle before installing.
It is RECOMMENDED to set connectors not in use to UNAVAILABLE while waiting for the session to end.
The CP SHALL NOT interrupt ongoing transactions for a firmware update, unless a hard reset is absolutely necessary.

JSON Examples

Request

[2, "msg-020", "UpdateFirmware", {
  "location": "https://firmware.example.com/v2.1.0/firmware.bin",
  "retrieveDate": "2024-01-16T03:00:00Z",
  "retries": 3,
  "retryInterval": 300
}]

Response

[3, "msg-020", {}]

21. Quick Reference

All Operations

Summary of all Section 5 operations initiated by the Central System.

#	Operation	Action Name	CSMS Sends	CP Responds With	Feature Profile
`5.1`	Cancel Reservation	`CancelReservation`	reservationId	status	Reservation
`5.2`	Change Availability	`ChangeAvailability`	connectorId, type	status	Core
`5.3`	Change Configuration	`ChangeConfiguration`	key, value	status	Core
`5.4`	Clear Cache	`ClearCache`	(empty)	status	Core
`5.5`	Clear Charging Profile	`ClearChargingProfile`	[id], [connectorId], ...	status	Smart Charging
`5.6`	Data Transfer	`DataTransfer`	vendorId, [messageId], [data]	status, [data]	Core
`5.7`	Get Composite Schedule	`GetCompositeSchedule`	connectorId, duration	status, [schedule]	Smart Charging
`5.8`	Get Configuration	`GetConfiguration`	[key]	[configurationKey], [unknownKey]	Core
`5.9`	Get Diagnostics	`GetDiagnostics`	location, ...	[fileName]	Firmware Mgmt
`5.10`	Get Local List Version	`GetLocalListVersion`	(empty)	listVersion	Local Auth List
`5.11`	Remote Start Transaction	`RemoteStartTransaction`	idTag, [connectorId], [chargingProfile]	status	Core
`5.12`	Remote Stop Transaction	`RemoteStopTransaction`	transactionId	status	Core
`5.13`	Reserve Now	`ReserveNow`	connectorId, expiryDate, idTag, reservationId	status	Reservation
`5.14`	Reset	`Reset`	type	status	Core
`5.15`	Send Local List	`SendLocalList`	listVersion, updateType, [list]	status	Local Auth List
`5.16`	Set Charging Profile	`SetChargingProfile`	connectorId, csChargingProfiles	status	Smart Charging
`5.17`	Trigger Message	`TriggerMessage`	requestedMessage, [connectorId]	status	Remote Trigger
`5.18`	Unlock Connector	`UnlockConnector`	connectorId	status	Core
`5.19`	Update Firmware	`UpdateFirmware`	location, retrieveDate	(empty)	Firmware Mgmt