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 start command result
Technical
5 min
CPO posts the start command resultExplore the commands module →
The charger has answered the CPO. The CPO posts a CommandResult to the response_url from the command. Its ACCEPTED means the charger accepted the request; it does not show that a Session started.
Runs against the sandbox in OCPI 2.1.1. The 2.2.1 sandbox CPO keeps its one charger busy for a minute after every START, so a result here can read EVSE_OCCUPIED.
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
Message FlowStep 2 of 6