OCPP WS IOocpp-ws-io

Comparison

How the ocpp-ws-io ecosystem approaches common EV scalability challenges differently from other Node.js libraries.

Comparison with Alternatives

Building a scalable OCPP Central System (CSMS) or Station Client involves navigating multiple architectural trade-offs: memory management, horizontal clustering, smart charging mathematics, and protocol translation.

The ocpp-ws-io ecosystem isn't the only option. Here's how our ecosystem approach fundamentally differs from other popular Node.js OCPP libraries.

A note on honesty: Our ecosystem is newer and has a smaller user base compared to the alternatives listed below. It has been tested primarily in controlled environments and small-scale deployments — not yet at the scale of libraries with years of community adoption.

The comparisons below are based on our reading of each library's public source code and documentation. If anything is inaccurate, please open an issue.


1. Ecosystem Scope vs. Isolated Libraries

Most open-source packages in the Node.js EV charging space supply only the WebSocket RPC parsing layer. Everything else is left as an exercise for the developer.

What ocpp-ws-io ecosystem addresses differently: We recognized that parsing JSON is only 10% of the battle.

  • Smart Charging: No other mainstream Node.js library ships with a mathematical load-balancer constraint solver. When you use the ocpp-smart-charge-engine, you avoid rolling your own power distribution algorithms.
  • Protocol Proxying: Transitioning from OCPP 1.6 to 2.1 usually breaks everything. Unique to our ecosystem, ocpp-protocol-proxy allows you to invisibly patch the gap by translating the payloads live on the wire.
  • Diagnostics: While other libraries require you to connect real hardware, the ocpp-ws-cli gives you a suite of fuzzers, load-testers, and interactive terminal simulators.

2. @voltbras/ts-ocpp

@voltbras/ts-ocpp is a popular, strongly typed, TypeScript-first OCPP library.

Where they excel:

  • Excellent out-of-the-box TypeScript types.
  • Simple class-based OOP API design.
  • Larger community and more mature adoption.

What our Core RPC (ocpp-ws-io) addresses differently:

  • Clustering: ts-ocpp stores connections in memory class instances. When scaling across multiple pods behind a load balancer, tracking stations requires custom pub/sub broker code. ocpp-ws-io natively provides a RedisAdapter for seamless unicast routing across multi-node kubernetes clusters.
  • Rate Limiting: We include socket-level token bucket rate limiters that can drop high-frequency DDoS metrics (e.g., MeterValues) before parsing, preserving CPU capacity.
  • Path-based Routing: ts-ocpp relies heavily on single class handlers. ocpp-ws-io offers Express-style path routing (OCPPRouter) to safely ringfence middleware and authentication (/api/v1 vs /api/v2).

3. ocpp-eliftech

ocpp-eliftech is one of the oldest JavaScript/Node packages for OCPP implementation.

Where they excel:

  • Longest track record — it has been used in production for years.
  • Complete implementation of OCPP 1.6-J.
  • Minimal and unopinionated design.

What our ecosystem addresses differently:

  • Modern Protocol Focus: eliftech is tied to OCPP 1.6. The ocpp-ws-io ecosystem has native, deeply validated auto-generated schema typings for OCPP 2.0.1 and OCPP 2.1.
  • Schema Validation: ocpp-ws-io implements incredibly rigorous JSON schema validation using AJV, smartly transforming malformed packets straight into valid OCPP-J error framing (FormatViolation).
  • Idempotency Keys: To prevent duplicate database processing on unstable cell networks, our RPC layer supports deterministic message IDs.

4. rpc-websockets / Generic RPC implementations

While not an OCPP library, many teams pipe raw WebSocket JSON-RPC through generic libraries like rpc-websockets and manually structure their payloads.

Where they excel:

  • Extremely lightweight and highly flexible.
  • No OCPP-specific constraints imposed on the developer.

What our ecosystem addresses differently:

  • Protocol Awareness: rpc-websockets doesn't understand the semantic differences between a CallError (Type [4]) and a generic socket fault. ocpp-ws-io enforces the official OCPP-J messaging sequence meticulously.
  • Mandatory Correlation: Generic RPC libraries allow fire-and-forget logic. OCPP fundamentally requires every action to be strictly correlated with a CallResult. We enforce this at compile-time while explicitly supporting the rare NOREPLY opt-outs.

5. Horizontal Scalability Philosophy

When moving from a local .env setup to a 5,000+ EVSE Kubernetes cluster, the architecture of your socket broker matters.

ConcernTypical In-Memory Librariesocpp-ws-io ecosystem / Core RPC
Multi-Node RoutingManual implementation requiredNative Redis presence registry with O(1) routing
Connection RehydrationConnections lost on restartEager Redis presence re-registration on exponential reconnect backoffs
Surge Handling (Thundering Herd)No built-in protectionRandomized ±25% ping jitter + strict token bucket throttling

When to Use What

Your SituationRecommended Choice
Simple single-instance OCPP 1.6 app, rely on vast mature community@voltbras/ts-ocpp or ocpp-eliftech
Building an interconnected OCPP 2.1 platform from scratchThe ocpp-ws-io ecosystem
You need to load balance multiple cars on a single breakerocpp-smart-charge-engine
Upgrading backend software but stuck with legacy 1.6 hardwareocpp-protocol-proxy

The ocpp-ws-io ecosystem is an open-source tool suite built to solve specific infrastructure problems. If those problems aren't yours, the other libraries listed here are highly capable choices.

On this page