One Charger. Three Generations of OCPP.

EV charging hardware should give its owner a choice of software platform throughout its working life.

That principle is behind PlugStream Firmware's support for OCPP 1.6, OCPP 2.0.1 and OCPP 2.1. Our OCPP 1.6 implementation uses JSON over WebSockets, so you will see it described precisely as OCPP 1.6J in our technical specifications.

For a driver, the protocol may be invisible. For an operator choosing hardware, an installer commissioning a site or a business planning a platform migration, it matters. The charger needs to fit the management system the customer uses today, with room for that choice to change later.

What OCPP connects

The Open Charge Point Protocol defines how a charger communicates with a Charging Station Management System, usually shortened to CSMS. This is the software behind a charging network: it manages functions such as authorisation, charging sessions, meter readings, charger status and remote commands.

An open protocol gives hardware manufacturers and software providers a shared way to communicate. That helps customers choose those parts of the system separately. The Open Charge Alliance's protocol overview explains the standard and its three supported generations.

For PlugStream, that means PlugStream Cloud is a choice, rather than a prerequisite for owning our hardware. A compatible third-party CSMS can provide the management connection. The features and support available through that platform need to be agreed with its provider.

OCPP 1.6J: a practical route into existing estates

Many operators already have a management platform they want to keep. A workplace may have established access rules, a fleet may have reporting processes built around its CSMS, or a residential development may be expanding an existing charging installation.

Supporting OCPP 1.6J allows PlugStream chargers to be considered for those projects without making a platform change a condition of buying new hardware.

Our implementation includes core charging operations, Smart Charging and security extensions. It uses the same underlying charger controls while communicating in the format the selected platform understands.

The practical benefit is continuity: an operator can assess new chargers against their existing service, support and integration requirements, then upgrade the estate at a pace that suits the project.

OCPP 2.0.1: richer management over the charger's life

OCPP 2.0.1 expanded the way a management platform can understand and control a charging station. Its Device Model provides a structured approach to configuration and monitoring. The protocol also changed transaction handling and expanded security and Smart Charging capabilities.

For teams responsible for keeping an estate available, richer information can make remote diagnosis and configuration more useful. It gives the platform more context about the charger and its components when something needs attention.

OCPP 2.0.1 is not backwards compatible with OCPP 1.6. They have different message structures and application models, as the Open Charge Alliance explains in What is new in OCPP 2.0.1. Supporting both requires the firmware to handle each version's behaviour.

OCPP 2.1: a foundation for closer energy integration

Released in January 2025, OCPP 2.1 builds on the architecture of OCPP 2.0.1. The specification adds support for areas including ISO 15118-20, bidirectional charging, Distributed Energy Resource control, local cost calculation and additional payment and authorisation options. See the Open Charge Alliance's OCPP 2.1 release announcement.

These developments reflect the charger's growing role in a site's energy system. Charging decisions increasingly involve available capacity, local generation, tariffs and the needs of other equipment.

Supporting OCPP 2.1 gives our firmware a communication foundation for that direction. It does not make every capability in the specification available on every PlugStream charger. Bidirectional charging, for example, also needs a suitable vehicle, charger power electronics, site installation and management platform.

The protocol version is one part of the project specification. The complete system determines what can be delivered.

A charger should be able to outlive its first backend

A charging estate can change management platform while the physical equipment still has years of useful service ahead of it. Operators may need different reporting, a new service arrangement or support for a wider mix of hardware.

Consider a business adding chargers to an OCPP 1.6 estate while planning a future move to OCPP 2.0.1. Multi-version firmware creates a route to assess the new hardware against both platforms. The physical installation and the software migration can then be planned separately.

That flexibility also matters in mixed estates. Sites grow over time, bringing together different charger models and protocol generations. Supporting all three gives operators more options for bringing PlugStream hardware into that environment.

Each connection uses one agreed OCPP version. In PlugStream Firmware, OCPP 1.6J is selected explicitly. A connection configured for OCPP 2.1 can also offer OCPP 2.0.1, allowing the CSMS to select a version it supports. It does not automatically fall back to OCPP 1.6J.

Before a migration, confirm the installed firmware, configuration access and connection settings. Plan the change around active sessions, transaction records and any site load-management dependencies.

Interoperability needs more than a successful connection

OCPP includes optional functionality, and platforms differ in the workflows they support. Agreeing a protocol version establishes the language of the connection; the required charging behaviour still needs to be validated.

For a third-party integration, useful checks include:

• authorisation, remote start and stop, and accurate transaction records;
• charger status, meter readings and fault reporting;
• Smart Charging profiles and site power limits;
• reconnecting after an outage or charger restart;
• configuration, security and firmware-management workflows.

PlugStream-specific monitoring, app features and service workflows also depend on the platform providing them. Moving the OCPP connection does not automatically recreate the full PlugStream Cloud experience elsewhere.

This is why compatibility should be assessed around the customer's actual operating requirements.

Testing across all three versions

Our firmware development includes automated message-schema checks across the implemented OCPP 1.6J, 2.0.1 and 2.1 messages. These check that requests and responses follow the expected structure for their version.

Our wider hardware-in-the-loop testing environment combines physical charger testing with virtual chargepoints for protocol scenarios. This lets us examine communication alongside situations such as interrupted sessions, changed charging profiles and reconnecting networks.

Schema checks, simulated scenarios and hardware tests provide different kinds of evidence. They are part of development and integration validation; they do not represent OCA certification or a guarantee that every third-party CSMS combination has been tested.

Choose the charger and the platform around your project

The PlugStream 7S, 7T, 22S and 22T share this approach to open charging. The aim is lasting choice: support for the platform you use now and practical options when your estate evolves.

If you are specifying a new installation or moving an existing estate, talk to PlugStream about CSMS compatibility. Share the platform, charger models, required OCPP version and operational workflows so we can help scope the integration.