Charger: tag templates with meter capability

[andig]

Summary

• Introduces a new meter template capability (util/templates/types.go)
• Tags 99 charger templates whose Go implementation unconditionally exposes CurrentPower() — either via a direct struct method or a decorator that is always wired with a non-nil currentPower argument
• Chargers that only conditionally provide CurrentPower (e.g., feature/register-detection, optional power: block, sponsor-gated, optional URL) are intentionally not tagged

Closes #11692

Categories of touched templates

• Direct struct method: abb, abl-em4, alfen, alpitronic, amperfied, chargex, compleo (+ senec/neoom variants), dadapower, daheimladen (+ pro), delta, e3dc-rscp, easee, em2go (+ home/duo), eprowallbox, etrel (+ duo), evecube, evsemaster-udp, fronius-wattpilot, hardybarth-ecb1, heidelberg, hesotec, innogy-ebox, kathrein, kse, lektrico, mennekes-compact, mennekes-hcc3, mypv (ac-elwa-2/ac-thor/ac-elwa-e), nexblue, nrggen2, nrgkick (bluetooth/connect), openevse, openwb (+ 2.0/pro), pantabox, peblar, plugchoice, pulsatrix, raedian, schneider-evlink-v3, semp (+ semp-sma), shelly-topac, sigenergy, smaevcharger, smartevse, solax (+ g2), sungrow, tessie, twc3, v2c, versicharge, vestel, victron (+ evcs), voltie, volttime, webasto-next, weidmüller, zaptec
• Switchsocket pattern with always-bound CurrentPower: fritzdect, homematic, homewizard, mystrom, shelly, tasmota, tapo, tplink, shelly-topac
• EEBus chargers that always render meter: true: eebus, elli-2, elli-charger-pro, ghost, porsche-pmcc/pmcp/wallbox
• Heatpump templates with always-rendered power: block: askoheat, idm, kermi, lambda-zewotherm, mtec
• sgready: emsesp
• Wallbe variants with meter.power: true always set: wallbe-meter, wallbe-pre2019-meter
• smartwb (renders evsewifi with meter.power: true)

Skipped (conditional CurrentPower)

• All OCPP variants (powerG only set on HasMeasurement(PowerActiveImport))
• abl, bender (cc/icc), cfos, etek, hardybarth-salia, keba-modbus (+p40), keba-udp, pcelectric (+ garo), phoenix-charx/em-eth/ev-eth, smart-evse, vanilla wallbe.yaml/wallbe-pre2019, warp-* (tinkerforge/warp-ws/warp2/warp3), evsewifi
• vaillant (depends on remote API response)
• sgready templates without power: (daikin-homehub-air2air, daikin-homehub, glen-dimplex, lg-therma, luxtronik, nibe-s-series, stiebel-lwa, stiebel-wpm, viessmann, weishaupt-wpm), heatpump templates without power: (ochsner-bwwp, xtherma)
• homeassistant.yaml (power is optional/advanced), homeassistant-switch (standbypower<0 disables it)

Skipped (no CurrentPower at all)

• alphatec, evsedin, obo, openwb-native, phoenix-ev-ser, pracht-alpha, pulsares, sgready-relay, vehicle-api, switchsocket (generic), demo-charger, demo-heatpump, icharge-cion

Test plan

• go build ./... clean
• go test ./util/templates/... passes (capability validation lints all entries)
• Verify the docs site picks up the new meter capability tag for filtering once make docs regenerates

[sourcery-ai]

Hey - I've left some high level feedback:

• The PR description says Smart EVSE variants were intentionally skipped due to conditional CurrentPower, but smartevse.yaml is tagged with meter; please double‑check whether this template should really advertise an unconditional meter capability or adjust the description.
• For many of the updated YAML templates the capabilities arrays now have a mixed order (e.g., `['mA', 'rfid', '1p3p', 'meter'] vs earlier patterns); consider standardizing the ordering (alphabetical or by importance) to keep future diffs smaller and the templates easier to scan.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The PR description says Smart EVSE variants were intentionally skipped due to conditional `CurrentPower`, but `smartevse.yaml` is tagged with `meter`; please double‑check whether this template should really advertise an unconditional meter capability or adjust the description.
- For many of the updated YAML templates the `capabilities` arrays now have a mixed order (e.g., `['mA', 'rfid', '1p3p', 'meter'] vs earlier patterns); consider standardizing the ordering (alphabetical or by importance) to keep future diffs smaller and the templates easier to scan.

---

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

• X
• Mastodon
• LinkedIn
• Facebook

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

[andig]

Addressing the review feedback:

• smartevse vs smart-evse: those are two separate chargers. smartevse.yaml renders type: smartevse (the modbus-based smartEVSE charger in charger/smartevse.go, which has CurrentPower as a direct struct method — unconditional). The skipped one is smart-evse.yaml rendering type: smart-evse (HTTP-based, conditional). The PR description's "smart-evse" entry was the one intended in the skip list.
• Capability ordering: pushed a follow-up commit that sorts capabilities consistently as iso151182, mA, rfid, 1p3p, meter (matching the order in ValidCapabilities) across all 30 affected templates. New diffs in this area will stay stable from now on.

[andig]

@premultiply hier passt was nicht?

[premultiply]

Die wallbe*-Implementierungen/Templates sind völlig veraltet und können ganz raus. Das läuft alles einheitlich über phoenix-ev-eth.

[andig]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in 9f998f0. The conflicts were in eebus.yaml, porsche-pmcc.yaml, and porsche-pmcp.yaml — all from the same master commit that dropped the unused evcc: ["eebus"] requirement entries. The resolution keeps our meter capability additions while incorporating master's requirement cleanup.

[tolot27]

Would it be useful to implement a meter type attribute for standard, MID, Eichrecht? The later two could be suffixed with "-conform".

[andig]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in cf7c6cb. One real conflict in openwb-2.0.yaml (master intentionally removed rfid, we had added meter; kept meter, dropped rfid). Also added capabilities: ["meter"] to stiebel-wpm.yaml now that master's "Stiebel WPM: re-add power" commit restored its unconditional power: block.

[naltatis]

LGTM