Split ISO/DIN capabilities

[premultiply]

What & why

The single iso151182 device capability lumped three distinct EV charging communication protocols into one
tag. This PR splits it into three explicit tags and reframes the capability documentation from wire-protocol
names to the features evcc actually derives from each protocol:

• iso15118-2 — ISO 15118-2
• iso15118-20 — ISO 15118-20
• din70121 — DIN 70121

Motivation (from review feedback): a user doesn't care which protocol a charger speaks on the wire — they care
what evcc gains from it (reading SoC, identifying the vehicle, …). The three protocols genuinely derive
different evcc-relevant capabilities, so keeping them separate is meaningful, and the docs should describe the
derived capability rather than the acronym.

This description doubles as background material so the capability docs / external documentation can be written
from it.

---

Background: the three protocols

All three are High-Level Communication (HLC) protocols that run as HomePlug Green PHY power-line
communication over the Control Pilot line, on top of the basic IEC 61851-1 signalling. They differ in scope and
in what vehicle data they expose.

	DIN 70121	ISO 15118-2	ISO 15118-20
Role	DC predecessor of ISO 15118-2	1st-generation HLC	2nd-generation HLC (2022)
Connector scope	DC only (CCS)	AC + DC	AC + DC
Security	none (no TLS)	optional TLS 1.2	mandatory TLS 1.3

They coexist via dual-stack: the shared SupportedAppProtocol handshake negotiates the highest protocol both
sides support and falls back (−20 → −2 → DIN 70121).

---

Derived evcc capabilities (what each tag actually means)

Derived capability	DIN 70121	ISO 15118-2	ISO 15118-20
SoC readout	✅ continuous, DC (EVRESSSOC)	✅ DC only — ❌ not over AC	✅ AC + DC, continuous (DisplayParameters.PresentSOC)
Battery capacity / energy	⚠️ EVEnergyCapacity (optional)	⚠️ optional, DC only	✅ BatteryEnergyCapacity + Min/Target/Max SoC
Vehicle identification	✅ EVCCID / MAC (Autocharge)	✅ EVCCID / MAC (Autocharge)	✅ EVCCID / MAC (Autocharge)
Power/current control loop	✅ DC current loop	✅ DC only (AC → PWM, not HLC)	✅ AC + DC (Dynamic-mode setpoints)
Bidirectional / V2X	❌	❌	✅ BPT (AC/DC → V2G/V2H/V2L)

1. State of charge (the primary evcc benefit)

The charger obtains the connected vehicle's SoC and hands it to evcc — no vehicle/cloud integration needed. It
is transmitted continuously during the session (in the repeating charge-loop message), as an integer percentage.

Important AC/DC nuance: ISO 15118-2 transmits SoC only for DC charging — the standard defines no SoC
field for AC sessions. Therefore a plain AC wallbox speaking ISO 15118-2 gets no SoC. Some AC wallboxes
(e.g. openWB Pro, using Bender CC613 / chargebyte / Hardy Barth controllers) work around this with a DC
handshake trick: at plug-in they briefly signal a DIN 70121 DC connection, read the SoC (and whatever battery
fields the car exposes) over that channel, tear it down, and then charge normally via IEC 61851-1 AC PWM. This
yields a one-time SoC at plug-in, not a continuously updated value. ISO 15118-20 fixes this — it carries SoC
natively over AC.

2. Vehicle identification — via EVCCID / MAC (Autocharge)

All three protocols carry the EVCCID (the EV communication controller's MAC address) in SessionSetupReq.
This is the practically usable vehicle identifier — exactly what "Autocharge" uses — and it works the same
across DIN 70121, ISO 15118-2 and ISO 15118-20.

• Caveat: it only works when the vehicle uses a stable, fixed MAC (OEM best practice: EVCCID = fixed,
  non-duplicated MAC). Vehicles that randomise their MAC for privacy cannot be identified this way.
• Plug & Charge / contract certificates are not relevant here: ISO 15118-2/-20 Plug & Charge yields a
  billing/contract identity (eMAID), not a vehicle identity, and requires a full V2G-PKI backend with
  provisioned certificates (rare in the field). It is an authorization/billing mechanism with no practical
  vehicle-identification use for evcc, so it is intentionally left out of the "identify" framing.

3. Power / current control loop during charging

Whether the protocol offers a practically usable closed-loop power/current regulation during the session:

Communication form	Practical control loop?
IEC 61851-1 PWM (AC baseline — every AC charger)	✅ Yes — Control Pilot duty cycle, continuous ≈6–80 A. This is what evcc uses to control AC wallboxes.
DIN 70121 (DC)	✅ Yes — CurrentDemand loop, EVSE sets the max current/power limit each ~150–200 ms; the EV follows
ISO 15118-2 — DC	✅ Yes — same CurrentDemand loop
ISO 15118-2 — AC	❌ Not practical — the ChargingStatus loop carries no setpoint; changing power requires a full renegotiation (coarse, slow). The real AC limiter remains the PWM
ISO 15118-20 — AC + DC	✅ Yes — Dynamic control mode: per-loop EVSETargetActivePower setpoint, no renegotiation; BPT can command discharge

Takeaway: on AC, the real power regulation is always the IEC 61851-1 PWM duty cycle — which every AC
charger does. So "dynamic power control" is not a distinguishing benefit of the iso15118-2 / din70121
tags. The only genuinely new control capability in this family is ISO 15118-20's Dynamic mode + BPT
(real-time setpoints and bidirectional charging).

4. Battery capacity / energy

Optional fields (EVEnergyCapacity, EVEnergyRequest, FullSOC, BulkSOC in −2/DIN; BatteryEnergyCapacity
and Min/Target/Max-SoC in −20). In −2/DIN these are optional and frequently left empty by real vehicles, so a
charger cannot rely on them. −20 makes these first-class and reference-clear.

Note — computing SoC from energy fields is not a viable substitute. One might try
SoC ≈ (EVEnergyCapacity − EVEnergyRequest) / EVEnergyCapacity. In practice this is unsound: both fields are
optional (often 0/empty), EVEnergyRequest may target the driver's SoC target rather than "full" and may
include charging losses/preconditioning (error of tens of %), the capacity reference (gross vs usable) is
unspecified, and both are sent only once at session start (never refreshed). On DC the direct EVRESSSOC
is mandatory anyway; on AC the capacity field doesn't exist. No production project does this.

5. Bidirectional charging (V2X)

Only ISO 15118-20 supports bidirectional power transfer (BPT) — AC-BPT and DC-BPT enabling V2G/V2H/V2L, with
Scheduled and Dynamic control modes. DIN 70121 and ISO 15118-2 are charge-only. This is −20's headline addition
and is forward-looking for evcc.

---

References

Standards/technical sources used to compile the background above:

• Typhoon-HIL protocol references — DIN 70121,
  ISO 15118-2,
  ISO 15118-20
• CharIN — ISO 15118-20 DC-BPT interoperability guide
• Fastned — Autocharge whitepaper ·
  EVgo — vehicle OEM interoperability best practices (EVCCID = fixed MAC)
• Wikipedia — ISO 15118 ·
  evcc — ISO 15118 docs

[poohnet]

As #31446 has been merged, the WARP4 template has to be changed now as well.

[andig]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in a9f43e7 (merged latest master and fixed the conflict) with a follow-up compatibility fix in 6e81aa6.

[poohnet]

According to @rtrbt din70121 should be added as well:

BTW if #31468 is merged first, the capabilities have to be changed: WARP4 implements both iso15118-2 and din70121 (and later iso15118-20, but this will still take a while)

[naltatis]

@premultiply can you phrase this from a user/feature perspective (identify, soc, ...).

[andig]

Wofür brauchen wir das denn überhaupt also was würde ein Anwender mit der Information machen? Für evcc relevant ist das m.E. nur, wenn wir daraus evcc Fähigkeiten ableiten. Welche wären das jeweils (also z.B. SoC auslesen)?

[premultiply]

Ausgangspunkt: "iso151182" als einziges Capability-Tag ist sehr ungenau bzw. unzureichend.

Zu diskutieren ist natürlich ob man dies wie hier vorgeschlagen (weiter) anhand der gewählten aber nicht weniger für den gemeinen Anwender nicht so geläufigen Spec-Namen oder anderer Tags macht.

Ich habe Claude mal gezielt recherchieren lassen und die PR-Beschreibung aktualisiert.
Durchaus lesenswert als die gewünschte technische Hintergrundinformation über die jeweiligen Fähigkeiten der Protokolle/Spezifikationen.

[naltatis]

Important AC/DC nuance: ISO 15118-2 transmits SoC only for DC charging — the standard defines no SoC
field for AC sessions. Therefore a plain AC wallbox speaking ISO 15118-2 gets no SoC. Some AC wallboxes
(e.g. openWB Pro, using Bender CC613 / chargebyte / Hardy Barth controllers) work around this with a DC
handshake trick: at plug-in they briefly signal a DIN 70121 DC connection, read the SoC (and whatever battery
fields the car exposes) over that channel, tear it down, and then charge normally via IEC 61851-1 AC PWM. This
yields a one-time SoC at plug-in, not a continuously updated value.

Interesting. Hier passiert ja auch ein Mix an Standards. Spricht für mich auf jeden Fall dafür, dass wir hier auf die Feature-Ebene bei den Capabilities gehen sollten. Also sowas wie initialSoc, continuousSoc ...
Mit welchem Verfahren die Wallbox das dann mit dem Fahrzeug rausbekommt ist aus Nutzersicht (vmtl. sogar aus evcc-Sicht) ja Nebensache.

[andig]

Ausgangspunkt: "iso151182" als einziges Capability-Tag ist sehr ungenau bzw. unzureichend.

Aber unzureichend wofür? Warum sollte uns das interessieren? Wir spezifizieren hier ja kein WB Datasheet? ich würde gerne nur Dinge dokumentieren, die wirklich für uns relevant sind.