What OCPP Provides, and What It Leaves Out
OCPP connects a charging station, called the Charge Point or CP, with a central server, the Charge Point Management System or CPMS. It defines messages for starting and ending sessions, reading meter data, and applying charging power profiles. It does not specify how fleet software communicates with the CPMS, how the CPMS links a session to a vehicle, or how charging records align with trip and dispatch data.
The difference between OCPP's capabilities and fleet operations' needs creates most integration problems. Once configured, the protocol handles communication with charging stations reliably. The difficult work sits in the layers above it.
OCPP 1.6 vs. 2.0.1: Know What Your Chargers Support
Most AC chargers deployed in Indonesia currently use OCPP 1.6J, the JSON version running over WebSocket. OCPP 2.0.1 improves smart charging, supports ISO 15118 Plug-and-Charge, and provides more detailed device management. However, many installed chargers still use 1.6J, so you will probably need to integrate with it regardless of your preferred version.
Before building the integration, confirm the version reported by your chargers in BootNotification. Some vendors mark hardware as "OCPP 2.0 ready" even though it ships with 1.6 firmware. Other units complete the 2.0.1 handshake but lack feature classes such as Smart Charging or Advanced Security. Firmware version and supported feature profiles are separate fields, and both need checking.
For fleet integrations, OCPP 1.6 covers the highest-value functions: remote session control, meter reporting, and charging power limits through ChargingProfile. These functions do not require 2.0.1. If you are choosing hardware for a new depot, requiring 2.0.1 is worthwhile. For an existing mixed fleet, treat 1.6J as the baseline.
OCPP and Your Fleet Data Model
OCPP uses a Charge Point-generated transaction ID for each session. It uses an idTag, such as an RFID card ID or token string, to identify the initiating entity. Neither one directly identifies the vehicle, driver, or trip record in your fleet system.
Your integration layer must preserve those relationships. A session beginning at 22:15 on Charger-04 with idTag A3-7F-9C must resolve to vehicle VH-09, a driver at the depot, a 05:30 expected end time, and a slot in tonight's charging plan. Without that link, session data remains an isolated log instead of useful operational information.
Mapping usually follows three patterns. Assigning one fixed idTag to each vehicle is easy, but fails when cards are lost or shared. Dynamic tokens issued by the fleet system are more dependable and let that system control attribution. A hybrid model combines static tags for known vehicles with remote start for exceptions. RideBlitz uses remote start and fleet-managed tokens, connecting session attribution to the dispatch schedule instead of relying on RFID practices at the depot.
Smart Charging with ChargingProfile: What Operators Often Miss
OCPP 1.6 has a Smart Charging feature set that many fleet operators leave unused. SetChargingProfile sends a ChargingProfile to a Charge Point to limit power over a defined schedule. A ChargingSchedule divides the session into periods, each with a maximum rate in watts or amperes.
This is the key integration area for fleet cost control. Rather than charging at the full AC rate from plug-in to completion, you can increase power during the deepest off-peak tariff period, reduce it during a grid demand event, and reach the target SoC by the required time instead of charging as quickly as the hardware permits.
ChargingProfile behavior requires care. A profile remains active until it expires or another profile replaces it. If fleet software loses its connection after sending one, the charger continues using the last profile received. Plan for this case explicitly: if the CPMS is offline for four hours overnight, the charger keeps following that profile. Morning checks are needed to confirm that sessions finished as planned.
In OCPP 1.6, smart charging applies at the Charge Point, not the electrical circuit. Four chargers sharing one circuit could each receive a 7.2 kW limit and overload the circuit if all operate at maximum power together. Managing grid-level load requires a local energy management controller or fleet software that coordinates profiles while understanding the circuit layout.
Integration Failure Modes to Anticipate
From the integrations completed during RideBlitz's early development, the failure modes causing the greatest operational disruption are similar across implementations:
- Timezone mismatches. OCPP timestamps are in UTC. Your local tariff windows are in WIB (UTC+7). A charging profile sent with UTC start times, applied by a charger with local time configured incorrectly, starts charging at the wrong hour. This sounds straightforward and is responsible for a disproportionate share of integration bugs in early deployments.
- Meter value drift. Some charger firmware underreports kWh consumed by a small but consistent margin. If you are using meter values for cost accounting, calibrate against your PLN electricity bill quarterly.
- ChargingProfile rejection handling. Chargers return Accepted, Rejected, or NotSupported on a SetChargingProfile call. Rejected and NotSupported require different handling. Log these responses explicitly rather than assuming Accepted silently.
- Silent fault states. Some chargers enter a sleep state during long idle periods and stop sending StatusNotification messages reliably. A charger that appears Available in your CPMS but has actually faulted at 02:00 is an unwelcome surprise at 05:30 when vehicles need to be checked out.
What to Do When Chargers Lack OCPP Support
Proprietary chargers without OCPP remain common in Indonesia, especially AC units from regional suppliers. If the hardware cannot provide OCPP, you have three practical choices: use the vendor's API, usually REST-based with polling intervals; add an OCPP gateway that translates the proprietary protocol; or treat the chargers as unmanaged and design your optimization model around them.
For AC chargers, the unmanaged option can work better than expected if fixed schedules are enforced with timer switches or smart plugs that monitor energy use. It is not a lasting solution for fleets seeking detailed optimization, but it allows operations to begin while you work toward full integration.
OCPP integration is neither fast nor simple. The main difficulty comes early. After session mapping, timezone handling, and ChargingProfile management work correctly, the protocol itself is dependable. Post-launch issues usually occur in the layer above OCPP rather than within the protocol.
