Learning Hub/Scenarios
Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.

Part of the lesson OCPI charging session lifecycle

CPO posts the stop command result

Technical
5 min
OCPI 2.2.1 and 2.3.0. OCPI 2.1.1 has no counterpart for: CPO pushes the remotely started SessionTest this flow runs against a CPO endpoint you have registered.
Test this flow
CPO posts the stop command result

The CPO posts a CommandResult to the stop command's response_url. Its ACCEPTED means the charger accepted the stop request. The Session is not completed until the CPO sends its final update.

The sandbox CPO does not start a Session for a START yet, so there is no Session to stop.

CPO
EMSP
"With the Commands module, commands can be sent from the eMSP, via the CPO to a Charge Point. Most Charge Points are hooked up to the internet via a relative slow wireless connection. To prevent long blocking calls, the commands module is designed to work asynchronously. The Sender (typically eMSP) send a request to a Receiver (typically CPO), via the Receivers Commands interface. The Receiver checks if it can send the request to a Charge Point and will respond to the request with a status, indicating if the request can be sent to a Charge Point. The Receiver (typically CPO) sends the requested command (via another protocol, for example: OCPP) to a Charge Point. The Charge Point will respond if it understands the command and will try to execute the command. This response doesn't always mean that the command was executed successfully. The Receiver (typically CPO) will forward the result in a new POST request to the Senders Commands interface."OCPI 2.2.1 specification · #mod_commands_flow"|ACCEPTED |Command request accepted by the Charge Point."OCPI 2.2.1 specification · #mod_commands_commandresulttype_enum
Explore the commands module →
Message Flow⚡eeMSPreceiverCCPOsenderCChargerUUserStep 5 of 6