Understanding OCPP Logs

With ChargePilot, your charging stations communicate with the ChargePilot controller via OCPP. There are predefined messages (actions) that are exchanged between the charging station and the ChargePilot controller. These include messages to authenticate a charging event, status and error messages, and reboots of a charging station.

It is possible to search multiple values via the search bar, e.g. Action, Charging Station ID, Status.

Below you will find more detailed information about the different log levels in ChargePilot and their contents.

OCPP Log Level

There are three different log levels in ChargePilot:

Minimal Logs, required for firmware updates (UpdateFirmware, BootNotification, FirmwareStatusNotification)
Info Log Level
Debug Log Level

By default, your site is at the Info Log level. This allows you to view relevant information and analysis about status changes, error messages and transactions at your location.

Info Log-Level

The following messages (actions) are included in the Info Log level:

	Message	Content according to OCPP 1.6
1	`Authorize`	Before the owner of an electric vehicle can start or stop charging, the Charge Point has to authorize the operation. The Charge Point SHALL only supply energy after authorization. When stopping a Transaction, the Charge Point SHALL only send an Authorize.req when the identifier used for stopping the transaction is different from the identifier that started the transaction.
2	`BootNotification`	After start-up, a Charge Point SHALL send a request to the Central System with information about its configuration (e.g. version, vendor, etc.). The Central System SHALL respond to indicate whether it will accept the Charge Point.
3	`FirmwareStatusNotification`	A Charge Point sends notifications to inform the Central System about the progress of the firmware update. The Charge Point SHALL send a FirmwareStatusNotification.req PDU for informing the Central System about the progress of the downloading and installation of a firmware update. The Charge Point SHALL only send the status Idle after receipt of a TriggerMessage for a Firmware Status Notification, when it is not busy downloading/installing firmware.
4	`StartTransaction`	The Charge Point SHALL send a StartTransaction.req PDU to the Central System to inform about a transaction that has been started. If this transaction ends a reservation (see Reserve Now operation), then the StartTransaction.req MUST contain the reservationId.
5	`StatusNotification`	A Charge Point sends a notification to the Central System to inform the Central System about a status change or an error within the Charge Point. The following table depicts changes from a previous status (left column) to a new status (upper row) upon which a Charge Point MAY send a StatusNotification.req PDU to the Central System.
6	`StopTransaction`	When a transaction is stopped, the Charge Point SHALL send a StopTransaction.req PDU, notifying to the Central System that the transaction has stopped.

Debug Log-Level

The following messages (actions) are included in the debug log level in addition to the info log level:

CancelReservation
CertificateSigned
ChangeAvailability
ChangeConfiguration
ClearCache
ClearChargingProfile
DataTransfer
DeleteCertificate
DiagnosticsStatusNotification
ExtendedTriggerMessage
FirmwareStatusNotification
GetCompositeSchedule

GetConfiguration
GetDiagnostics
GetInstalledCertificateIds
GetLocalListVersion
GetLog
Heartbeat
InstallCertificate
LogStatusNotification
MeterValues
RemoteStartTransaction
RemoteStopTransaction

ReserveNow
Reset
SecurityEventNotification
SendLocalList
SetChargingProfile
SignCertificate
SignedFirmwareStatusNotification
SignedUpdateFirmware
TriggerMessage
UnlockConnector
UpdateFirmware

Not every charging station supports all OCPP messages. However, some messages are mandatory for integration with ChargePilot. More information can be found here: OCPP "must"-requirements for charger integration in ChargePilot

Content of the OCPP messages

Each action consists of several values, which are explained in the table below:

	Value	Description
1	`action`	Type of message, e.g. “StatusNotification”
2	`connector_id`	charging point ID
3	`request`	Request. Depending on the action, the request contains different information.
4	`site_id`	ID of the site
5	`charger_id`	charging station ID
6	`response`	Response. Depending on the action, the response contains different information.
7	`datetime`	date and time of the OCPP message
8	`source`	Source: The source indicates where the message came from. "cp" means that the request was sent from the charging station to ChargePilot. "csms" (= charging station management system) means that the request was sent from the ChargePilot controller.

OCPP Logs Download

ChargePilot provides downloadable OCPP logs to enable detailed charging event and error reporting. The download is filterable by charging station ID, OCPP status messages, and actions as well as by date and time. This enables users to sort for the information relevant to their analysis and decreases the amount of fields in the download.

Descriptions and examples of each field in the download are shown in the below table. Please note that at the moment, this feature has a maximum of 10,000 displayable records. In order to successfully export, the filtering option can be used to refine your search.

For more detailed information about each field, please review the Open Charge Alliance’s OCPP 1.6J documentation, linked below.

Field Descriptions

Header in OCPP Log Download	Description	Example	Is this field sent by every EVSE? or
Datetime	Time and date of message sent via OCPP, in UTC	2024-11-26T10:03:49Z
Action	Refers to the specific operation or command being performed in a message exchange between the Charge Point and the Central System (in this case, ChargePilot)	StatusNotification,StopTransaction, Heartbeat
Charger ID	Charging station ID (unique for each charging station)	Charger 5
Connector ID	Charging point ID. Indicates which port on the charging station the information is coming from (e.g. 0,1,2). Typically, 0 indicates the main cabinet and 1, 2, or 3 indicate additional charging ports on the charging station.	1	If blank, this may indicate a single port charger.
Request Vendor Error Code	A manufacturer-specific error code that provides additional information for debugging or error reporting. Charger manufacturers have different error codes, which provide different levels of granularity. please reach out to your EVSE manufacturer for a detailed explanation of each.	CHARGER_DOOR_OPEN
Request Timestamp	Time and date of message when processed by ChargePilot. There may be a minor delta (<2s) between this field and datetime, due to data granularity discrepancies. Associated with StartTransaction, StopTransaction, StatusNotification.	2024-11-26T10:03:49Z
Request Status	Refers to the operational state of a charging point and is communicated using `StatusNotification` messages. This status indicates various phases of the charging process, including states like "Available," "Preparing," "Charging," "SuspendedEV," "SuspendedEVSE," "Finishing," and "Faulted." Each state reflects the charging point's readiness, active charging state, or issues requiring attention.	Faulted
Request Error Code	Indicate various issues encountered during communication between a charging station and a back-end system. These errors are usually reported through OCPP's `StatusNotification` message, helping operators diagnose and resolve charging station issues efficiently.	EVCommunicationError or ConnectorLockFailure
Request Info	Denotes any additional information related to the message, typically an error.	State transition
Request Vendor ID	Unique identifier used to specify the manufacturer or vendor initiating a particular request, often associated with `StatusNotification` messages. Configured by EVSE manufacturer.	HLX
Request ID Tag	Vehicle RFID, often associated with `StopTransaction` and `StartTransaction` messages. This contains the identifier which requested to stop the charging. It is optional because a Charge Point may terminate charging without the presence of an idTag, e.g. in case of a reset.	43434
Request Meter Stop	The energy meter reading when a transaction ends (in watt hours), sent along with StopTransaction. EVSE’s send this data differently, either continuously or resetting at every transaction/	1387299
Request Transaction ID	A unique identifier for a charging session, consistent between Start Transactions, Stop Transactions, and `MeterValues`. Configured by the EVSE.	4356987
Request Reason	Indicates the reason for stopping a transaction. Only associated with `StopTransaction` messages.	PowerLoss
Response ID Tag Info Status	Indicates the authorization status of a charging session linked to a specific RFID tag or identifier. Often associated with `Authorize`, `StartTransaction`, or `StopTransaction` messages.	Accepted
L1 Voltage*	Output voltage delivered to the EV via the connector, in volts	31.234
L2 Voltage*	Output voltage delivered to the EV via the connector, in volts	31.234
L3 Voltage*	Output voltage delivered to the EV via the connector, in volts	31.234
Voltage*	Output voltage delivered to the EV via the connector, in volts	101
L1 Current.Import*	Instantaneous current flow to EV (in L1), in amps	5
L2 Current.Import*	Instantaneous current flow to EV (in L2), in amps	5
L3 Current.Import*	Instantaneous current flow to EV (in L3), in amps	5
Current.Import*	Instantaneous current flow to EV, in amps	15
L1 Power*	Instantaneous active power imported by EV. (usually W or kW) in L1. Corresponds to Power.Active.Import	12
L2 Power*	Instantaneous active power imported by EV. (usually W or kW) in L2. Corresponds to Power.Active.Import	12
L3 Power*	Instantaneous active power imported by EV. (usually W or kW) in L3. Corresponds to Power.Active.Import	12
Power*	Instantaneous active power imported by EV. (usually W or kW). Corresponds to Power.Active.Import	12

*Different chargers report these fields in different formats. This means that depending on the charger, certain columns may be blank. Also, not all chargers report these additional data points. When the charger does report this data, it will appear in the OCPP logs download as reported by the charger. Please check with your EVSE manufacturer for more detailed information on these granular fields.

Detailed information about OCPP 1.6 actions can be found here: ocpp-1.6.pdf