EV status says 'Charging' at 140 W standby with the charger disabled — the >100 W physics-inference threshold is below any real charge

[traktore-org]

Live evidence (PROD, 2026-08-08 ~15:45)

Charge mode Off, SEM enforcing it correctly (commanded_current: 0.0 A), observer mode off, car at ~100 % — and the EV card shows Status: Charging · 140 W, binary_sensor.sem_ev_charging: on.

Root cause

coordinator/sensor_reader.py (three sites): the physics inference ev_charging or ev_power > 100 marks charging whenever the meter reads over 100 W, even when the plug/charging sensors say off. That inference exists for the right reason — a lying plug sensor during a REAL charge (#616 class) — but a real charge cannot be below the 6 A minimum (~1.4 kW single-phase, ~4.1 kW three-phase). 140 W is charger/vehicle standby draw, common on a KEBA with a full car, and 100 W is far below the line that separates the two.

Fix direction

Raise the inference threshold to something no real charge can be under (e.g. 500 W — still catches every genuine charge, never a standby trickle), or additionally require that SEM has not itself commanded 0 A/disabled. All three sites (2078, 2968, 3353) plus a check for downstream consumers (session tracking, notifications, flow attribution) — the threshold feeds more than the badge.

Scope

1.7 lane — shipped behavior, unrelated to the 1.8 planner branch (reproduced on it, but the sites predate it).

[traktore-org]

Thanks Guido — ran a verify-first pass + a reproduction on this. The physics-inference part of your diagnosis holds, but there's a wrinkle worth flagging before anyone implements it: raising the >100 W threshold does not touch the reported binary_sensor.sem_ev_charging: on badge. Two independent mechanisms are in play; only one is the physics inference.

1. The physics inference (sensor_reader.py, 3 sites ≈ 2041 / 2867 / 3252) writes ev_connected only — never ev_charging

• binary_sensor.sem_ev_charging.is_on → data["ev_charging"] (binary_sensor.py:172) → SEMData.power.ev_charging (types.py:938). Every assignment to power.ev_charging comes from reading the configured charging sensor; none derive it from watts or from ev_connected. The three physics blocks assign ev_connected / ev_connected_per_charger exclusively.
• Repro (legacy config: plug off / charging-binary off / 140 W): ev_connected=True (physics fires, 140 > 100) but ev_charging=False → sem_ev_charging would be off.
• So the >100 W threshold is genuinely too low, but it only produces the false CONNECTED state — which is what feeds the downstream consumers you listed (session tracking, notifications, flow attribution). And 500 W is exactly right for it: it matches SEM's own idle/handshake floor (keba.py: handshake_power_w = 500, KEBA idle ~110 W). A real ≥6 A charge is ≥1.38 kW single-phase, so 500 W never suppresses a genuine charge.

2. The reported sem_ev_charging: on badge comes from power.ev_charging = the raw brand charging boolean — the signal the codebase itself says to distrust

• keba.py::actual_charging "deliberately ignores power.charging — it lags 5+ s on KEBA (sensor.sem_ev_power lags KEBA's charging_power by 5+ kW for several seconds #289)" and uses power_w > handshake_power_w (500 W). charger_types.py documents the same: "prefer power_w > 500 … treat charging as informational."
• But the published binary_sensor.sem_ev_charging publishes that raw boolean directly, with no power gate. At 140 W idle it reads truthy — either a lagging KEBA charging_state, or a numeric sensor.keba_*_state code caught by the float(s) > 0 fallback in _read_binary_sensor — so the badge is on. Repro (charging sensor reads a nonzero idle state, 140 W): ev_charging=True → sem_ev_charging: on. And because ev_charging short-circuits the or, the physics threshold is a no-op in exactly this case.

Recommended fix (your call — it changes a user-facing entity's semantics + the consumers you flagged)

• Make the published charging surface honor the 500 W actual_charging floor the adapters already use (i.e. stop publishing ev_charging from the raw boolean alone), or your second option — gate it on "SEM commanded 0 A/idle and power < 500 W" (narrower; leaves normal charges and observer-mode external charges >500 W untouched). Either one fixes both the badge and the false-connected.
• Raise the >100 W physics threshold to 500 W at the 3 sites regardless — that's the correct, safe fix for the CONNECTED inference and matches the adapter convention.

Not auto-shipping this: redefining binary_sensor.sem_ev_charging (users build automations on it) plus the downstream-consumer sweep you called out is a design decision I'd rather leave to you. Worth a docs/BUG_CLASSES.md row too — "idle / lagging EV signal read as an active charge; the canonical 500 W actual_charging floor bypassed at surface X" — the physics inference and the published badge are two instances of the same shape. Queued for you.

[traktore-org]

Decision taken and built — on develop, lands in v1.7.6-beta.9. Went with the first option, which is really just enforcing the convention the codebase already documents:

• The published badge honors the 500 W actual-charging floor. readings.ev_charging (and each per-charger entry) now requires real draw above EV_ACTIVE_CHARGE_FLOOR_W = 500 whenever a power source is configured — the same rule every adapter's actual_charging applies. The raw brand boolean survives only on installs with nothing but a charging boolean (nothing better exists there). Per-charger entries are judged on their own reading; the fleet flag follows the gated map, so the two can't disagree.
• The physics inference uses the same floor at all 3 sites (was 100 W — below the box's own standby draw), and its charging-boolean leg now sees the gated badge, so a numeric idle state code can't invent a phantom connection either. The duplicated inline fleet inference collapsed into one shared helper while I was in there.
• Re the automations concern: a real ≥6 A charge is ≥1.38 kW single-phase, so no genuine charge can be suppressed — the only behavior change users see is the badge no longer lying at standby.

Pins: tests/test_739_charging_badge_floor.py (badge floor fleet + per-charger, boolean-only pass-through, both physics floors) plus a new phantom-standby corner in test_ev_connected_physics_defence.py. The 2026-05-29 #285+1 repro (8 kW against a lying plug sensor) still overrides, now for the honest reason — the draw, not the boolean. docs/BUG_CLASSES.md row for the "idle/lagging EV signal read as an active charge" shape follows with the beta.