Legacy 809 drivers often only report energy (kWh) at the end of a session. A modern OCPP-809 driver supports Transaction Meter Values (Sampledata), sending voltage and current every 60 seconds to satisfy European MID compliance.
The ticket sat in the backlog for three sprints before anyone touched it. It was labeled OCPP-809: “Develop legacy translation layer for Series 4 Charging Units.”
The Series 4 units were old. Not "vintage" old, but "firmware-last-updated-in-2016" old. They spoke JSON, technically, but it was a dialect of OCPP 1.5 that seemed to ignore half the schema. The client wanted these units managed by a modern Central System running OCPP 2.0.1.
The spec was simple: Build a driver that acts as a man-in-the-middle. Translate up, translate down. Don’t lose telemetry. ocpp-809 driver
The driver compiled. The unit tests passed (mocking the legacy JSON was a nightmare of interface{} types). We deployed to the staging environment.
It immediately failed.
The Error: BootNotification rejected. The Log: Legacy 809 drivers often only report energy (kWh)
[OCPP-809-DEBUG] Rx: "chargePointModel": "S4-ULTRA", "chargePointVendor": "Voltex"
[OCPP-809-DEBUG] Tx (Translated): "reason": "PowerUp", "chargingStation": "model": "S4-ULTRA", "vendorName": "Voltex"
[CENTRAL-SYSTEM-ERROR] Invalid Registration Status.
The Central System rejected the handshake. Why?
It turned out the Series 4 units didn't send a chargeBoxIdentity in the HTTP header, which OCPP 1.6+ requires. The driver was trying to generate a UUID on the fly, but the Central System’s security policy required the charge point's serial number as the identifier.
I had to write a regex scraper that interrogated the TCP handshake preamble—a dirty, non-standard hack—to extract the serial number from a proprietary "hello" packet before the OCPP session even started. The Central System rejected the handshake
The EV industry is shifting to OCPP 2.0.1 (which introduces ISO 15118 Plug & Charge and Device Model). Legacy 809 drivers built for 1.6 will soon be obsolete.
Look for next-gen drivers that support:
| Test | Description | Expected Result | |------|-------------|----------------| | T1 – Setpoint change | DSO sends 50kW → 20kW limit | CSMS reduces charger power within 5 seconds | | T2 – Link failure | Cut IEC 104 link for 10 minutes | Driver keeps last limit, then fallback after timeout | | T3 – Reject invalid | DSO sends 0kW limit but min profile is 6kW | Driver rejects command, sends negative confirm | | T4 – Reverse telemetry | Charger consumes 7.2kW | Driver sends M_ME_TF_1 with value 7200 |
Based on the identifier ocpp-809, this appears to refer to a charge point driver/firmware implementing the OCPP (Open Charge Point Protocol) standard, likely version 1.6 or 2.0.1, with “809” possibly indicating a hardware platform (e.g., an STM32 or similar embedded controller).
Here are the typical features you would expect from an OCPP-809 driver:
