Track OCPP 2.1: upstream ocpp-go PR #371, and what 2.0.1/2.1 unlock over 1.6J

[HuggeK]

Tracks OCPP 2.1 support landing in our protocol library, and records what the
newer dialects unlock — so future FTW work and charger purchases aim at the
right protocol level.

Upstream status: the library is working on it

FTW's OCPP layer is lorenzodonini/ocpp-go
v0.19.0 (1.6J + 2.0.1, pinned in go/go.mod). For 2.1:

• PR #371 — feature: OCPP 2.1 support —
  open draft by @xBlaz3kx: 185 files, +15,646 lines, opened June 2025 and
  still actively updated (last push July 2026). This is the one to watch.
• Tracking issue upstream: lorenzodonini/ocpp-go#337.
• The maintainer's master has been quiet since August 2025, so review
  bandwidth — not code — looks like the bottleneck.

Earlier upstream attempts (all closed unmerged)

• #398 feat: ocpp 2.1
• #415 feat: Add OCPP 2.1 support (foundation messages)
• #416 feat: Add OCPP 2.1 support

Three independent attempts is evidence of demand as well as of the size of the
lift.

When it lands, the FTW-side cost is deliberately small: one more handler file
and one more listener — the version-neutral core (charger state, telemetry
mapping, control semantics) does not change. See docs/ocpp.md.

What 2.0.1 already adds over 1.6J

Everything FTW does today (throttle, pause at 0 A, resume, session metering)
works on 1.6J. What 1.6J cannot do, and 2.0.1 can:

• Vehicle identity. 2.0.1 idTokens include MacAddress (autocharge) and
  eMAID (ISO 15118 Plug & Charge) — the charger tells us which car plugged
  in. 1.6J only carries the RFID idTag, which names the card, not the car.
  This is the gate for per-vehicle profiles (capacity, surplus-only,
  price-optimized targets) that switch automatically per car.
• NotifyEVChargingNeeds (with ISO 15118): the car states the energy it
  actually wants — and on DC its SoC and target SoC. Planning against
  requested energy beats guessing from a hand-typed battery capacity.
• SoC over the wire. The SoC measurand is far better supported in the
  2.0.1 transaction stream — no more anchor-plus-delivered-Wh estimation.
• Security profiles. TLS with server/client certificates, key management,
  security event log — closes the cleartext basic-auth gap docs/ocpp.md
  documents today.
• Device model. Standardized variable reporting (GetReport): phases,
  max current and capabilities become readable facts instead of installer
  folklore typed into max_charge_w.

What 2.1 adds on top (published Jan 2025, adoption still thin)

• Bidirectional power transfer (V2X/V2G) via ISO 15118-20 — steering
  discharge through standard OCPP instead of vendor paths (today FTW's only
  V2X device is the Ambibox over vendor MQTT).
• DER control functions — the charger presents as a controllable DER
  (grid-support modes), which is exactly how FTW models devices.
• Smarter charging profiles and priority charging, backward compatible
  with 2.0.1.

Buying guidance

When buying a charger for an FTW site, prefer, in order:

1. OCPP 2.0.1 with ISO 15118 ("Plug & Charge" / autocharge on the spec
   sheet) — best optimization ceiling available today, TLS-capable.
2. OCPP 2.0.1 without 15118 — still gets the transaction model, device
   model and security profiles.
3. OCPP 1.6J — fully supported, but it is the optimization floor:
   throttle/pause/metering only, card-based identity at best, no TLS.

Vendors announcing 2.1 firmware roadmaps score bonus points — 2.1 is
backward-compatible with 2.0.1, and FTW already runs one listener per dialect
(8887/8888), so new dialects slot in beside old chargers.

When upstream merges

• Evaluate the ocpp-go release carrying 2.1 (or the merged chore(release): version packages #371)
• Add the 2.1 listener + handler file (port port_v21, same shared core)
• Revisit security profiles / TLS for all dialects
• Vehicle identity → per-car profiles (depends on 2.0.1 idTokens, not 2.1)

Context: #732 (OCPP central system), #833 / #834 are
unrelated CI flakes found while shipping it. Every charger on the office bench
speaks 1.6J today.

🤖 Generated with Claude Code