OCPP 2.1 and EV Charging Meter Data: What EVSE Manufacturers Should Check- Zhejiang Yongtailong Electronic Co., Ltd

OCPP interoperability is an important part of EV charging system development, but it does not verify the complete EV charging meter-data chain.

The Open Charge Alliance has scheduled its OCPP 2.0.1 and OCPP 2.1 Plugfest & Conference Asia for 25–26 August 2026 at the COEX Conference Center in Seoul. The event gives Charging Station and Charging Station Management System (CSMS) implementers an opportunity to test their OCPP implementations with multiple partners, identify issues and improve practical interoperability.

That testing is important, but it covers only one part of the complete data chain:

Energy Meter
→ Charger Controller
→ Charging Station Software
→ OCPP Communication Layer
→ CSMS

OCPP defines communication between a charging station and a CSMS. It is not an energy-meter certification standard. OCPP interoperability testing does not by itself validate meter accuracy, Modbus registers, controller mapping, measurement timing, polling logic or billing-data correctness.

Although this article uses OCPP 2.1 as the current reference point, the separation between meter-level integration and OCPP-level communication also applies to many OCPP 1.6 and OCPP 2.0.1 deployments.

For EVSE manufacturers, the practical question is therefore not only:

Does the charging station support OCPP 2.1?

It is:

Can the complete system collect, interpret, store and transmit the correct meter data from the hardware meter to the CSMS?

Where the Energy Meter Sits in an EV Charging System

The energy meter is installed at a defined electrical metering point inside or beside the charging equipment.

Depending on the charger architecture, this may involve:

An AC energy meter on an input or output circuit
A DC energy meter on the DC output path
A DIN rail meter inside an AC charging enclosure
An embedded metering module connected to the charger controller
A meter intended for billing, separate from internal monitoring sensors

The required metering boundary should be defined by the charger architecture, billing model and applicable market rules.

The hardware meter normally communicates with the charger controller through a local interface such as RS485/Modbus, pulse output, CAN, serial communication or another internal interface, depending on the design.

The controller reads the meter values, converts them into the required internal format and passes them to the charging-station software. The station then sends selected measurement and transaction information to the CSMS through the applicable OCPP implementation.

This creates two separate integration layers:

Meter-to-controller integration
Charging station-to-CSMS OCPP communication

A valid OCPP message does not prove that the original meter register, unit, scaler, direction or timestamp was interpreted correctly before transmission.

Meter selection also depends on whether the charging architecture measures energy on the AC side or the DC side. For a broader explanation of metering-point selection, see YTL’s guide to AC vs DC metering in EV charging projects.

What EV Charging Meter Values Usually Include

Required values depend on the charger type, billing model, monitoring requirements, load-control strategy and target market.

Common meter values may include:

Cumulative active energy
Transaction-start meter value
Transaction-stop meter value
Calculated transaction energy, where applicable
Voltage
Current
Active power
Reactive power, where required
Power factor
Frequency
Import or export energy
Per-phase measurements
Timestamped values
Meter status
Communication or alarm information

Transaction energy should not automatically be treated as a direct hardware-meter register. In many systems, it is calculated from the difference between cumulative meter values captured at transaction start and transaction stop.

A billing application may mainly require cumulative energy, transaction boundaries, timestamps and meter identification. A monitoring application may also need voltage, current, power and status values. A local load-management function may require faster updates than the CSMS reporting process.

Not every meter provides every value, refresh rate or resolution. The selected meter should therefore be evaluated against the controller, charger software and project requirements.

Hardware Meter Data Versus OCPP Platform Data

A value shown in a CSMS is not necessarily a direct, unchanged value from the hardware meter.

It may pass through several processing stages:

The meter measures and stores an electrical value.
The controller reads a register or data object.
The controller applies the correct data type, unit and scaler.
The charger associates the value with an EVSE, connector or transaction.
The station maps the value to the applicable OCPP measurand and related metadata, such as context, phase, location, EVSE, connector or transaction association.
The station assigns or retains the required timestamp.
The value is transmitted according to the selected OCPP version and implementation.
The CSMS stores, validates, aggregates or processes the result.

The exact message structure and metadata organisation vary between OCPP versions. Project teams should therefore confirm which OCPP edition, schemas and certification profile apply to the selected implementation.

An error at any stage can create incorrect platform data even when the energy meter and OCPP connection are both operating.

Common integration errors include:

Reading the wrong register
Incorrect byte or word order
Incorrect signed or unsigned interpretation
Wrong decimal scaling
Confusing cumulative and interval values
Reversing import and export direction
Assigning data to the wrong EVSE or connector
Incorrect timestamp or time-zone conversion
Losing values during communication interruption
Resetting or replacing a cumulative-energy counter without correct handling

EVSE manufacturers should compare the same test value across the complete trace:

Meter Reading or Meter Diagnostic Value
→ Controller Diagnostics
→ Charging Station Log
→ OCPP Message
→ CSMS Record

This method also works for embedded metering modules that do not have a local display.

Measurement, Refresh, Polling and Reporting Intervals

Several timing concepts must be distinguished.

Timing Item	Meaning
Measurement interval	How often the meter internally measures or calculates a value
Data refresh interval	How often the meter updates the available register or output
Controller polling interval	How often the charger controller reads the meter
OCPP reporting interval	How often the charging station sends selected information to the CSMS

These intervals do not have to be identical.

For example, an energy meter may refresh active power quickly, the controller may poll it every second for local load control, and the charging station may report selected or aggregated information to the CSMS at a longer interval.

Project teams should define:

Meter measurement or calculation interval
Register refresh interval
Controller polling interval
CSMS reporting interval
Transaction-start and transaction-stop capture timing
Timestamp source
Clock-synchronisation method
Required data resolution
Counter persistence after reboot
Missing- and duplicate-data handling

The system should distinguish between:

Fast local control data
Periodic monitoring data
Transaction and billing data
Diagnostic and event data

A meter suitable for a billing application may not automatically provide the refresh rate needed for dynamic load management. Similarly, a fast internal sensor does not automatically meet legal-metrology or billing requirements.

Register Mapping Between the Meter and Charger Controller

Supporting Modbus communication does not guarantee compatibility with every EV charger controller.

For a Modbus energy meter, the EVSE manufacturer should verify:

Register addresses
Function codes
Data types
Byte and word order
Signed or unsigned format
Scaling factors
Units
Read-only and writable registers
Data refresh rate
Baud rate
Parity and stop bits
Device address
Timeout and retry behaviour
Exception handling
Firmware and register-map version consistency

The controller must map each meter register to the correct internal variable. The charging-station software must then map that internal value to the applicable OCPP measurand and associated metadata, as defined by the selected OCPP version.

Meter Item	Integration Check
Cumulative energy	Register, unit, scaler, persistence and rollover behaviour
Transaction values	Start and stop capture points and calculation method
Voltage	Per-phase, channel or total value
Current	Per-phase, channel or output value
Active power	Sign convention and import/export direction
Timestamp	Meter clock, controller clock or station time source
Meter status	Normal, warning, communication failure or fault
Update timing	Meter refresh, controller polling and CSMS reporting intervals

Testing should use known loads and compare the meter reading, controller diagnostics, charging-station log, OCPP message and CSMS record.

Offline Storage and Data Reconciliation

A charging station may continue operating while its communication with the CSMS is temporarily unavailable.

The charger controller or station software should implement the project-defined strategy for:

Preserving transaction continuity
Storing required meter and transaction records
Retaining timestamps
Resending unsent information
Preventing duplicate records
Restoring message order
Reconciling transaction data
Handling counter rollover or reset
Handling meter replacement

The system specification should define whether local storage contains:

Raw meter readings
Processed transaction-start and transaction-stop values
Calculated transaction values
Constructed but unsent OCPP messages
Local database records
A combination of these records

This distinction affects retransmission, reconciliation and auditability.

The hardware meter may continue accumulating energy during a CSMS outage, but that does not mean every intermediate value has been stored by the controller or charging-station software.

Representative test scenarios should include:

CSMS connection loss during charging
Charger-controller reboot
Meter communication interruption
Power failure
Delayed message delivery
Duplicate retransmission
Out-of-order data
Meter replacement
Counter reset or rollover

What OCPP Interoperability Testing Verifies

OCPP Plugfests allow Charging Station and CSMS implementers to test their OCPP implementations against multiple partners.

Depending on the implemented functional blocks, test scenarios, OCPP version, configuration and participating systems, interoperability testing may help evaluate:

Message exchange
Required protocol behaviour
Transaction communication
Meter-data message handling
Error responses
Security-related communication
Smart-charging functions
Selected OCPP feature interactions

The exact coverage depends on the implemented functional blocks, test scenarios and participating systems.

A Plugfest is not automatically equivalent to complete OCPP certification, validation of every optional feature or verification of the charging station’s internal meter-data chain.

OCPP 2.1 extends OCPP 2.0.1 with capabilities and enhancements related to areas including ISO 15118-20, bidirectional charging, distributed energy-resource control and other charging functions.

OCPP 2.1 Edition 1 was published as IEC 63584-210:2025. However, project teams should confirm which OCPP edition, schemas and certification profile apply to the actual charging-station and CSMS implementation.

What Still Requires Meter-Level Testing

OCPP interoperability testing does not by itself verify:

Meter accuracy
AC or DC metering-point suitability
Modbus register correctness
Controller-driver implementation
Unit and scaler conversion
Meter refresh performance
Controller polling logic
Timestamp source
Counter persistence
Offline meter-data handling
Billing suitability
Tamper protection
Behaviour after restart
Compatibility with each meter firmware version

A charging station may exchange valid OCPP messages while reporting an incorrect value because of an internal mapping, scaling, timing or storage error.

EVSE manufacturers should therefore perform three separate validation layers:

Meter Accuracy and Electrical Testing
2. Meter-to-Controller Integration Testing
3. Charging Station-to-CSMS OCPP Testing

Passing one layer does not prove that the other two layers have passed.

Billing, Signed Meter Values and Certification Checks

Billing and metrology requirements vary by country, jurisdiction, charging scenario and business model.

Depending on the project, buyers may need to review:

Meter accuracy requirements
MID-related certification
German Eichrecht requirements
OCMF or other signed-meter-value formats
Market-specific approvals
Display and transparency requirements
Data signing and verification
Seal or tamper requirements
Transaction-record retention
Certificate scope
Approved firmware or system configuration

These requirements do not apply uniformly to every country or charging scenario.

The responsible party and required evidence may relate to the meter, charging station, transparency software, CSMS workflow or complete charging system, depending on the jurisdiction.

Signed meter values are one part of the end-to-end data chain. Their transmission through OCPP does not by itself prove that all local legal-metrology, transparency, signature-verification or billing requirements have been satisfied.

OCPP is a communication protocol between the charging station and CSMS. It does not replace legal-metrology approval, meter certification, billing-system validation or market-specific compliance assessment.

EV Charger Meter Integration Checklist

Check Area	What to Verify
Charger type	AC or DC charging architecture
Metering point	Input, output, connector or transaction boundary
Electrical range	Voltage, current and direct, shunt or CT measurement
Required values	Energy, power, voltage, current, status and alarms
Timing	Measurement, refresh, polling and reporting intervals
Interface	RS485, Modbus, pulse, CAN or another local interface
Register mapping	Address, type, byte order, unit and scaler
Controller handling	Polling, conversion, storage and error handling
OCPP mapping	Applicable measurand and associated metadata for the selected OCPP version
Timestamp	Source, synchronisation and time-zone handling
Offline operation	Stored record type, resend, ordering and duplicate handling
Certification	Market-specific metrology and billing requirements
Testing	Meter, controller, charging station and CSMS validation
Change control	Meter firmware, controller software and register-map versions

How YTL Can Support EV Charging Metering Hardware

Zhejiang Yongtailong Electronic Co., Ltd. (YTL) manufactures energy metering and power measurement products for EV charging, commercial and industrial energy management, PV/ESS, smart building and power distribution applications.

Relevant YTL product capabilities may include:

AC energy meters
DC energy meters
DIN rail energy meters
RS485 / Modbus energy meters
Energy meters with fast data refresh for selected load-control applications
Communication-enabled metering products
Project-based OEM/ODM support

YTL can support initial meter evaluation based on:

Charger architecture
AC or DC metering point
Electrical range
Required meter values
Communication interface
Measurement refresh and controller polling requirements
Target market
Certification needs

Support may include:

Register-map review
Sample data validation
Communication-option review
Sample testing
Project-specific technical evaluation

Final controller mapping, OCPP implementation and end-to-end CSMS validation require cooperation between the meter supplier, EVSE manufacturer, controller developer and platform provider.

Product capabilities vary by model, firmware, communication interface and certificate scope. Modbus communication, data refresh rate, billing suitability and charger-controller compatibility should be confirmed for the selected meter and tested in the intended EVSE environment.

FAQ

What is OCPP meter data?

OCPP meter data is measurement information sent by a charging station to a CSMS. The original measurement may come from a hardware energy meter, but it is read, mapped and processed by the charger controller and station software before transmission.

Does OCPP 2.1 communicate directly with the energy meter?

Usually not. OCPP is used between the charging station and CSMS. The hardware meter normally communicates with the charger controller through Modbus, pulse, CAN or another local interface.

Does Modbus support guarantee EV charger compatibility?

No. Compatibility also depends on register addresses, data types, byte order, units, scaling, refresh rate, polling logic, controller software and error handling.

Does passing an OCPP Plugfest verify meter accuracy?

No. Plugfest testing focuses on interaction between Charging Station and CSMS implementations. Meter accuracy and meter-to-controller mapping require separate testing.

How is transaction energy calculated?

In many systems, transaction energy is calculated from the difference between cumulative energy recorded at transaction start and transaction stop. The exact method depends on the meter, controller, charging-station software and platform design.

Why are timestamps important?

Timestamps connect measurements to transactions and reporting periods. Incorrect clock settings, time zones or delayed messages can create billing and reconciliation errors.

What should be stored when the CSMS is offline?

The system specification should define whether the charger stores raw meter readings, transaction-start and transaction-stop values, calculated transaction data, unsent OCPP messages or a combination of these records.

Do signed meter values guarantee billing compliance?

No. Signed meter values may support a billing or transparency workflow, but legal compliance depends on the applicable market rules, meter and charger configuration, verification software, certificate scope and complete system implementation.

What should EVSE manufacturers provide when requesting a meter?

They should provide the charger type, metering point, voltage and current range, required values, measurement refresh and controller polling requirements, communication interface, register requirements, target market, billing purpose and expected quantity.

Conclusion

OCPP 2.1 supports communication and interoperability between charging stations and CSMS platforms, but reliable EV charging metering begins below the OCPP layer.

The complete data chain includes:

Hardware Energy Meter
→ Charger Controller
→ Charging Station Software
→ OCPP Communication
→ CSMS

EVSE manufacturers should verify:

Metering-point suitability
Required meter values
Register mapping
Measurement, refresh, polling and reporting intervals
Timestamp behaviour
Cumulative-energy handling
Offline storage and reconciliation
OCPP data mapping
Signed-meter-value and market-specific billing requirements
Meter-, controller- and CSMS-level test results

Planning an EV charging meter integration project? Contact YTL and share your charger architecture, AC or DC metering point, required values, communication interface, polling requirements and target market.