OCPP 1.6J is the JSON-over-WebSocket form of the Open Charge Point Protocol, released in 2015 and still dominant on chargers installed in India through 2025. The specification runs to 196 pages and clearly describes core message flows, so independent implementations should interoperate. Yet connecting a new charger model to our backend exposes divergence in at least two or three places almost every time.
These differences are patterned, not random. They cluster in six areas where the spec is underspecified or behavior is optional. Knowing them lets you test before hardware reaches a live site, rather than finding issues through failed sessions.
The Basic Message Flow
First, the usual sequence. A charger powers on and sends a BootNotification request with its vendor, model, serial number, and firmware version. The CSMS replies with Accepted, Pending, or Rejected, plus a heartbeat interval. The charger sends Heartbeat messages at that interval. Connector changes, such as a plugged-in cable, an RFID card presentation, or session start, trigger StatusNotification. Session start triggers StartTransaction. During the session, the charger may send MeterValues. At the end, it sends StopTransaction with final energy.
That is the happy path. Here are six points where chargers diverge.
Divergence 1: Heartbeat Interval Is Often Ignored
The CSMS sends heartbeatInterval in seconds in the BootNotificationResponse. The spec requires the charger to use it. Many instead follow firmware configuration, often a manufacturing default of 30 or 60 seconds.
This affects connectivity detection. If the CSMS flags a charger offline after 3 x heartbeat interval passes without a message, but the charger sends at 30 seconds while you expect 300 seconds, false alerts result. If the offline threshold uses your configured interval while the charger follows a longer default, genuine outages take longer to detect.
To validate, set a non-standard interval such as 47 seconds after the initial BootNotification exchange, then measure subsequent heartbeats. If timing does not converge to 47 seconds within a few heartbeats, the charger ignores the field.
Divergence 2: Offline Behavior Varies
OCPP 1.6 does not define which status a charger should report after losing its CSMS connection. It addresses messages on a live connection, not what a charger does offline for 2 hours.
We have observed four patterns: local card presentations are accepted and sessions stored for upload after reconnection; the charger enters Faulted and rejects new sessions; it remains Available while silently dropping session data; or it reboots every 5 to 10 minutes while reconnecting, creating dashboard noise.
For sites with intermittent connectivity, common in industrial parks or basement parking with weak cellular signal, offline behavior is critical. Test it before deployment: cut internet access for 4 hours, watch the status LED and connector, restore connectivity, and verify recovered session data.
Divergence 3: MeterValues Detail
OCPP 1.6 provides MeterValuesSampledData, which selects measurands such as energy, power, current, and SoC, and SampledDataInterval, which sets sampling frequency in seconds. A charger supporting smart metering should report session energy at that interval.
Many chargers send only final accumulated energy in StopTransaction. They send no mid-session MeterValues, so the dashboard cannot show a live kWh counter, only the final value after the session ends.
This may be adequate for pricing accuracy, but not for load management, where current kW draw is needed to enforce a site-level power cap. A charger reporting only at StopTransaction cannot join dynamic load management. Confirm mid-session MeterValues during hardware qualification before choosing a model for a load-managed deployment.
Divergence 4: LocalAuthorizationList Retention
OCPP 1.6 defines SendLocalList, allowing the CSMS to send authorized RFID tokens to a charger for local authorization during connectivity loss. The charger should retain this list across reboots. GetLocalListVersion lets the CSMS check the version stored on the charger.
Several models lose the local authorization list across power cycles. Others retain it but cap the list at 100 entries, a limit disclosed only in a hardware-manual footnote. At a site with more than 100 registered drivers, some lose access when connectivity drops.
Load 200 tokens, power-cycle the charger, query the local list version, and test authorization with a token from the second half of the list.
Divergence 5: SmartCharging Profile Handling
OCPP 1.6 has an optional Smart Charging feature profile with SetChargingProfile and ClearChargingProfile. A charger advertising SmartCharging in supportedFeatureProfiles must honor these messages.
In the field, a charger may answer "Accepted" to SetChargingProfile without applying it. Recurring weekly schedules with multiple periods are especially error-prone. We have seen chargers use only the first period, apply a profile for the current day but not the next, or return to full-power charging after reboot despite a persistent profile.
If load management relies on OCPP smart charging profiles, verify persistence and multi-period handling before deployment.
Divergence 6: StatusNotification Error Codes
A charger sending StatusNotification with status Faulted should include errorCode to classify the fault. The spec defines 15 specific error codes: ConnectorLockFailure, EVCommunicationError, GroundFailure, HighTemperature, InternalError, LocalListConflict, NoError, OtherError, OverCurrentFailure, OverVoltage, PowerMeterFailure, PowerSwitchFailure, ReaderFailure, ResetFailure, WeakSignal.
Most Faulted StatusNotifications we receive from field chargers use OtherError whatever the underlying fault. That undermines automated classification. Consistent OtherError reporting cannot distinguish a ground fault requiring an electrician from a connector lock failure that might clear after a remote reset, or a weak cellular signal that may resolve itself.
OtherError usage tracks charger firmware quality. Ask hardware vendors whether firmware maps faults to the correct OCPP error codes, and request tests that trigger known faults to confirm reporting.
Pre-Deployment Charger Model Checks
The Open Charge Alliance (OCA) offers an OCPP 1.6 conformance test tool, and an OCA conformance certificate shows that a charger passed defined test cases. We are not arguing certification is wrong. We are saying operator testing still covers gaps: offline behavior, LocalAuthorizationList persistence across power cycles, and multi-period smart charging profile handling in realistic conditions.
When onboarding a hardware model, our qualification adds 8 tests beyond any conformance certificate: heartbeat adherence, offline session logging and recovery, MeterValues sampling, LocalAuthorizationList persistence across 3 reboots, list overflow at 150 entries, SetChargingProfile application and persistence, multi-period profile correctness, and error-code specificity across 5 triggered fault types.
The tradeoff is plain: 4 hours of validation found at least one substantive issue in every charger model tested.