ocpp: a Python implementation of the Open Charge Point Protocol

The protocol, the two versions, and the errata

The ocpp package is a Python implementation of the JSON version of the Open Charge Point Protocol, which is the protocol an electric vehicle charge point speaks to a central management system. The package supports OCPP 1.6 with errata v4, and OCPP 2.0.1 with Edition 2 FINAL dated 2022-12-15 and the Edition 3 errata of 2024-11.

The errata detail is the interesting part. Both versions are still in the field, and the difference between 1.6 and 2.0.1 is not cosmetic, so a library that tracks the errata of both is doing real work rather than shipping a message list. The README is precise about which document revisions are covered, which is the kind of precision that matters when you are debugging a charge point that will not complete a handshake.

The repository topics call it a framework and name both client and server, and the examples directory has three folders, examples/v16/, examples/v201/ and examples/v21/, so both directions of the conversation and more than one version are covered by runnable material rather than by documentation alone.

The package is on PyPI as ocpp, the documentation is on Read the Docs at ocpp.readthedocs.io, and there is a separate page in that documentation for the central system side, which tells you the project thinks of the two ends as separate audiences.

The project is MIT licensed and is maintained by The Mobility House, and the last push to the repository was on 2026-10-04 with the release 2.1.0 published on 2025-07-16 after 2.0.0 in January 2025.

A licence split that runs through the repository

The licence section of the README does something that most projects do not: it splits the repository in two.

Everything except the documents in docs/v16 and docs/v201 is licensed under MIT, with the copyright held by The Mobility House. The documents in docs/v16 and docs/v201 are licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public Licence.

So the code is yours to use, modify and vendor without obligation, and the specification material that ships alongside it is not, because the NoDerivatives condition forbids adapting those documents. For a project whose value is the fidelity of the protocol, keeping the specification text verbatim and the licence honest about it is a coherent choice: the alternative, paraphrasing the specification to get around a share-alike clause, would be worse for everyone.

The practical consequence for a user is small but real. If you are building a product that embeds the specification material, that is a different licensing situation from a product that imports the Python package, and the two files in the repository are where you find out which is which.

The rest of the governance is conventional and complete, with a SECURITY.md for the security policy, a CONTRIBUTING.md, a CODE_OF_CONDUCT.md and a SUPPORT.md, all of which the README links directly.

Installing it is pip, and the choice is between PyPI and a clone

The installation section is short, which is what you want from a library with no build step of its own.

pip install ocpp

Or, if you want the source, clone the project and install it manually.

pip install .

The package is built with Poetry, and the manifest says so directly, with a build system requiring poetry-core at 2.0.0 or newer and below 3.0.0. The runtime dependency list is short: jsonschema, and Python itself.

That single runtime dependency is worth understanding rather than dismissing. A protocol implementation whose only non-standard dependency is a JSON Schema validator is almost certainly validating the message payloads against schemas, and that is a meaningful design choice in a protocol where a malformed frame is a rejected handshake. It also means the library itself brings very little into your dependency tree, and that most of the behaviour you will be relying on is the project's own code rather than a framework's.

The Python version requirement is where the manifest is worth a second look. The dependency section says python is at least 3.11 and below 4, while the classifiers still list support for 3.8, 3.9, 3.10, 3.11, 3.12 and 3.13. The classifiers describe what the package was tested against at some point, and the constraint is what the install will actually enforce, and for a library this is the kind of drift that catches a team with a pinned 3.10 image in CI.

The Makefile is the developer entry point

The Makefile is the fastest way to understand how the project is developed, and it is a well organised one.

The default goal is help, and the help target lists the targets with their descriptions: build for the wheel through Poetry, deploy, which is explicitly marked as not recommended and only for when it is really needed, install for the dependencies in the environment, update for the lock file, lint for the linting checks, unit-tests for the test suite, tests for everything, and a release target that takes a semantic version and bumps the project version with Poetry, also updating the version in the docs source configuration.

There is a detail in that last one that shows the level of care. Bumping the version in a Python package is one line, but a documentation site that reports the wrong version is the sort of small wrongness that generates support questions, so the release target fixes both.

The documentation build is a single command, and it is the standard Sphinx invocation.

poetry run sphinx-build -b html docs/source docs/build

The Makefile also handles the case where Poetry is not installed, with an install target that either uses an existing installation or pip installs it, and it errors out with a clear message if there is neither a global install nor an activated virtual environment. The documentation at the end of the help output says to check the Makefile to know exactly what each target is doing, which is the sort of instruction that saves a newcomer an hour.

Pytest, hypothesis and the JSON Schema dependency

The development dependencies describe a serious testing setup, and one entry in particular is a good sign.

Pytest is there with pytest-asyncio for the asynchronous tests and pytest-cov for coverage. The formatting and linting is a triple of black, isort and flake8, with black configured for a line length of 88 and isort set to the black profile, and there is a .flake8 file at the root for the rest.

The interesting one is hypothesis, a property-based testing library. For a protocol implementation, property-based testing is a natural fit, because the interesting properties are the ones a fixed test case will not reach: that a message with a missing field is rejected, that a payload with an out-of-range value is rejected, that the same call sequence produces the same state. Combined with the runtime dependency on jsonschema, the picture is of a library that validates what it sends and receives against the schema rather than trusting the shape.

For an EV charging protocol, that matters more than it would for a typical API client. A charge point that sends a malformed BootNotification or a StatusNotification with a bad timestamp is a charge point that a central system may refuse, and the failure appears on the other side of a network connection in a device you may not have physical access to.

The Sphinx build and the sphinx-rtd-theme in the dev dependencies are what produce the documentation site, and the readthedocs configuration at the root ties it together.

A project that changed hands and kept its version scheme

The acknowledgements section records a handover, and it is worth reading because maintainer turnover is a real risk for a protocol library.

Until the end of 2024 the project was led and maintained by Auke Oosterhoff and Jared Newell, and the README thanks them for their work. Since then the project has been led by Chad Meadowcroft, Mohit Jain and Patrick Roelke, with links to each of their profiles.

That is a change of lead within a year, and the release history is the evidence that it went well rather than badly. Version 2.0.0 was released on 2025-01-03, a release candidate for 2.1.0 followed on 2025-07-02, and 2.1.0 shipped on 2025-07-16. The last push to the repository was on 2026-10-04, so the code is still moving even though the last tagged release is from mid-2025.

The gap between the two is not alarming for a library like this, where the protocol versions it supports change outside the maintainers' control, and where a release has to coordinate support for two protocol generations at once. The authoring credits in the package metadata are a long list of eleven names, which is another sign of a project with a broad contributor base rather than one maintained by a single pair of people.

For an adopter, the practical point is that this is a library with a real community and a recent change of lead, and the CHANGELOG.md in the repository is where the detail of what changed between versions lives.

Editorial conclusion

ocpp fits a team building or testing an EV charge point or a charge point management system in Python, and who need both ends of the protocol implemented rather than one of them. It does not fit a team that needs the XML flavour of OCPP, since the package covers the JSON version only, and it does not fit a team that needs a certification-ready stack, since this is a protocol library rather than a compliance product. Verify three things before you build on it: which protocol version your charge point actually speaks, because 1.6 and 2.0.1 have different message sets and different security models, which Python version you will run, since the dependency floor is 3.11 even though the package classifiers still list older versions, and whether you need the specification documents, which are licensed under Creative Commons Attribution-NoDerivatives rather than the MIT licence that covers the code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mobilityhouse/ocpp on GitHub
4. README
5. Releases