Building an OCPI Server/Client Using PyOCPI
What is OCPI?
The Open Charge Point Interface (OCPI) allows for a scalable, automated roaming setup between Charge Point Operators and e-Mobility Service Providers. It supports authorization, charge point information exchange (incl transaction events), charge detail record exchange and finally, the exchange of smart-charging commands between parties.
PyOCPI is a Python implementation of OCPI based on the well known Python web framework FastAPI.
check it on PyPI.
How Py-OCPI works?
Py-OCPI requires two Python classes as the working basis. whenever OCPI server requires to provide stored data, it will use the CRUD class to get the data, then the data will be passed to Adapter class to make the data compatible with OCPI acceptable schemas. CRUD and Adapter classes are not provided by the Py-OCPI and the developer needs to provide them when using the library.
Why CRUD is not provided by Py-OCPI?
Since different projects have different architectures, We wanted to give the developer the choice of having different options for getting the required data. The developer may want to connect to an external party for getting the data so he will implement the CRUD class by HTTP requests. or the developer may want to get the data from database directly so he will initiate a database sessions inside the CRUD.
How to use Py-OCPI?
First build the app using the library FastAPI app creator. now we have different options for running the app:
standalone: and run it just like any other FastAPI app. If you’re not familiar with FastAPI deployment check this https://fastapi.tiangolo.com/deployment/manually/
sub application: mount the app as a sub app to another FastAPI app. in this way the OCPI APIs will be integrated in an already available app.
it’s recommended to run the app in standalone as a microservice beside other microservices. In this way the app will have a separate API and can be scaled easily.
What are the use cases?
Py-OCPI can by used both as a CPO or an EMSP. when it’s run as a CPO it needs to interact with a CSMS for connection with charge points. when it’s run as an EMSP it needs to have a persistent storage like a SQL database.