ocpp-proxy is a simple 1-1 OCPP WebSocket proxy. A charger connects to this proxy, which opens a
single upstream connection to one CSMS (central server) and relays messages transparently in both
directions. It does not parse or route based on OCPP message content - it is a pass-through relay.
This is a deliberately simplified sibling of ocpp-2w-proxy (a two-way proxy that fans a charger's
messages out to a primary and secondary CSMS). Do not port two-way/multi-server logic back into this
project - if that's needed, use ocpp-2w-proxy instead.
Single-file Python application, no package structure:
ocpp-proxy.py- entire proxy implementation (connection handling, relay loops, entrypoint)ocpp-proxy.ini- runtime configuration (logging levels, host/port, upstream server URL)requirements.txt- Python dependenciesDockerfile,compose.yaml- container packaging
pip install -r requirements.txt
python ocpp-proxy.py --config ocpp-proxy.ini
Charger connects to ws://<proxy-host>:<port>/<charger_id>; the proxy forwards to
<ext-server.server>/<charger_id>.
- Keep it a single file. This project's entire value is being simple and easy to audit - don't split into modules or add abstractions unless the file becomes genuinely unwieldy.
- No OCPP message parsing/validation beyond what's needed for the relay loops. If you need per-message
logic (inspecting Call/CallResult/CallError types, tracking message IDs, etc.), that's a sign the
change belongs in
ocpp-2w-proxyinstead, not here. - Config lives in the
.inifile viaconfigparser, not environment variables or hardcoded values. - Logging goes through the module-level
logger(logging.getLogger("proxy")); per-logger levels are set from the[logging]section of the config file. - No test suite exists. Verify changes by running the proxy against a real or mock OCPP charger/CSMS WebSocket pair.