How to stop a charging session with stopTransaction

Intro

To stop an OCPP charging session, the electric vehicle (EV) charger and charging management system must follow a strict process. If done incorrectly, it might produce errors and block EV chargers for the next driver.

There are many ways of stopping the EV charging session (and we will take a glance at all of them). However, the most common triggers are the user pressing a stop button on the EV charger’s user interface, the EV reaching full charge, or the EV charger deciding to stop the charging session (e.g., reached time limit or hardware error). 

Regardless of the method used to stop the session, the EV charger (OCPP client) will send a new status notification and a StopTransaction request to the charging management system (OCPP backend).

These OCPP messages terminate the charging session and are amongst the most common messages in the EV charging world. If you have not done so yet, we recommend that you understand how to start an EV charging session before learning how to stop one. To do so, please read the OCPP startTransaction guide first.

To stop the OCPP charging session, also known as a transaction, initiated by the OCPP client, we need the following OCPP messages:

• StatusNotification request
• StopTransaction request

‍

How to Use a Status Notification Update to Stop an OCPP Charging Session

Before stopping a charging session, the EV charger is in the “charging” mode. This means a charging session was previously initiated, and the last StatusNotification sent by the EV charger was “charging.”

In order to stop the charging session, the EV charger sends a new StatusNotification request (statusNotification.req) to the OCPP backend. The status notification will change the active status from “charging” to one of the following Charge Point statuses:

• "Available"
• "SuspendedEV"
• "Finishing"
• "Unavailable"
• "Faulted"

The variety of status types reflects the variety of reasons for a charging session to end. We explain the conditions that trigger each charge point status below:

"Charging"→ "Available"
‍The charging session ends while no user action is required (e.g., the fixed cable was removed on the EV side).

"Charging" → "SuspendedEV"
‍Charging stops upon EV request (the electric vehicle does cannot take any additional energy).

"Charging" → "suspendedEVSE"
Charging stops upon EVSE (Electric Vehicle Supply Equipment) request (e.g., smart charging restriction, the transaction was not correctly authorized in a StartTransaction.conf).

"Charging"→ "Finishing"
‍The user stops the transaction via the charger UI or a RemoteStopTransaction message + further user action is required (e.g., remove the cable and leave the parking bay).

"Charging" → "Unavailable"
‍The charging session has ended + no user action is required + the connector is scheduled to become Unavailable.

"Charging" → "Faulted"
‍A fault is detected that prevents further charging operations (charger error).

This might sound complex or unnecessary but it gives many important insights into the charger error during the charging operation and will help to operate charging locations efficiently.

‍

To Summarize, when the EV charger wants to initiate the stop of the charging session, the charger will send a new statusNotification.req message to the OCPP server, changing from “charging” to one of the status transactions above. Without this status update, the charger will not stop charging.

If the OCPP backend is ready, it will respond with a statusNotification.conf message to confirm that the message was received and understood. The confirmation does not contain any information.

Below you see the flow of the status notification request in OCPP:

‍

‍

As mentioned above, the statusNotification.req message is used widely in many scenarios beyond the stop of the session. It includes the following information:

• connectorId: Is the identifier of the charging connector, which is typically 1 or 2. If the charge point has more plugs, this number will be higher.‍
• errorCode: Shows potential errors that are reported by the charger. To start the session, it should ideally contain “NoError”. However, possible errors can be “EVCommunicationError”, “UnderVoltage”, etc. In many cases, the status will show “OtherError” and a vendor error code in the additional info or vendorErrorCode field. For large operations, these error codes become very important and will offer insights into possible hardware errors.‍
• status: As mentioned above, this should be changing from “Charging” to “Available”, “Finishing”, etc. 

‍

‍

Note: If the charger has more than one outlet, the connectorId will be numbered 1,2,3, etc. This is important as some chargers allow simultaneous charging. Connector 1 might then be on the status “Available” while connector 2 is still on the status “Charging.” If only one single plug can charge at a time, the other connectors should send a statusNotification request containing the status “Unavailable.”

‍

Here you see an example of the statusNotifcation.req

{
    "connectorId": 2,
    "errorCode": "NoError",
    "status": "SuspendedEV",
    "timestamp": "2022-09-12T10:01:00.515Z"
}

‍

‍

How to Stop Transaction Request and Energy Report in OCPP

After the status change from “Charging” to one of the six possible statuses, the EV charger will send the stopTransaction Request (startTransaction.req).

The time between the status change and the stop transaction request can vary depending on the EVSE manufacturer. At Ampcontrol, we have observed times between 1 second and 10s of seconds. This is the essential information that the charging has stopped, sent from the OCPP client to the OCPP server.

Upon receipt of a StopTransaction.req, the OCPP server responds with a StopTransaction.conf. Therefore, the server will verify the information contained in the stop transaction request, such as the transactionId, timestamp, or idTag.

‍

‍

Besides a stop timestamp, the transactionId, and the idTag, the OCPP stopTransaction message also contains two beneficial fields: reason and meterStop.

The “reason” field identifies the trigger for the charging session’s termination. This helps the charging point operator troubleshoot the charging operation and can inform the driver why their charging session was stopped. Possible reasons are:

• Local: Stopped locally via user request at the Charge Point. This is a regular termination of a transaction. Examples: presenting an RFID tag or pressing a button to stop.
• PowerLoss: Complete loss of power.
• Reboot: A locally initiated reset/reboot occurred.
• Remote: Stopped remotely via user request. This is a regular termination of a transaction—examples: termination using a smartphone app or exceeding a (non-local) prepaid credit.
• SoftReset: A soft reset command was received.
• EVDisconnected: The emergency stop button was used, or the vehicle was disconnected. 
• DeAuthorized: The transaction was stopped because of the authorization status in a StartTransaction.conf
• Other: Any other reason
• UnlockCommand: OCPP backend sent an Unlock Connector command (allows to unlock a charge point plug physically).

The “meterStop” field reports the energy usage at the end of the charging session. This helps to properly report the total kilowatts charged and the total energy costs for that charging transaction.

Note: The OCPP backend (CMS) typically applies a sanity check to verify the data in the stopTransaction.req. However, the OCPP backend should always respond with a StopTransaction.conf. Failing to respond with a StopTransaction.conf will only cause the Charge Point to try the same message again as specified in Error responses to transaction-related messages.

‍

To summarize, the request and confirmation message both include essential information that we want to discuss:

• idTag: Shows the identifier which requested the charging termination. It is optional because a Charge Point may terminate charging without the presence of an idTag, e.g., in case of a reset.
• meterStop: Contains the meter value in Wh for the connector at the end of the transaction. 
• timestamp: Contains the date and time at which the transaction was stopped.
• transactionId: Contains the transactionId as received by the StartTransaction.conf.
• reason: Shows the reason why the transaction was stopped.
• transactionData: This contains transaction usage details relevant for billing purposes. Moreover, the transactionData element is used as a container for any number of MeterValues, using the same data structure as the meterValue elements of the OCPP MeterValues.req
• idTagInfo: Contains information about authorization status, expiry, and parent id.

‍

Here you can see an example for a stopTransaction.req and the stopTransaction.conf:

stopTransaction.req

{
    "reason": "Local",
    "transactionId": 568161113,
    "meterStop": 4329600,
    "timestamp": "2022-09-08T10:31:26.127Z"
}

‍

stopTransaction.conf

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

‍

‍

Summary

The stopTransaction and statusNotification messages are important OCPP messages that are frequently used at EV charging networks or private charging hubs.

The typical process to terminate a charging session is:

1. Change charger status from “Charging” to “Available,” “SuspendedEV,” etc.
2. Stop the charging process via user interaction, vehicle, charger, or remote command.
3. EV charger sends the stopTransaction.req message, which contains meter values for proper reporting.