Tinkerforge WARP: add WARP4 support with vehicle SoC via ISO 15118 by poohnet · Pull Request #31446 · evcc-io/evcc

poohnet · 2026-07-03T11:52:38Z

Adds support for the recently released Tinkerforge WARP4 charger. WARP4 inherits the WARP2/3 API, so charging control already works with the existing warp-ws implementation. What's new is ISO 15118 communication: the wallbox reads the vehicle's SoC at charge start and estimates it during the session, exposed via the ev/state API.

WARP4 Smart/Pro added to the combined tinkerforge-warp-ws template with per-product capabilities (iso151182 on both, meter on Pro)
warp-ws registers api.Battery when the iso15118 feature is announced in info/features (WARP4 firmware 2.12.2 or later), returning api.ErrNotAvailable while no vehicle SoC is known, in which case evcc falls back to the vehicle's own SoC source
live SoC updates via the existing websocket connection
vehicle identification by MAC address: identify prefers the ISO 15118 MAC from ev/state over the RFID tag, so vehicles can be matched via their configured identifiers
WARP's own phase auto switching is now also disabled on WARP4 devices (same built-in 1p/3p switching as WARP3)
template requirements document the wallbox configuration: identification needs "Autocharge" or "Read state of charge" enabled; reading the SoC needs "Read state of charge", which is only available on the WARP4 Pro (built-in energy meter required); firmware 2.12.2 or later

TODO

verify against WARP4 hardware
WARP4 firmware release announcing the iso15118 feature (released as 2.12.2)
re-verify with released firmware 2.12.2
if Split ISO/DIN capabilities #31468 is merged first, change the capabilities to iso15118-2 and din70121 (WARP4 implements both)

poohnet · 2026-07-03T17:51:41Z

My VW ID.4 is identified instantly and the reported SoC is correct.

sourcery-ai

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="templates/definition/charger/tinkerforge-warp4-ws.yaml" line_range="5" />
<code_context>
+products:
+  - { brand: TinkerForge, description: { generic: WARP4 Smart } }
+  - { brand: TinkerForge, description: { generic: WARP4 Pro } }
+capabilities: ["iso151182", "mA", "rfid", "1p3p", "dim"]
+requirements:
+  description:
</code_context>
<issue_to_address>
**issue (review_instructions):** The capability "iso151182" appears to be a typo and is inconsistent with the usual "iso15118" naming used in other templates.

In other charger templates, the ISO 15118 capability is typically labeled "iso15118". Using "iso151182" here will likely break capability detection and is inconsistent with the established wording in the templates directory. Please adjust this entry to match the standard capability name defined in templates/README.md / other existing templates.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `templates/**/*.yaml`

**Instructions:**
Verify that the changes comply to the rules defined in templates/README.md. Also check consistence (wording) with other files inside templates directory.

</details>
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

andig · 2026-07-04T08:23:49Z

@@ -162,6 +160,14 @@ func NewWarpWS(ctx context.Context, uri, user, pass, emURI, emUser, emPass strin
 		}
 	}

+	// WARP4: probe the ev/state api providing vehicle data read via ISO 15118;
+	// no locking needed, the websocket goroutines are not started yet
+	var ev warp.EvState


Sorry if I have my picky day, but I don't like this either: Getting here only to test for the result somewhere else creates more confusion (and is not what I meant). Just to be sure: every other feature is detectced via HasFeature. This is not possible here?

Unfortunately not (at least not now): the firmware only announces evse, meter(s), nfc, phase_switch etc. in info/features, the ev module does not register a feature (checked all addFeature calls in the sources). So probing the api is the only option. Reworked it to read like hasFeature: stateless probe, called where the result is used. I'll ask Tinkerforge to add a feature flag so this can switch to hasFeature eventually.

But maybe it's worth opening a PR for adding "ev" to the info/features, so that evcc can drop the probe in the future.

@andig, should we defer this PR until the "ev" feature is available in the WARP4 firmware?

/cc @rtrbt any chance to get this announced as feature?

This should be a "no-brainer". I've just opened a PR and will check this evening...
Tinkerforge/esp32-firmware#503

Announcing the "ev" feature works fine and with the latest changes evcc still correctly identifies my car and reads the SoC.
So we'll have to wait for the Tinkerforge PR being merged...

@andig, please re-review the commit.

This should be a "no-brainer". I've just opened a PR and will check this evening...
Tinkerforge/esp32-firmware#503

Sorry, this took a while. I've changed the PR to add the "iso15118" feature, see the PR for an explaination.

andig · 2026-07-04T14:30:37Z

LGTM

poohnet · 2026-07-04T14:33:34Z

LGTM

Do you want me to squash the commits in the PR or are you going to squash-merge them later?

andig · 2026-07-05T12:53:00Z

I can always squash when committing :)

rtrbt · 2026-07-08T09:20:45Z

LGTM except that the feature is now called "iso15118" instead of "ev". 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)

poohnet · 2026-07-08T09:51:51Z

Thanks @rtrbt, I've changed the code accordingly and test this evening with the latest WARP4 firmware from master...

sourcery-ai

Hey - I've reviewed your changes and they look great!

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

poohnet · 2026-07-08T16:04:00Z

@andig, @rtrbt - successfully tested on the latest master 👍

[lp-1  ] INFO 2026/07/08 15:58:50 car disconnected
[lp-1  ] INFO 2026/07/08 15:59:20 car connected
[lp-1  ] INFO 2026/07/08 15:59:20 vehicle updated: unknown -> VW ID.4

So IMHO this PR is ready for merge now...

rtrbt · 2026-07-09T09:03:06Z

One nitpick: WARP4 chargers ship with "Read state of charge" disabled to disable the PLC modem/ISO15118 communication completely. We do this because with the modem enabled, the charger would have to wait two minutes before switching to the old charging process via IEC 61851 when charging a non-ISO vehicle, for example a Twingo.

You could either

Add a paragraph to the documentation that enabling "Read state of charge" is necessary for both the SoC, as well as the EV's mac address to be seen by EVCC,

or (if EVCC decides that waiting two minutes before starting to charge non-ISO vehicles is a better decision than requiring the user to change the configuration) enable "read_soc" in iso15118/config , as is done with the phase auto-switch here:

evcc/charger/warp-ws.go

Lines 138 to 152 in 4f71e96

    
           // Phase Auto Switching needs to be disabled for WARP3 and WARP2 + EM 
        
           // Necessary if charging 1p only vehicles 
        
           typ, err := w.getWarpType() 
        
           if err != nil { 
        
           	return nil, err 
        
           } 
        
           if typ == "warp3" || (typ == "warp2" && emURI != "") { 
        
           	enabled, err := w.disablePhaseAutoSwitch() 
        
           	if err != nil { 
        
           		return nil, err 
        
           	} 
        
           	if enabled { 
        
           		w.log.WARN.Println("disabled WARP phase auto switching") 
        
           	} 
        
           }

evcc/charger/warp-ws.go

Lines 449 to 463 in 4f71e96

    
           func (w *WarpWS) disablePhaseAutoSwitch() (bool, error) { 
        
           	uri := fmt.Sprintf("%s/evse/phase_auto_switch", w.URI) 
        
           	var state struct { 
        
           		Enabled bool `json:"enabled"` 
        
           	} 
        
           	if err := w.GetJSON(uri, &state); err != nil { 
        
           		return false, err 
        
           	} 
        
           	if !state.Enabled { 
        
           		return false, nil 
        
           	} 
        
           	req, _ := request.New(http.MethodPost, uri, request.MarshalJSON(map[string]bool{"enabled": false}), request.JSONEncoding) 
        
           	_, err := w.Do(req) 
        
           	return true, err 
        
           }

poohnet · 2026-07-09T09:51:35Z

Thanks for the context @rtrbt! I would prefer documenting it over auto-enabling: switching read_soc on costs non-ISO vehicles the two minute fallback delay, which the owner should decide deliberately (unlike the phase auto switch, which evcc must disable for its phase control to work at all).

One suggestion though: could the firmware announce iso15118 only when is_enabled()? In the factory state the modem is in hardware reset, so the feature is announced but ev/state can never deliver data - evcc would show a permanently unavailable SoC. Gating on is_enabled() (not on read_soc alone, so autocharge-only setups keep MAC identification) would let evcc self-configure correctly, similar to how phase_switch or rgb_led are announced conditionally. A live config enable could add the feature at runtime; features going stale on live disable until reboot seems acceptable given features are add-only anyway.

Independent of that, I will extend the template documentation: vehicle identification requires ISO 15118 to be enabled, reading the SoC additionally requires "Read state of charge".

andig · 2026-07-09T09:54:51Z

evcc would show a permanently unavailable SoC.

It wouldn't if you return 0 or api.ErrNotAvailable- we'll just fallback to vehicle then.

poohnet · 2026-07-09T10:05:55Z

Ok, soc() already returns api.ErrNotAvailable when ev/state carries no data, so a stock WARP4 will fall back to the vehicle and a conditional feature announcement is cosmetic only.

rtrbt · 2026-07-09T11:51:21Z

One suggestion though: could the firmware announce iso15118 only when is_enabled()? In the factory state the modem is in hardware reset, so the feature is announced but ev/state can never deliver data - evcc would show a permanently unavailable SoC. Gating on is_enabled() (not on read_soc alone, so autocharge-only setups keep MAC identification) would let evcc self-configure correctly, similar to how phase_switch or rgb_led are announced conditionally. A live config enable could add the feature at runtime; features going stale on live disable until reboot seems acceptable given features are add-only anyway.

Nope that's not what features are for. A feature (almost) always indicates that a piece of hardware is available. For example the ethernet feature indicates an ethernet PHY is available, but you can still unplug the cable or deactivate ethernet via the API.

Ok, soc() already returns api.ErrNotAvailable when ev/state carries no data, so a stock WARP4 will fall back to the vehicle and a conditional feature announcement is cosmetic only.

This will then also fall back to the vehicle's data if reading the SoC via iso 15118 fails? Seems to be a good idea.

- new template tinkerforge-warp4-ws (WARP4 Smart/Pro) with iso151182 capability - warp-ws: probe ev/state endpoint and register api.Battery when available - warp-ws: subscribe to ev/state websocket events for live SoC updates - warp-ws: disable WARP phase auto switching also for warp4 devices Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The mac address read via ISO 15118 is exposed in ev/state. Prefer it over the RFID tag so vehicles can be matched by their identifiers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- detect WARP4 via already fetched device type instead of probing ev/state - align soc with identify: return result first Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Probe the endpoint in NewWarpWS before the websocket goroutines start, avoiding both device name matching and init-time locking. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The ev module is not announced in info/features, so hasFeature cannot detect it. Probe the api statelessly in NewWarpWSFromConfig instead; evState is populated by the initial websocket push. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Requires WARP4 firmware announcing the ev feature, see Tinkerforge/esp32-firmware#503. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tinkerforge announces the feature from the iso15118 module instead of the ev module, since the ev module will also be ported to devices without a PLC modem. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Replaces the separate WARP4 template with per-product entries in the combined template. SoC reading requires the built-in meter and is documented as Pro-only; vehicle identification works on both variants. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

andig · 2026-07-09T14:13:26Z

Rein damit?

poohnet · 2026-07-09T14:22:10Z

Rein damit?

Vielleicht mache ich heute Abend sicherheitshalber noch einen letzten Test mit der gerade veröffentlichten Firmware?! :-D

poohnet · 2026-07-09T16:53:31Z

Just re-tested with firmware 2.12.2 and a fresh evcc database: Still looking good :-)

poohnet marked this pull request as ready for review July 3, 2026 17:51

sourcery-ai Bot reviewed Jul 3, 2026

View reviewed changes

Comment thread templates/definition/charger/tinkerforge-warp4-ws.yaml Outdated

andig reviewed Jul 4, 2026

View reviewed changes

Comment thread charger/warp-ws.go Outdated

andig reviewed Jul 4, 2026

View reviewed changes

Comment thread charger/warp-ws.go Outdated

andig reviewed Jul 4, 2026

View reviewed changes

Comment thread charger/warp-ws.go Outdated

andig added the devices Specific device support label Jul 4, 2026

poohnet force-pushed the warp4 branch from 4757646 to 19e18b4 Compare July 4, 2026 07:17

andig reviewed Jul 4, 2026

View reviewed changes

poohnet mentioned this pull request Jul 4, 2026

ev: Announce ev feature Tinkerforge/esp32-firmware#503

Closed

poohnet marked this pull request as draft July 4, 2026 10:57

poohnet force-pushed the warp4 branch 2 times, most recently from 3edce63 to d6478c1 Compare July 8, 2026 15:56

poohnet marked this pull request as ready for review July 8, 2026 16:00

sourcery-ai Bot reviewed Jul 8, 2026

View reviewed changes

poohnet mentioned this pull request Jul 8, 2026

Tinkerforge WARP: correct capabilities per generation and variant #31590

Merged

poohnet and others added 3 commits July 9, 2026 15:51

Tinkerforge WARP: identify vehicle by mac address on WARP4

dd7b67b

The mac address read via ISO 15118 is exposed in ev/state. Prefer it over the RFID tag so vehicles can be matched by their identifiers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tinkerforge WARP: address review feedback

bde4597

- detect WARP4 via already fetched device type instead of probing ev/state - align soc with identify: return result first Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

poohnet and others added 5 commits July 9, 2026 15:51

Tinkerforge WARP: gate EV features on ev/state availability

755c9f6

Probe the endpoint in NewWarpWS before the websocket goroutines start, avoiding both device name matching and init-time locking. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tinkerforge WARP: detect EV features via info/features

faf22cb

Requires WARP4 firmware announcing the ev feature, see Tinkerforge/esp32-firmware#503. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tinkerforge WARP: rename detected feature to iso15118

23453f4

Tinkerforge announces the feature from the iso15118 module instead of the ev module, since the ev module will also be ported to devices without a PLC modem. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

poohnet force-pushed the warp4 branch from d6478c1 to 8742c0f Compare July 9, 2026 14:00

Tinkerforge WARP: document WARP4 firmware requirement

3f04890

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

andig merged commit d495d3e into evcc-io:master Jul 9, 2026
9 checks passed

poohnet deleted the warp4 branch July 9, 2026 17:06

poohnet mentioned this pull request Jul 9, 2026

Split ISO/DIN capabilities #31468

Closed

Uh oh!

Uh oh!

Conversation

poohnet commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

poohnet commented Jul 3, 2026

Uh oh!

sourcery-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

andig Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

poohnet Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

poohnet Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

poohnet Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

andig Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

poohnet Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

poohnet Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rtrbt Jul 8, 2026

Choose a reason for hiding this comment

Uh oh!

andig commented Jul 4, 2026

Uh oh!

poohnet commented Jul 4, 2026

Uh oh!

andig commented Jul 5, 2026

Uh oh!

rtrbt commented Jul 8, 2026

Uh oh!

poohnet commented Jul 8, 2026

Uh oh!

sourcery-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

poohnet commented Jul 8, 2026

Uh oh!

rtrbt commented Jul 9, 2026

Uh oh!

poohnet commented Jul 9, 2026

Uh oh!

andig commented Jul 9, 2026

Uh oh!

poohnet commented Jul 9, 2026

Uh oh!

rtrbt commented Jul 9, 2026

Uh oh!

andig commented Jul 9, 2026

Uh oh!

poohnet commented Jul 9, 2026

Uh oh!

poohnet commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

poohnet commented Jul 3, 2026 •

edited

Loading

poohnet Jul 4, 2026 •

edited

Loading

poohnet commented Jul 9, 2026 •

edited

Loading