- Different OCPP versions and vendor extensions per charger fleet.
- Session events, charging state, and meter values need custom mapping.
- Each deployment becomes another implementation branch to maintain.
- Session, power, status, and telemetry arrive in one consistent model.
- Applications consume one interface regardless of the charger brand.
- Real-time and historical access live behind the same governed surface.
OCPP gives you a standard — but not simplicity
The Open Charge Point Protocol (OCPP) was created to solve a real problem: EV chargers from different manufacturers couldn't communicate with central management systems from different vendors. OCPP established a common protocol layer, and today almost every commercially deployed AC and DC charger supports it. In that respect, it succeeded.
But OCPP is a wire protocol, not a developer-friendly API. It is a WebSocket-based message exchange system with a specific JSON (or SOAP, for older versions) message schema. Building an application on top of OCPP directly means managing persistent WebSocket connections, handling message queuing and delivery guarantees, parsing OCPP message types, and dealing with the significant variance in how different manufacturers implement the standard. OCPP compliance does not mean identical behavior.
The result is that even with OCPP as a foundation, developers building fleet management systems, billing platforms, or smart charging applications face substantial integration work — not the instant plug-and-play the existence of a standard might suggest.
The OCPP landscape: 1.6 vs 2.0
Two major OCPP versions are in active deployment. Understanding the differences matters for any integration project.
OCPP 1.6 is the most widely deployed version. The vast majority of installed chargers — in parking facilities, workplaces, and public locations — run OCPP 1.6. It covers the core use cases: session management, meter values, status notifications, and remote start/stop. Its limitations are in device management, security, and smart charging profiles.
OCPP 2.0.1 is the current specification and is increasingly required for new installations, particularly in regulated markets and fleet deployments. It adds significantly improved security (TLS certificate management, signed meter values), more granular smart charging capabilities, better device management, and support for ISO 15118 (the vehicle-to-grid communication standard). New commercial and public charging infrastructure is moving toward OCPP 2.0.1.
Both versions expose similar core data — session start and stop, energy delivered, power draw, connector status — but the message structure, field names, and feature support differ significantly. An integration that works perfectly with a 1.6 charger may require substantial rework for a 2.0.1 charger from the same manufacturer.
Why direct OCPP integration is painful
Building directly on OCPP requires solving several problems that have nothing to do with your application's purpose.
- WebSocket connection management: every charger maintains a persistent WebSocket connection to a central system. You need to handle reconnection logic, heartbeat monitoring, and connection state across potentially thousands of chargers simultaneously.
- Vendor divergence: charger manufacturers interpret the OCPP spec with their own quirks. A field marked optional in the spec may be required by one vendor's firmware. Meter value sampling intervals vary. Status codes are sometimes mapped differently. Each new charger brand requires investigation and adjustment.
- Message parsing complexity: OCPP messages are typed (BootNotification, MeterValues, StatusNotification, etc.) and need to be routed, validated, and stored differently. Building and maintaining the message handler is non-trivial engineering.
- Security requirements: OCPP 2.0.1 mandates TLS with client certificates for charger authentication. Managing a certificate authority and certificate lifecycle for a charger fleet is an operational burden most application developers should not have to take on.
- Data normalization: meter value readings arrive in different units (Wh, kWh), at different sampling rates, with different measurand identifiers. Normalizing this into a consistent timeseries requires its own pipeline.
The EDX approach to EV charger data
EDX handles the OCPP layer entirely. Chargers connect to the EDX platform using their standard OCPP configuration — pointing the charger's central system URL at the EDX endpoint. EDX manages the WebSocket connections, handles both OCPP 1.6 and 2.0.1, and normalizes all incoming telemetry into the standard EDX data model.
Your application then accesses charger data through the same REST and WebSocket API used for solar panels, batteries, and meters. A charger is simply a device in the EDX object hierarchy. Its data points follow the same schema, its timeseries are queryable with the same endpoint, and its status is updated in real time just like any other connected asset.
This means you can build a unified dashboard that shows solar generation, battery state of charge, and EV charger activity side by side — without writing separate integration code for each asset type. It also means adding a new charger brand to your deployment requires no code changes on your side: if EDX supports the brand, it appears in your device list automatically.
Data points available through the EDX EV charger integration
Through the normalized API, the following data is available for every connected OCPP charger:
- Session start and stop: precise timestamps for when a charging session began and ended, with the connector identifier and (where available) the vehicle or RFID token that initiated the session.
- Energy delivered per session: total kWh delivered in a session, derived from meter start and stop values. This is the primary data point for billing.
- Power draw over time: instantaneous power (kW) at configurable sampling intervals throughout the session. Useful for load management and grid impact analysis.
- Connector status: real-time status for each connector (Available, Preparing, Charging, SuspendedEV, SuspendedEVSE, Finishing, Faulted). Alerts can be triggered on Faulted status.
- Error codes: OCPP error codes normalized into a consistent format, with timestamps. Essential for remote diagnostics and maintenance scheduling.
- Cumulative meter values: total energy delivered by a charger over its lifetime, useful for hardware utilization reporting.
Use cases for normalized EV charger data
Fleet management
Fleet operators need visibility across all charging events for all vehicles, regardless of which charger brand is deployed at each depot. Normalized session data from EDX gives fleet managers a single view of charging activity, energy cost, and vehicle readiness — without the complexity of per-brand integrations.
Billing and cost allocation
Property managers and employers who provide charging as a benefit need per-session energy data to allocate costs accurately. EDX session data — start time, stop time, energy delivered, connector ID — provides the inputs required for automated billing calculations.
Load balancing and smart charging
Buildings with multiple EV chargers and limited grid capacity need to distribute available power intelligently across active sessions. Real-time power draw data from EDX enables load management applications to stay within grid connection limits while maximizing charging throughput.
V2G readiness
As bidirectional chargers and vehicles capable of vehicle-to-grid operation become more common, the data infrastructure needs to be in place before dispatch decisions can be made. EDX tracks the relevant data points — available discharge capacity, state of charge from the vehicle, charger bidirectionality — and exposes them through the API so that VPP and energy management applications can incorporate EV assets into their optimization logic. Read more about the broader VPP architecture.
Frequently asked questions
Does EDX support both OCPP 1.6 and OCPP 2.0?
Yes. EDX normalizes data from chargers running both OCPP 1.6 and OCPP 2.0.1. The version difference is handled by the platform — your application sees a consistent data model regardless of which protocol version the charger uses. Mixed-version fleets (some chargers on 1.6, others on 2.0.1) are fully supported.
Can I use the EV charger data for billing purposes?
Yes. EDX provides energy delivered per session (kWh), session start and stop timestamps, and connector identifiers — the core data points needed for billing calculations. For regulatory compliance in metered billing contexts, verify that your metering setup meets the legal accuracy requirements in your jurisdiction. Most OCPP chargers include a certified energy meter; EDX passes the meter values through without modification.
What is V2G and does EDX support it?
Vehicle-to-grid (V2G) is the ability for an EV to discharge stored energy back into the grid or building through a bidirectional charger. EDX tracks the data points required for V2G readiness — state of charge, available capacity, charge and discharge power — and exposes them through the standard API. The V2G dispatch logic itself is implemented in the optimization layer of your application or VPP platform, consuming the data EDX provides.
OCPP is a wire protocol, not a developer API. The distance between those two things is where most EV integration projects lose months.
Ready to access EV charger data through a clean REST API? See the EDX platform or book intro to review your charging infrastructure. You can also explore the full energy data API guide for the broader integration picture.