Driver - Ocpp-809

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: ocpp-809 driver

[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. The driver compiled

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 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. The Central System rejected the handshake

Look for next-gen drivers that support:

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.