Introduction #
Objectives #
This document is based on the OCPP 1.6 JSON protocol and describes the guidelines for operating the Wellborne OCPP server and controlling the charger implementation. This document contains all AC and DC charger commands, charger model differences, and they do not all apply.
Warning #
This document is intended for use by Wellborne’s internal developers for development and debugging operations, and any problems or losses caused by the use of this document by persons other than those authorized by Wellborne shall not render Wellborne liable for any direct, indirect, special or consequential damages caused by the following circumstances:
- This document may not be reproduced or shared without permission;
- Wellborne is not liable for any consequences arising from misuse of the information in this document;
- In the event of distribution or reproduction of this document not expressly authorized by Wellborne, Wellborne may decide to take legal action at its discretion.
Controls #
“Response” is the command that the load point/central server responds to the central server/load point after receiving the corresponding command. Only the “Operations Initiated by Central System” command can be operated, with the exception of “Response”.
| N° | Operations initiated by the load point | N° | Operations initiated by the central system |
|---|---|---|---|
| 1 | Authorize | 21 | CancelReservation |
| 2 | AuthorizeResponse | 22 | CancelReservationResponse |
| 3 | BootNotification | 23 | ChangeAvailability |
| 4 | BootNotificationResponse | 24 | ChangeAvailabilityResponse |
| 5 | DataTransfer | 25 | DataTransfer |
| 6 | DataTransferResponse | 26 | DataTransferResponse |
| 7 | DiagnosticsStatusNotification | 27 | ChangeConfiguration |
| 8 | DiagnosticsStatusNotificationResponse | 28 | ChangeConfigurationResponse |
| 9 | FirmwareStatusNotification | 29 | ClearCache |
| 10 | FirmwareStatusNotificationResponse | 30 | ClearCacheResponse |
| 11 | Heartbeat | 31 | ClearChargingProfile |
| 12 | HeartbeatResponse | 32 | ClearChargingProfileResponse |
| 13 | MeterValues | 33 | GetCompositeSchedule |
| 14 | MeterValuesResponse | 34 | GetCompositeScheduleResponse |
| 15 | StartTransaction | 35 | GetConfiguration |
| 16 | StartTransactionResponse | 36 | GetConfigurationResponse |
| 17 | StatusNotification | 37 | GetDiagnostics |
| 18 | StatusNotificationResponse | 38 | GetDiagnosticsResponse |
| 19 | StopTransaction | 39 | GetlocalListVersion |
| 20 | StopTransactionResponse | 40 | GetlocalListVersionResponse |
| 41 | RemoteStartTransaction | ||
| 42 | RemoteStartTransactionResponse | ||
| 43 | RemoteStopTransaction | ||
| 44 | RemoteStopTransactionResponse | ||
| 45 | ReserveNow | ||
| 46 | ReserveNowResponse | ||
| 47 | Reset | ||
| 48 | ResetResponse | ||
| 49 | Sendlocallist | ||
| 50 | SendlocalListResponse | ||
| 51 | SetChargingProfile | ||
| 52 | SetChargingProfileResponse | ||
| 53 | TriggerMessage | ||
| 54 | TriggerMessageResponse | ||
| 55 | UnlockConnector | ||
| 56 | UnlockConnectorResponse | ||
| 57 | UpdateFirmware | ||
| 58 | UpdateFirmwareResponse |
Loading process #
For an electric vehicle to be charged by a Charge Point, it must first authorize the user to start charging. If the user is authorized, the Charge Point informs the Central System that the charging session has begun.
When a user wishes to disconnect his electric vehicle from the Charge Point, the Charge Point must check that the user is either the one who initiated the charging session, or that he belongs to the same group, and therefore has authorization to end the charging session. Once authorization has been obtained, the Charge Point informs the Central System that the charging session has been terminated.
Connection #
Link #
https://charge.wellborne.fr/ocpp/user/user1
Workspace #
After logging in, the following page appears:
1. Enter the terminal’s serial number and click on “Search” to check the terminal’s status.
2. First click on “Load ID”, then click on “Start debug”.
3. Click on the command list on the left and enter the required configuration keys
Operation #
RemoteStopTransactionResponse #
StatusNotification #
Order description:
A Load Point sends a notification to the Central System to inform it of a change in status or an error in the Load Point.
Busy states: Preparing, Charging, SuspendedEV, SuspendedEVSE and Finishing
Other states: Available, Unavailable, Reserved, Faulted, SuspendedEV, SuspendedEVSE
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectoId | integer connectorID ≥ 0 | 1..1 | Mandatory. The id of the connector whose status is reported. The id “0” is used if the status is that of the Load Point’s main controller. |
| errorCode | ChargePointErrorCode | 1..1 | Mandatory. Contains the error code reported by the Charge Point. |
| info | CiString50Type | 0..1 | Optional. Additional information about an error. |
| status | ChargePointStatus | 1..1 | Mandatory. Contains the current status of the Charge Point. |
| timestamp | dateTime | 0..1 | Optional. Time at which status is reported. If absent, the time the message was received will be used. |
Configuration #
connectorId:
errorCode:
info:
status:
timestamp:
vendorID:
vendorErrorCode:
SetChargingProfileResponse #
StartTransaction #
Order description:
The Charge Point must send a StartTransaction.req command to the Central System to inform it that a transaction has started. If the transaction terminates the reservation, the StartTransaction.req command must contain the reservationId.
On receipt of the StartTransaction.req command, the Central System must respond with a StartTransaction.conf command. This command must include the transaction ID and authorization status.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectoId | integer connectorID > 0 | 1..1 | Mandatory. Identifies which Charge Point connector is used. |
| idTag | IdToken | 1..1 | Mandatory. Contains the identifier with which the transaction was started. |
| meterStart | integer | 1..1 | Mandatory. Contains the value of the Wh connector at the start of the transaction. |
| reservationId | integer | 0..1 | Optional. Contains the ID of the reservation that is terminated as a result of the transaction. |
| timestamp | dateTime | 1..1 | Mandatory. Time at which transaction starts. |
Configuration #
ConnectorId:
idTag:
meterStart:
reservationId:
timestamp: (time format “2023-09-01T04:03:00.000”)
ClearCache #
Order description:
The Central System can ask the Load Point to clear the authorization cache. The Central System must send a ClearCach.req command to clear the Load Point’s authorization cache.
On receiving the ClearCach.req command, the load point must respond with a ClearCache.conf command. The response command must indicate whether the Load Point was able to clear the authorization cache.
Configuration #
No
Operation #
Simply click on “send” to clear the authorization cache.
FirmwareStatusNotificationResponse #
BootNotification #
Order description:
After start-up, the Charge Point must send a request to the Central System with its configuration information (version e.g., vendor, etc.). The Central System must reply to indicate whether it accepts the Charge Point.
The Load Point must send a BootNotification.req command each time it starts up or reboots. Between the physical start-up and the completion of the BootNotification, where the Central System responds Accepted or Pending, the Load Point must not send another request to the Central System. This includes cache messages already present in the Load Point.
| Field name | Field type | Card | Description |
|---|---|---|---|
| chargeBoxSerialNumber | CiString25Type | 0..1 | Optionnel. Contient une valeur qui identifie le numéro de série du Bloc de Charge dans le Point de Charge. Sera retiré dans une version future |
| loadPointModel | CiString20Type | 1..1 | Mandatory. Contains a value identifying the model of the Charge Point. |
| Field name | Field type | Card | Description |
|---|---|---|---|
| chargePointSerialNumber | CiString25Type | 0..1 | Optional. Contains a value identifying the Charge Point’s serial number. |
| chargePointVendor | CiString20Type | 1..1 | Mandatory. Contains a value identifying the vendor of the Charge Point. |
| firmwareVersion | CiString50Type | 0..1 | Optional. Contains the version of the Charge Point firmware. |
| iccid | CiString20Type | 0..1 | Optional. Contains the ICCID of the modem’s SIM card. |
| imsi | CiString20Type | 0..1 | Optional. Contains the IMSI of the modem’s SIM card. |
| meterSerialNumber | CiString25Type | 0..1 | Optional. Contains the serial number of the Charge Point’s main meter. |
| meterType | CiString25Type | 0..1 | Optional. Contains the type of the Charge Point’s main meter. |
Configuration #
chargePointVendor:
loadPointModel:
chargePointSerialNumber:
chargeBoxSerialNumber:
firmwareVersion:
iccid:
imsi:
meterType:
meterSerialNumber:
BootNotificationResponse #
FirmwareStatusNotification #
Order description:
A Load Point sends a notification to inform the Central System of the progress of the firmware update. The Load Point sends a FirmwareStatusNotification.req command to inform the Central System of the progress of the firmware update download and installation. The Load Point should only communicate the “Idle” status after receiving the TriggerMessage for firmware status notification, when it is not downloading or installing firmware.
On receipt of the FirmwareStatusNotification.req command, the Central System must respond with a FirmwareStatusNotification.conf command.
Configuration #
statusl: (Downloaded, DownloadFailed, Downloading, Idle, InstallationFailed, Installing, Installed)
DataTransfer #
Order description:
If a Load Point needs to send information to the Central System for a function not supported by OCPP, it must use the DataTransfer.req command.
| Field name | Field type | Card | Description |
|---|---|---|---|
| vendorId | CiString25Type | 1..1 | Mandatory. Identifies the specific vendor implementation. |
| messageId | CiString50Type | 0..1 | Mandatory. Additional identification field. |
| data | Text Length undefined | 0..1 | Optional. Data without length or specific format. |
Configuration #
vendorId:
messageID: (getenergy, G_SetAmount, G_SetEnergy, G_SetTime, getmonthrecord, getdayrecord, getcountrecord, appconfigmode, getnetworkname, getnetworksignal, factorymode, clearrecord, getelockstate, gethardmessage, getdayfault, getmonthfault, getcountfault, clearfault)
data:
| N° | Control | Description |
|---|---|---|
| 1 | getenergy | History of energy expended during charging session. |
| 2 | G_SetAmount | Load capacity adjustment. |
| 3 | G_SetEnergy | Charge energy adjustment. |
| 4 | G_SetTime | Set charging time. |
| 5 | getmonthrecord | Get the month’s load history. |
| 6 | getdayrecord | Get today’s load history. |
| 7 | getcountrecord | Get the cumulative load report. |
| 8 | appconfigmode | App. mode |
| 9 | getnetworkname | Get the network name. |
| 10 | getnetworksignal | Obtain signal strength. |
| 11 | factorymode | Restore factory settings. |
| 12 | clearrecord | Clear load reports. |
| 13 | getelockstate | Obtain electronic lock status. |
| 14 | gethardmessage | Obtain information on a defined parameter: CP, PMW, voltage, current, load-shedding power sample, etc. |
| 15 | getdayfault | Obtain information on the day’s malfunctions. |
| 16 | getmonthfault | Obtain information on the month’s malfunctions. |
| 17 | getcountfault | Obtain information on cumulative malfunctions. |
| 18 | clearfault | Delete malfunction information. |
| 19 | solar_target_data | Reserve. |
| 20 | get_external_meterval | Get the load-shedding balance / sample solar value |
Configuration #
connectorId: (0, 1, 2, 3, 4)
ClearCacheResponse #
UnlockConnector #
Order description:
The Central System can ask the Load Point to disconnect a connector. To do this, the Load Point must send an UnlockConnector.req command.
The purpose of this message is to help drivers of electric vehicles who have difficulty disconnecting their cable from the Charge Point in the event of a cable retraction malfunction. When the user calls the after-sales service, an operator can trigger the UnlockConnector.req command at the Charge Point, forcing a new attempt to unlock the connector.
The UnlockConnector.req command must not be used to stop a remote transaction; this operation must be performed with the RemoteStop command.
After receiving the UnlockConnector.req command, the Load Point must respond with an UnlockConnector.conf command. The response should indicate whether the Load Point has successfully unlocked its connector.
If a transaction was in progress on a specific connector, then the Load Point must first terminate the transaction as described under StopTransaction.
Note: UnlockConnector can only be used with chargers fitted with an AC socket.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectorId | integer connectorId > 0 | 1..1 | Mandatory. Contains the identity of the connector to be unlocked. |
Configuration #
connectorId: (1, 2, 3, 4)
Operation #
Enter the number corresponding to the connector you wish to unlock and click on “send”.
NB: This command cannot be used to terminate a transaction in progress.
DiagnosticsStatusNotification #
Order description:
The Load Point sends a notification to inform the Central System of the download status of a diagnostic. The Load Point sends a DiagnosticsStatusNotification.req command to inform the Central System that the diagnostic download is in progress, or has failed or succeeded. The Load Point must only send the “Idle” status after receiving the DiagnosticsStatusNotification TriggerMessage, when it is not downloading the diagnosis.
On receipt of the DiagnosticsStatusNotification.req command, the Central System must respond with a DiagnosticsStatusNotification.conf command.
Configuration #
statuI: (Idle, Uploaded, UploadFailed, Uploading)
CancelReservation #
Order description:
To cancel a reservation, the Central System sends a CancelReservation.req command to the Load Point.
If the Load Point has a reservation corresponding to the one quoted by the CancelReservation.req command, it must respond with an “Accepted” or “Rejected” status.
| Field name | Field type | Card | Description |
|---|---|---|---|
| reservationId | integer | 1..1 | Mandatory. ID of the reservation to be cancelled. |
Configuration #
reservationId:
Operation #
The reservationId of the cancelReservation must be identical to the reservationId. If the parent ID is set, the reservationId is the same as the parentId.
GetLocalListVersionResponse #
TriggerMessageResponse #
ReserveNowResponse #
ChangeConfigurationResponse #
CancelReservationResponse #
RemoteStartTransactionResponse #
SendLocalListResponse #
AuthorizeResponse #
SendLocalList #
Order description:
The Central System can send a Local Authorization List that a Load Point can use to authorize idTags. The list can be either a complete list to replace the list currently in the Load Point, or a different list with updates to be applied to the list currently in the Load Point.
Configuration #
listVersion:
localAuthorizationList:
updateType: (Differential, Full)
UpdateFirmwareResponse #
GetCompositeSchedule #
Order description:
The Central System can ask the Load Point to report the Composite Charging Schedule by sending a GetCompositeSchedule.req command. The schedule reported in the GetCompositeSchedule.conf command is the result of calculating all active schedules and any local limits present in the Load Point.
Configuration #
connectorId:
duration:
chargingRateUnit: (A, W)
Operation #
If you have set the load profile, obtain the current schedule with the GetCompositeSchedule command.
DataTransferResponse #
StopTransactionResponse #
ClearChargingProfileResponse #
UnlockConnectorResponse #
GetCompositeScheduleResponse #
GetDiagnostics #
Order description:
The Central System may request diagnostic information from the Load Point. The Central System must send a GetDiagnostics.req command to obtain the Charge Point’s diagnostic information with the location where the Charge Point should download the diagnostic data, and potentially a start and end time for the diagnostic data.
On receipt of the GetDiagnostics.req command, and if the diagnostic information is available, then the Load Point must respond with a GetDiagnostics.conf command which gives the name of the file that will be downloaded and which contains the diagnostic information. The Charge Point must send a single file. There is no mandatory file format. If the diagnostic file is not available, then the GetDiagnostics.conf command must not contain a file name.
| Field name | Field type | Card | Description |
|---|---|---|---|
| rental | anyUR1 | 1..1 | Mandatory. Contains the location (directory) where the diagnostics file is to be downloaded. |
| retries | integer | 0..1 | Optional. Specifies how many times the Load Point should try to download the diagnostic before giving up. If this field is left blank, the Load Point decides how many attempts it makes. |
| retryInterval | 0..1 | Optional. Interval in seconds between each attempt. If this field is not filled in, the Load Point decides the length of the intervals. | |
| startTime | 0..1 | Optional. Date and time of the earliest information to be included in the diagnosis. | |
| stopTime | 0..1 | Optional. Date and time of the most recent information to be included in the diagnosis. |
Configuration #
location: (http://charge.wellborne.fr:80/ocpp/uploadFile/logs/http://ess-charge.atesspower.com:80/ocpp/uploadFile/logs/)
retries:
retryInterval:
startTime: (format: 2023-09-01T04:03:00.000)
stopTime:
Operation #
Enter the path to send the report and click on “send”. You can also enter the diagnostic start and end times, and the charger will download the diagnostic information corresponding to the defined time slot.
NB: First of all, you need to insert an SD card with at least 8GB of space in the charger slot. The time slot for a diagnostic report cannot exceed one day.
ResetResponse #
ChangeAvailability #
Order description:
The Central System may ask the Charge Point to change its availability. A Charge Point is considered “operative” when it is charging or ready to charge. A Charge Point is considered unavailable when it is not charging. The Central System must send a ChangeAvailability.req request to the Charge Point to change its availability. The Central System can change the availability from available to unavailable.
On receipt of the ChangeAvailability.req command, the Load Point must respond with a ChangeAvailability.conf command. The response must indicate whether the Load Point can change to the required availability status. When a transaction is in progress, the Load Point must respond with the status “Scheduled” to indicate that the availability change must take place at the end of the transaction.
If the Central System asks the Load Point to change to a status it is already in, the Load Point must respond with the availability status “Accepted”.
When the availability change requested with the ChangeAvailability.req command is effective, the Load Point must inform the Central System of its new availability status with a StatusNotification.req command, as described here.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectorId | integer connectorId ≥ 0 | 1..1 | Mandatory. The ID of the connector whose availability is to be changed. “0” is used if the availability of the Charge Point and all its connectors is to be changed. |
| type | AvailabilityType | 1..1 | Mandatory. Contains the type of availability change to be performed by the Charge Point. |
This command is used to modify the charger’s status, often for on-site maintenance operations. Once the “out of service” command has been transmitted to the charger, the charger can only be reset once its status has been reset in this interface.
Configuration #
connector: (0, 1, 2, 3, 4)
type: (Inoperative, Operative)
Operation #
0: complete charger
1: A connector (DC)
2: B connector (DC)
3: C connector (AC)
4: D connector (AC)
Inoperative: charger is undergoing maintenance (out of service)
Operative: normal state, charger available
Enter the ID of the connector concerned in the dedicated field, typing “1” for example, and fill in the connector status field, such as “Inoperative”.
ClearChargingProfile #
Order description:
If the Central System wants to delete some or all of the load profiles previously sent to the Load Point, it must send a ClearChargingProfile.req command.
The Load Point must respond with a ClearChargingProfile.conf command specifying whether it was able to apply the request.
| Field name | Field type | Card | Description |
|---|---|---|---|
| id | integer | 0..1 | Optional. The ID of the load profile to be deleted. |
| connectorId | integer | 0..1 | Optional. Specifies the ID of the connector whose load profiles are to be deleted. ID “0” corresponds to the load profile of the entire Load Point. The absence of this parameter means that deletion applies to all load profiles corresponding to the request. |
| chargingProfilePurpose | ChargingProfilePurposeType | 0..1 | Optional. Specifies the purpose of the load profiles to be deleted, if they match the command. |
| stackLevel | integer | 0..1 | Optional. Specifies the stackLevel for which load profiles will be deleted, if they match the command. |
Configuration #
id:
connectorId:
chargingProfilePurpose: (ChargePointMaxProfile, TxDefaultProfile, TxProfile)
stackLevel:
Operation #
Enter the load profile you wish to clean and run the command. If you want to clean one of the connectors, enter the corresponding connector code.
NB: don’t forget to check the current load profile via “GetCompositeSchedule”.
TriggerMessage #
Order description:
During normal operation, the Charge Point informs the Central System of its status whenever necessary. If there is nothing to report, the Load Point sends at least one heartBeat at regular intervals.
If the Central System has reason to doubt the accuracy of the information transmitted, or if the transmission time seems too long, the TriggerMessage.req command enables it to ask the Load Point to send messages.
For each message requested, the Central System can optionally indicate which message it wishes to receive. For each of these requests, the Central System can optionally indicate to which connector the request is addressed.
| Field name | Field type | Card | Description |
|---|---|---|---|
| requestedMessage | MessageTrigger | 1..1 | Mandatory. |
| connectorId | integer connectorId > 0 | 0..1 | Optional. Filled in only when the request is addressed to a specific connector. |
Configuration #
requestedMessage: (BootNotification, DiagnosticsStatusNotification, FirmwareStatusNotification, Hearbeat, MeterValues, StatusNotification)
connectorId:
Operation #
Select the command you wish to trigger from the options.
StartTransactionResponse #
GetConfigurationResponse #
SetChargingProfile #
Order description:
The Central System can send a SetChargingProfile.req command to a Load Point to define a load profile in the following situations:
- At the start of a transaction, to set the load profile for the transaction: If the Central System receives a StartTransaction.req command, it must respond with a StartTransaction.conf command. If a load profile is required, the Central System may choose to send a SetChargingProfile.req command to the Load Point. It is advisable to check the timestamp in the StartTransaction.req command before sending the load profile, to check whether the transaction is likely to still be in progress. The StartTransaction.req command may have been cached during offline time.
- When sending a RemoteStartTransaction command to a Load Point: The Central System can include a load profile in a RemoteStartTransaction command. If the Central System includes a load profile, ChargingProfilePurpose must be set to TxProfile.
- During a transaction, to change the active transaction profile: The Central System can send a load profile to the Load Point in order to update the load profile for this transaction. To do this, the Central System must use a SetChargingProfile.req command. If a load profile with the same ID, or the same combination of stackLevel / ChargingProfilePurpose, exists in the Load Point, the new load profile should replace the existing load profile, otherwise, the new load profile should be added. The Charge Point must then re-evaluate its catalog of charging profiles to determine which one should be active. To ensure that the updated load profile applies only to the current transaction, the load profile’s chargingProfilePurpose must be set to TxProfile.
- Outside the context of a transaction as a message in its own right, to set a charging profile on a local controller, a Charge Point, or a default charging profile to a connector: The Central System can send default charging profiles to a Charge Point. To do this, the Central System uses the SetChargingProfile.req command. These load profiles can be sent at any time. If a load profile with the same ID, or the same combination of stackLevel / ChargingProfilePurpose, exists in the Load Point, the new load profile must replace the existing load profile, otherwise, the new load profile must be added. The Load Point must then re-evaluate its catalog of load profiles to determine which one should be active.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectorId | integer | 1..1 | Mandatory. The connector to which the profile applies. If connectorId = 0, the message contains a global limit for the Load Point. |
| csChargingProfiles | ChargingProfile | 1..1 | Mandatory. The load profile to be applied to the Load Point. |
Configuration #
connectorId:
csChargingProfiles
chargingProfileId:
transactionId:
stackLevel:
chargingProfilePurpose: (ChargePointMaxProfile, TxDefaultProfile, TxProfile)
chargingProfileKind: (chargingProfileKind)
recurrencyKind: (Daily, Weekly)
validFrom:
validTo:
chargingSchedule
duration:
startSchedule:
chargingRateUnit: (A, W)
chargingSchedulePeriod: (sample: {“startPeriod”:0, “limit”:20000.0, “numberphases”:3})
Operation #
GetDiagnosticsResponse #
MeterValues #
Order description:
A Load Point can sample the electricity meter or another sensor/transducer to provide additional information about the measured values. It is up to the Load Point to decide when to send the meter values. This can be configured using the ChangeConfiguration.req command, specifying the data to be collected and the intervals between reports.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectorId | integer connectorId ≥ 0 | 1..1 | Mandatory. Contains a number (>0) designating a Charge Point connector. “0” is used to designate the main counter. |
| transactionId | integer | 1..1 | Optional. The transactions to which these sample values are linked. |
| meterValue | MeterValue | 1..* | Mandatory. Counter sample values with time markers. |
Configuration #
connectorId:
transactionId:
meterValue:
HeartbeatResponse #
RemoteStartTransaction #
Order description:
The Central System can request the Load Point to start a transaction by sending a RemoteStartTransaction.req command. On receipt of the command, the Load Point must respond with a RemoteStartTransaction.conf command and a status indicating whether or not it is able to start the transaction.
The RemoteStartTransaction.req command must contain an identifier (idTag), which the Load Point must use to indicate whether it is able to start the transaction, in order to send a RemoteStartTransaction.req command to the Central System.
The transaction is started in the same way as described in the StartTransaction chapter. The RemoteStartTransaction.req command can contain a connector ID if the transaction is to start on a specific connector. When the connector ID is supplied, the Load Point controls connector selection. A Load Point can reject a RemoteStartTransaction.req command without a connector ID.
The Central System can include a load profile in the RemoteStartTransaction.req command. The purpose of this load profile must be set to TxProfile. The Load Point must use this load profile for the transaction.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectorId | integer | 0..1 | Optional. Number of connectors on which to start the transaction. Connector ID must be > 0 |
| idTag | IdToken | 1..1 | Mandatory. The identifier the Charge Point must use to start the transaction. |
| chargingProfile | ChargingProfile | 0..1 | Optional. The Charging Profile to be used by the Charge Point for the requested transaction. ChargingProfilePurpose must be set to TxProfile. |
Configuration #
idTag:
chargingProfile
chargingProfileId:
transactionId:
stackLevel:
chargingProfilePurpose: (ChargePointMaxProfile, TxDefaultProfile, TxProfile)
chargingProfileKing: (Absolute, Recurring, Relative)
recurrencyKind: (Daily, Weekly)
validFrom:
validTo:
chargingSchedule
duration:
startSchedule:
chargingRateUnit: (A, W)
chargingSchedulePeriod:
minChargingRate:
Operation #
Enter the connectorId and idTag to start the transaction. The idTag can be customized. If you wish to interrupt the transaction remotely, go to RemoteStopTransaction and you’ll see that the ID has been filled in. Click on “send” to interrupt the load.
StopTransaction #
Order description:
When the transaction is interrupted, the Load Point must send a StopTransaction.req command, notifying the Central System that the transaction has been stopped.
A StopTransaction.req command can contain an optional TransactionData element to provide further details about the use of the transaction. This element is a container for a number of MeterValues, using the same data structure as the MeterValue elements of the MeterValues.req command.
On receiving the StopTransaction.req command, the Central System must respond with a StopTransaction.conf command.
| Field name | Field type | Card | Description |
|---|---|---|---|
| idTag | IdToken | 0..1 | Optional. Contains the identifier required to stop charging. Optional because the Charge Point can terminate the charge without the presence of an idTag in the event of a reset. A Charge Point must send the idTag if it is known. |
| meterStop | integer | 1..1 | Mandatory. Contains the value of the Wh connector counter at the end of the transaction. |
| timestamp | dateTime | 1..1 | Mandatory. Contains the date and time when the transaction stops. |
| transactionId | integer | 1..1 | Mandatory. Contains the transaction ID as received by the StartTransaction.conf command. |
| reason | Reason | 0..1 | Optional. Contains the reason why the transaction was stopped. Can only be omitted when the reason is “local”. |
| transactionData | MeterValue | 0..* | Optional. Contains transaction usage details relevant to billing. |
Configuration #
idTag:
meterStop:
timestamp:
transactionId:
reason: (EmergencyStop, EVDisconnected, HardReset, Local, Other, PowerLoss, Reboot, Remote, SoftReset, UnlockCommand, DeAuthorized)
TransactionData:
UpdateFirmware #
Order description:
The Central System can notify a Load Point of a firmware update requirement. The Central System must send an UpdateFirmware.req command to ask the Charge Point to install new firmware. The command must contain a timestamp after which the Load Point is allowed to retrieve the new firmware, and the location where it can be downloaded.
On receipt of the UpdateFirmware.req command, the Load Point should respond with an UpdateFirmware.conf command. The Load Point should start retrieving firmware as soon as possible after the specified timestamp.
| Field name | Field type | Card | Description |
|---|---|---|---|
| rental | anyURL | 1..1 | Mandatory. Contains the breadcrumb trail including the URL designating the location where to retrieve the firmware. |
| retries | integer | 0..1 | Optional. Specifies how many times the Load Point should try to download the firmware before giving up. If this field is left blank, the Charge Point decides how many times to try. |
| retrieveDate | dateTime | 1..1 | Mandatory. Contains the timestamp after which the Charge Point can retrieve the new firmware. |
| retryinterval | integer | 0..1 | Optional. The interval in seconds after which a new test can be made. If this field is left blank, the Load Point determines the interval duration. |
Configuration #
location:
retries:
retrieveDate:
retryInterval:
Operation #
Enter the location where the firmware is stored under “Location”. Other options can be entered as required. The update takes approximately 1-3 minutes.
NB: The version of the old firmware must be of the same series.
DiagnosticsStatusNotification #
Order description:
The Load Point sends a notification to inform the Central System about the status of the diagnostics download. The Load Point must send a DiagnosticsStatusNotification.req command to inform the Central System that the diagnostics download is in progress, finished, or has failed. The Load Point must send an “Idle” status after receiving a TriggerMessage, when it is not downloading diagnostics.
On receipt of the DiagnosticsStatusNotification.req command, the Central System must respond with a DiagnosticsStatusNotification.conf command.
GetLocalListVersion #
Order description:
To support synchronization of the Local Authorization List, the Central System can request the version number of the Local Authorization List from the Load Point. The Central System must send a GetLocalListVersion.req command.
On receipt of the GetLocalListVersion.req command, the Load Point must respond with a GetLocalListVersion.conf command containing the version number of the Local Authorization List. A version number of 0 should be used to indicate that the Local Authorization List is empty, and a version number of -1 should be used to indicate that the Load Point does not support the Local Authorization List.
Operation #
Click on “send” to obtain the Local List Version.
GetConfiguration #
Order description:
To obtain the value of the configuration settings, the Central System must send a GetConfiguration.req command to the Load Point.
If the list of configuration keys is empty or missing (optional), the Load Point must respond with a list of all configuarion settings in its GetConfiguration.conf command. Otherwise, the Load Point must respond with a list of recognized keys and their respective values in read-only mode; unrecognized keys must be placed in the response command as part of the list of optional unknown keys within the GetConfiguration.conf command.
The number of configuration keys requested in a single command can be limited by the Load Point. The maximum can be obtained by reading the GetConfigurationMaxKeys configuration key.
| Field name | Field type | Card | Description |
|---|---|---|---|
| key | CiString50Type | 0..* | Optional. List of keys for which the configuration value is requested. |
Configuration #
key: (any number, 1, 2, 3, etc.)
Operation #
Enter any value in the “key” field, and the information bar will display all the key values, so find the one you need.
RemoteStopTransaction #
Order description:
The Central System can ask the Load Point to interrupt a transaction by sending it a RemoteStopTransaction.req command containing the transaction identifier. The Load Point must respond with a RemoteStopTransaction.conf command to indicate whether or not it was able to interrupt the transaction.
This request to interrupt the remote transaction is equivalent to a local action to stop a transaction. Thus, the transaction must be stopped, and the Load Point must send a StopTransaction.req command and, if possible, unlock the connector.
The main reasons for using this command are:
- To enable the CPO operator to help a user who is unable to terminate a transaction.
- To enable mobile applications to control load transactions via the Central System.
| Field name | Field type | Card | Description |
|---|---|---|---|
| transactionId | integer | 1..1 | Oligatory. The identifier of the transaction the Load Point is asked to interrupt. |
Configuration #
transactionId:
Operation #
The transaction ID is obtained automatically, and the load can be interrupted remotely by pressing “send”.
ReserveNow #
Order description:
The Central System can send a ReserveNow.req command to the Charge Point to reserve a connector for use by a specific idTag.
To request a reservation, the Central System must issue a command to the Load Point. The Central System can specify which connector is to be reserved. On receipt of the ReserveNow.req command, the Load Point must respond with a ReserveNow.conf command.
If the request’s reservationId matches the Charge Point’s reservation, then the Charge Point must replace the reservation with the request’s new reservation.
If the reservationId does not match the reservation in the Load Point, then the Load Point must respond with the status value “Accepted” if it succeeds in reserving the connector. The Load Point must respond “Occupied” if it or the specified connector are occupied. The Load Point must also respond “Occupied” if it or the connector has been reserved for the same or a different idTag. The Load Point must respond “Faulted” if it or the connector is in a fault state. The Charge Point must respond “Unavailable” if it or the connector are unavailable. The Load Point must respond “Rejected” if it is not configured to accept reservations.
If the Charge Point accepts the reservation request, it must then refuse to load any idTag with the reserved connector, apart from the one corresponding to the reservation idTag. When the “ReserveConnectorZeroSupported” configuration key is set to “true”, the Load Point accepts reservations for connector 0. If the connectorId in the reservation is 0, then the Load Point must not reserve a specific connector, but must ensure that for the duration of the reservation a connector remains available for the idTag. If the “ReserveConnectorZeroSupported” configuration key is not set, or set to “false”, the Load Point must respond “Rejected”. If the reservation idTag has a value (optional), then in order to determine the parent idTag associated with the matching idTag, the Load Point can search for it in the LocalAuthorizationList or AuthorizationCache. If it is not found in these locations, the Load Point must send an Authorize.req command for the approaching idTag to the Central System. The Authorize.conf response contains the parent ID.
The reservation must end either when a transaction begins for the idTag or parent idTag with the specific Load Point or connector reserved, or when the time specified in “expireDate” is reached, or when the Load Point or connector is set to “Faulted” or “Unavailable”.
If the transaction for the idTag starts, then the Load Point must send a reservationId in the command (StartTransaction.req) to notify the Central System that the reservation has been completed.
When the reservation expires, the Charge Point must terminate the reservation and make the connector available. The Charge Point must send a status notification to inform the Central System that the reserved connector is now available.
If the Load Point has implemented an AuthorizationCache, then on receipt of the ReserveNow.conf command, it must update the cache entry, if the idTag is not on the LocalAuthorizationList, with the IdTagInfo value from the response as described under AuthorizationCache.
| Field name | Field type | Card | Description |
|---|---|---|---|
| connectorId | integer connectorId ≥0 | 1..1 | Mandatory. Contains the ID of the connector to be reserved. A value of 0 means that the reservation is not for a specific connector. |
| expiryDate | dateTime | 1..1 | Mandatory. Contains the reservation end time stamp. |
| idTag | IdToken | 1..1 | Mandatory. The identifier for which the Charge Point must reserve the connector. |
| parentidTag | IdToken | 0..1 | Optional. Parent idTag. |
| reservationId | integer | 1..1 | Mandatory. The unique ID of this reservation. |
Configuration #
connectorId: (0, 1, 2, 3, 4)
expiryDate: (Format timestamp 2024-04-08T04:03:00.000)
idTag: (custom)
parentIdTag: (optional)
reservationId: (custom)
Operation #
Enter the time period for which the load is to be reserved. Other fields can be customized, for example idTag:1234567890123456.
ChangeAvailabilityResponse #
MeterValuesResponse #
ChangeConfiguration #
Order description:
The Central System can request the Load Point to modify the parameter configuration. To do this, it sends a ChangeConfiguration.req command. This command contains a “key-value”, where “key” is the name of the configuration whose setting is to be changed and “value” is the new setting for this configuration?
On receipt of the ChangeConfiguration.req command, the Load Point must respond with a ChangeConfiguration.conf command indicating whether or not it was able to execute the requested modification. Details of the contents of “key” and “value” are not prescribed. If “key” does not correspond to a configuration supported by the Load Point, it must respond with a NotSupported status. If the modification is carried out successfully, the Load Point must respond with an Accepted status. If the modification is carried out successfully, but a reboot is required, the Load Point should respond with a RebootRequired status. If the configuration fails, the Load Point should respond with a Rejected status.
If a “key” value is defined in CSL, it can be accompanied by a [KeyName]MaxLength key, indicating the maximum length of the CSL. If the “key” is not defined, a safe value of 1 must be assumed.
| Field name | Field type | Card | Description |
|---|---|---|---|
| key | CiString50Type | 1..1 | Mandatory. The name of the configuration to be modified. Search for standard configuration key names and associated values. |
| value | CiString500Type | 1..1 | Mandatory. The new setting value. Search for standard configuration key names and associated values. |
Configuration #
key: (G_ChargerID: check configuration key list)
value: (NBG0D49234: according to key list)
Operation #
Enter the key value under “key” as G_ChargerID, and enter the ChargerID you wish to modify under “value”, as NBGZG49235. The information fields show the status of the changes, which can also be viewed in “Getconfiguration”.
Authorize #
Order description:
Before the user of an electric vehicle can start or stop charging, the Charge Point must authorize the operation. The Charge Point must only supply energy after authorization. When stopping a transaction, the Charge Point must only send an Authorize.req command when the identifier used to stop the transaction is different from the one that started it.
The Authorize.req command should only be used to authorize an identifier to start or stop the load.
The Load Point can authorize the identifier locally without involving the Central System, as described under LocalAuthorizationList. If the IdTag presented by the user is absent from the LocalAuthorizationList or AuthorizationCache, then the Load Point must send an Authorize.req command to the Central System.
When this request is received, the Central System must respond with an Authorize.conf command. This command must indicate whether or not the IdTag is accepted by the Central System. If the Central System accepts the IdTag, then the response must include a parentIdTag and a status value indicating acceptance or reason for rejection.
If the Load Point has implemented an AuthorizationCache, then on receipt of the Authorize.conf command, it must update its cache list, if the IdTag is not in the LocalAuthorizationList, with the IdTagInfo value from the response as described under AuthorizationCache.
| Field name | Field type | Card | Description |
|---|---|---|---|
| idTag | IdToken | 1..1 | Mandatory. Contains the identifier to be authorized. |
Configuration #
IdTag:
StatusNotificationResponse #
Heartbeat #
Order description:
To let the Central System know that it is still connected, the Load Point sends a heartbeat at configurable intervals.
The Load Point must send a Heartbeat.req command to ensure that the Central System knows that the Load Point is still active.
On receipt of the command, the Central System must respond with a Heartbeat.conf command. The response must contain the Central System time, which we recommend you use for the Charge Point to synchronize its internal clock.
The Load Point can skip sending the Heartbeat.req command when another command has been sent to the Central System during the configured interval. This implies that the Central System must assume the availability of the Load Point at the time the command was received, in the same way as it would have done when receiving the Heartbeat.req command.
Reset #
Order description:
The Central System must send a Reset.req command to request the Load Point to reset itself. The Central System can request a hard reset or a conventional reset. On receipt of the command, the Load Point must respond with a Reset.conf command. The response must include whether the Load Point will attempt to reset itself.
When a classic reset request is received, the Load Point must return to a state similar to that of having just been started. If a transaction is in progress, it must stop normally, before the reset, as under StopTransaction.
On receiving a forced reset request, the Load Point must attempt to terminate any transactions in progress normally, as under StopTransaction, and then begin the reset.
| Field name | Field type | Card | Description |
|---|---|---|---|
| type | ResetType | 1..1 | Mandatory. Contains the type of reset to be performed by the Charge Point. |
Configuration #
Type: (Hard, Soft)
Operation #
When you select force reset or classic reset, the charger will automatically reset.
OCPP configuration keys #
| Key | Definitions | Value | Length | Configurable | Readable |
|---|---|---|---|---|---|
| G_ChargerID | Charger ID | Letters | <19 | Yes | Yes |
| G_ServerURL | Loader URL | Letters | <71 | Yes | Yes |
| G_ChargerRate | Charger price | Numbers | No | Yes | Yes |
| G_ChargerLanguage | Loader language | AC: English, Thai, Italian, Hungarian, Slovak, French, Spanish DC: English, French | No | Yes | Yes |
| G_MaxCurrent | Max. current of charger | Numeric characters | No | Yes | Yes |
| G_ChargerMode | Charging mode | 1, 2, 3 (1: APP, 2: RFID, 3: Plug & Charge) | No | Yes | Yes |
| G_CardPin | RFID password | Default: 242007 | 6 figures | Yes | Yes |
| G_ChargerNetIP | Charger IP | Vacuum | <16 | Yes | Yes |
| G_ChargerNetGateway | Loader gateway | Vacuum | <16 | Yes | Yes |
| G_ChargerNetMac | MAC | Vacuum | 17 figures | Yes | Yes |
| G_ChargerNetMask | Mask | Vacuum | <16 | Yes | Yes |
| G_ChargerNetDNS | DNS | Vacuum | <16 | Yes | Yes |
| G_Authentication | Connection authorization key | Default: 12345678 | <21 | Yes | Yes |
| G_HeartbeatInterval | OCPP pulse time in seconds | Numbers | No | Yes | Yes |
| G_WebSocketPngInterval | Websocket protocol ping interval in seconds | Numbers | No | Yes | Yes |
| G_MeterValueInterval | Interval in seconds of the metervalues command for the OCPP protocol | Numbers | No | Yes | Yes |
| G_MaxTemperature | Maximum charger protection temperature value | Numbers, default: 85 | No | Yes | Yes |
| G_ExternalLimitPower | External power limit for load balance | Numbers | No | Yes | Yes |
| G_ExternalLimitPowerEnable | Authorize load balance | 0: off / 1: on | No | Yes | Yes |
| G_ExternalSamplingCurWring | External sampling current, wiring method | 0: CT2000 1: Counter 2: CT3000 | No | Yes | Yes |
| G_SolarMode | Solar load | Format de transfert, chaîne : n° de prise > régler valeur (NB : le réglage ATESS ne requiert pas de n° de prise) N° de prise : 0, 1, 2, 3 0 : chargeur complet Modes de charge = 0 : FAST, 1 : ECO, 3 : ECO+ | No | Yes | Yes |
| G_SolarlimitPower | Solar charging power limit (only affects ECO+ mode) | Unit: kWh, supports decimals | No | Yes | Yes |
| G_PeakValleyEnable | Peak-valley function | 0: off / 1: on | No | Yes | Yes |
| G_AutoChargeTime | On/off button, to set charging time | 00:00-23:59 | No | Yes | Yes |
| G_RCDProtection | RCD protection value | mA | No | Yes | Yes |
| G_PowerMeterType | Meter type | Eastron, Acrel, Acrel DDS1352, Acrel DTSD1352, Eastron SDM230, Eastron SDM630, Eastron SDM 120 MID, Eastron SDM72D MID, Din-Rail DTSU666 MID, SM-US-200 DDSU666 | No | Yes | Yes |
| G_PowerMeterAddr | Meter address | DDSU666 | No | Yes | Yes |
| G_LowPowerReserveEnable | Programmed reserve load | Enable : on Disable : off | No | Yes | Yes |
| G_LCDCloseEnable | LCD on/off | Enable : on Disable : off | No | Yes | Yes |
| G_TimeSharingPrice | Rates per period | Transfer format, string: time1 = 00:00-01:00 / price1 = 0.01 / time2 = 00:00-02:00 / price1 = 0.01 / etc. Supports a maximum of 5 tariff configurations per period. | No | Yes | Yes |
| G_NetworkMode | Changing the network mode | DHCP: dynamic IP STATIC: static IP | No | Yes | Yes |
| G_TimeZone | Time zone setting | East 8 : UTC+08:00 West 8 : UTC-08:00 | No | Yes | Yes |
| G_DebugEnable | The loader issues a DataTransfer command to report debugging information to the server. | Enable : on Disable : off | No | Yes | Yes |
| G_SolarBoost | Solar boost function switch | Format de transfert, chaîne : n° de prise > régler valeur (NB : le réglage ATESS ne requiert pas de n° de prise) N° de prise : 0, 1, 2, 3 0 : chargeur complet Valeur du réglage = Disable, ManualBoost, SmartBoost | No | Yes | Yes |
| G_OffPeakEnable | Peak-valley function switch | Format de transfert, chaîne : n° de prise > régler valeur (NB : le réglage ATESS ne requiert pas de n° de prise) N° de prise : 0, 1, 2, 3 0 : chargeur complet Valeur du réglage = Disable, Enable | No | Yes | Yes |
| G_PeriodTime | Configuration of manualBoost time slots and peak load time slots | Format de transfert, chaîne : n° de prise > régler valeur. Supporte un maximum de 5 plages horaires (NB : le réglage ATESS ne requiert pas de n° de prise) N° de prise : 0, 1, 2, 3 0 : chargeur complet | No | Yes | Yes |
| LightIntensity | The luminosity of breathing | Valeur, pourcentage : 0-100. NB : actuellement non supporté | No | Yes | Yes |
| G_WorkingMode | Check working mode | Read-only values / ECO mode values / PVlink ManualBoost / PVlink SmartBoost / PVlink / ECO+ mode / PVlink+ ManualBoost / PVlink+ SmartBoost / PVlink+ / Load balance value / Power distribution / Peak-valley value / Off peak / FAST mode | No | Yes | Yes |
| G_FullContinueChargeEnable | Preheating function | Enable : on Disable : off | No | Yes | Yes |
| G_PhaseWringMethod | Grid type | TN-1-fase TN-3-fase IT-1-fase IT-3-fase | No | Yes | Yes |
| G_ForceL2RelayEnable | Phase 2 relay control | Description: sequential electrical control switch L2 forcibly closes or disconnects phase current output L2 during charging Enable: on Disable: off | No | Yes | Yes |
| G_SolarThresholdCurr | Solar current threshold setting | Unit: A | No | Yes | Yes |
| G_DaylightSavingTime | Standby delay | A value greater than 0 indicates that the threshold is activated and the actual value set. A value equal to 0 indicates that the threshold function is deactivated. | No | Yes | Yes |
| G_OffPeakCurr | Charging time during peak-valley hours | Corresponds to the duration of the peak-valley, if the option is not set, the default load is the nominal current. Fomrat: socket no. & curr1 = 10 & curr2 = 20 & curr3 = 30, etc. (supports up to 5 settings). | No | Yes | Yes |
| G_RandDelayChargeTime | Charging time delay | Unit: seconds. When the value is 0, this function is disabled. | No | Yes | Yes |
| G_OffPeakTime | Peak-valley charging time | Parameter configuration format: time = current & socket no. For example: 00:00-01:00=9&1 | No | Yes | Yes |
| GWMaxPower | Maximum charger output power | For DC chargers only | No | Yes | Yes |
| GWMaxPowerA | The output power of the A | For DC chargers only | No | Yes | Yes |
| GWMaxPowerB | Connector B output power | For DC chargers only | No | Yes | Yes |
| GWServerURL2 | Server URL2 | Only for DC chargers, under development | No | Yes | Yes |
| GWServerDURLFunction | URL2 switch | Only for DC chargers, under development | No | Yes | Yes |
| G_ServerQRCode | Server QR code | For DC chargers only | No | Yes | Yes |
| G_FreeIdTag | “freevenIdTag” modified in Plug & Charge mode | No | Yes | Yes | |
| G_WifiSSID | Wifi name | No | Yes | Yes | |
| G_WifiPassword | Wifi password | No | Yes | Yes | |
| G_4GAPN | APN | No | Yes | Yes | |
| getcountfault | Anomaly history | No | Yes | Yes | |
| G_FullContinueChargeEnable | Preheating function | For AC chargers only | No | Yes | Yes |
