01Platform · Hardware
Any charger that speaks OCPP properly
zevOS does not manufacture hardware and does not resell it, which means it has no commercial reason to lock you to a brand. What matters is not the badge on the unit — it is which parts of the protocol the firmware actually implements.
Requirements
What a charger must implement
The first five are non-negotiable — a unit missing any of them cannot be billed or operated properly. The rest determine how expensive the charger will be to run.
- Required
OCPP 1.6J or 2.0.1 over WebSocket
JSON over a secure WebSocket, with subprotocol negotiation. SOAP-era OCPP 1.5 is not supported.
- Required
An energy register in MeterValues
Energy.Active.Import.Register at minimum, sampled during the session. A charger that does not report energy cannot be billed correctly — this is the single most important check at commissioning.
- Required
StartTransaction and StopTransaction with meter readings
meterStart and meterStop values, and a stop reason. The stop reason is what resolves most driver disputes without further investigation.
- Required
StatusNotification per connector
Connector-level state transitions with error codes. This is the raw material for availability measurement and fault triage.
- Required
Remote start, stop, unlock and reset
The core remote command set. Without it, every intervention is a site visit.
- Strongly advised
GetConfiguration and ChangeConfiguration
Readable and writable configuration keys, so configuration drift can be detected and corrected remotely.
- Strongly advised
UpdateFirmware and GetDiagnostics
Firmware over the air and remote log retrieval. The difference between a fleet you can maintain and one you must visit.
- Strongly advised
SetChargingProfile, including TxDefaultProfile
Required for smart charging and load management. Verify the unit enforces the profile rather than merely acknowledging it — read back the composite schedule.
- Strongly advised
Local authorisation list and offline transaction buffering
Essential at depots and weak-signal sites, where a connectivity outage must not stop charging.
Hardware families
Specify for the traffic that exists
The most common capital mistake in Indian charging is buying car-oriented DC for a location whose actual EV traffic is two- and three-wheelers.
| Family | Power | Connectors | Typical sites | Notes |
|---|---|---|---|---|
| LEV & light AC | 3.3 kW | Bharat AC-001, LEV sockets | Two- and three-wheeler charging points, societies, last-mile fleet hubs | The largest EV segment in India by volume and the most under-served. Cheap hardware, high utilisation, volume economics. |
| AC destination | 7.4 – 22 kW | Type 2 | Malls, hotels, offices, apartment parking, workplace banks | Long dwell time, so the scarce resource is the bay rather than the energy. Per-minute or session-fee pricing is defensible here. |
| DC low power | 15 – 30 kW | Bharat DC-001, CCS2 | Older Indian EVs, commercial three-wheelers, small fleets | Still relevant where the vehicle mix is older. Verify the connector matches the traffic before specifying. |
| DC fast | 50 – 150 kW | CCS2, occasionally CHAdeMO | Urban hubs, highway corridors, fuel forecourts | Plan throughput on 35–45 kW average from a 60 kW unit — vehicle taper and thermal derating mean nameplate power is not delivered power. |
| DC high power | 180 kW and above | CCS2, often multi-gun | Highway corridors, bus and truck depots | Check whether multi-gun units share a single power stack — two vehicles may each receive half. Smart charging is generally mandatory at these ratings. |
Before you order twenty
Buy one and put it through this
A charger that passes this sequence will be cheap to run for years. One that fails any step will generate tickets for as long as you own it.
- 01Complete a real session with a real vehicle and confirm the reported energy matches the unit’s own meter display.
- 02Pull the network connection mid-session and confirm the session continues and reconciles on reconnect.
- 03Issue a remote stop from the platform and confirm the session closes cleanly.
- 04Push a charging profile and read back the composite schedule to confirm the unit enforces it rather than merely acknowledging it.
- 05Trigger a firmware update and watch the full status trail through to Installed.
- 06Leave it connected for two weeks and check for heartbeat gaps and reconnect storms.
Mixed fleets
Multiple vendors, one operational surface
Most networks accumulate hardware from three or four vendors across several vintages, running a mixture of OCPP 1.6J and 2.0.1. zevOS keeps the protocol handlers isolated per version and normalises everything into one internal event vocabulary — so your operations team never needs to know which protocol a charger speaks in order to reset it, reconfigure it or read its uptime.
- Per-model profiles absorb vendor quirks instead of pushing them into your workflow
- Configuration standards applied across brands, with drift detected and corrected
- Firmware rolled out by model cohort, with a per-unit status trail
- Fault codes decoded into readable descriptions, vendor codes preserved alongside
Send us a model and firmware version
We will tell you exactly what it supports and where the gaps are — before the purchase order, which is the only time it is useful.