Batteriehistorie: stehende Werte gelten nicht mehr als frische Messungen

Der Vorschlag aus Abschnitt CB (CAN-Wert innerhalb 300 s verlangen) wurde
gemessen und trifft nicht: er haette zwei eindeutige Werkbank-Tage
durchgelassen (CAN 5 Minuten neben dem Minimum) und echte Fahrzeugtage
verworfen - am stehenden Fahrzeug schweigt CAN, eine CAN-Frist verwirft also
ausgerechnet die Ruhespannung.

Der wirkliche Mechanismus: zustand_oder_none() liefert den zuletzt bekannten
Zustand unabhaengig vom Alter, und pruefen() stempelte ihn mit "jetzt". Ein
schweigender Dongle "misst" damit alle fuenf Minuten weiter seinen letzten
Wert. Am Bestand belegt: der 16.08.2026 trug einen Tageseintrag, obwohl der
Sensor an dem Tag kein einziges Mal gemeldet hatte (naechste echte Meldung 885
Minuten entfernt); sieben von 19 Eintraegen standen mehr als fuenf Minuten von
jeder echten Meldung entfernt.

messzeitpunkt() beantwortet jetzt beide Fragen an einer Stelle: ist das eine
neue Messung, und wann wurde sie gemacht. Gestempelt wird mit der Geraetezeit,
wenn zuordenbar - so wie der Rueckblick es laengst tut, der damit die richtige
Umsetzung war und keine Aenderung brauchte. Der Tag kommt aus der Messung, nicht
aus date.today(). Die Frischepruefung steht vor der Plausibilitaetsgrenze, sonst
warnt ein offline gegangener Dongle alle fuenf Minuten ueber denselben Wert (77
identische Zeilen in 3000 Protokollzeilen gezaehlt).

Die erste Fassung mass das Alter an last_updated und hatte damit ein Loch, das
erst die Live-Pruefung zeigte: Home Assistant setzt beim Hochfahren jede
Entitaet neu, last_updated steht danach auf der Neustartzeit. Gemessen: nach dem
Neustart um 21:12:54 trug der Spannungssensor last_updated 21:12:54, waehrend
die Meldezeit desselben Datensatzes 14:46:47 sagte. Das Alter wird deshalb an
der Messzeit gemessen.

Geprueft: 18 Tests in tests/batterie/, davon fallen 16 gegen HEAD; alle 116
Backend-Tests gruen; live im Testcontainer belegt - der erste Takt nach dem
Neustart meldet "keine neue Messung" statt der bisherigen Warnung.

Offen: Werkbank und Fahrzeug lassen sich aus diesen Daten nicht sicher trennen.
Abgestellt sind die erfundenen Eintraege, nicht die Frage, wo der Dongle steckt.

AGENTS.md

@@ -1,6 +1,6 @@
 # AGENTS.md — Project state, review findings, open items, and working rules
 
-**Last updated: 2026-09-05** (Audit-Durchgang, Abschnitt DC) (Tankstelle zweizeilig und antippbar, die Belegkarte sagt bei
+**Last updated: 2026-09-06** (Die Batteriehistorie zeichnete stehende Werte als frische Messungen auf - der Vorschlag aus CB war messbar falsch, Abschnitt DI; davor: die ausgelieferte .ipa registriert zwei eigene Plugins nicht, Abschnitt DH). Davor: 2026-09-05, Audit-Durchgang, Abschnitt DC. (Tankstelle zweizeilig und antippbar, die Belegkarte sagt bei
 fehlender Position die Wahrheit statt einen toten Knopf zu zeigen, der Regler bekommt einen
 Speichern-Knopf, und die Share-Erweiterung trug eine andere Versionsnummer als die App;
 dazu die Kopfmarke statt der Firmierung des Betreibers und ein
@@ -9802,10 +9802,16 @@ minimum against whether the vehicle was reporting over CAN within plus/minus 5 m
 days pass, 13 do not** — including 2026-09-03 (12,149 V at 23:56, the desk). These values feed the
 resting voltage, the SOC, the SOH trend and the fallback shown in "Mein Audi / Zustand".
 
-**Not built, proposed:** require a fresh CAN value near the voltage reading before recording it —
-the same mechanism as `wert_in_naehe()` with its 300 s window for the outside temperature. Without a
-vehicle, nothing gets recorded. The 13 existing entries are the owner's data; removal is via the
-swipe gesture in the measurement list.
+**Not built, proposed — ÜBERHOLT am 2026-09-06, siehe Abschnitt DI:** require a fresh CAN value
+near the voltage reading before recording it — the same mechanism as `wert_in_naehe()` with its
+300 s window for the outside temperature. Without a vehicle, nothing gets recorded. The 13 existing
+entries are the owner's data; removal is via the swipe gesture in the measurement list.
+
+> **Diese Regel wurde gemessen und trifft nicht.** Sie hätte zwei eindeutige Werkbank-Tage
+> durchgelassen (CAN 5 Minuten neben dem Minimum) und echte Fahrzeugtage verworfen — am stehenden
+> Fahrzeug schweigt CAN, eine CAN-Frist verwirft also ausgerechnet die Ruhespannung. Der wirkliche
+> Mechanismus war ein anderer: `pruefen()` zeichnete den zuletzt bekannten Wert alle fünf Minuten
+> erneut auf und stempelte ihn mit `jetzt`. Abschnitt DI hat die Rechnung und die Korrektur.
 
 ## CC. Tankstelle zweizeilig und antippbar, die Belegkarte sagt die Wahrheit, der Regler bekommt einen Knopf (2026.9.4.5)
 
@@ -12553,3 +12559,131 @@ Am **fertigen Buendel** zu pruefen, nicht am Projekt:
 Die ersten vier prueft das Skript selbst und bricht sonst ab. Der fuenfte Punkt
 bleibt Handarbeit: dass eine Klasse in der Liste steht, heisst noch nicht, dass
 die Bruecke sie zur Laufzeit findet.
+
+## DI. Die Batteriehistorie zeichnete stehende Werte als frische Messungen auf (2026-09-06)
+
+Auftrag des Eigentümers: die in Abschnitt CB gemeldete Verunreinigung der
+Batteriehistorie durch Werkbank-Messungen abstellen. **Der dort vorgeschlagene
+Weg war falsch, und das Messen hat es gezeigt, bevor Code entstanden ist.**
+
+### Warum der Vorschlag aus CB nicht trägt
+
+CB schlug vor, eine Messung nur aufzuzeichnen, wenn ein CAN-Wert innerhalb von
+300 s vorliegt („ohne Fahrzeug wird nichts erfasst"). Gegen die 19 gespeicherten
+Tage und den recorder gerechnet, trifft diese Regel in **beide** Richtungen
+daneben:
+
+* Sie hätte zwei eindeutige Werkbank-Tage **durchgelassen** - am 15.08. und
+  23.08. lag eine CAN-Meldung 5 Minuten neben dem Tagesminimum.
+* Sie hätte echte Fahrzeugtage **verworfen** - der 30.08. (95 min) und der
+  04.09. (8 min) tragen Tagesmaxima von 14,7 bzw. 14,4 V, also Generatorspannung.
+  Insgesamt hätte sie 12 von 19 Tagen abgelehnt.
+
+Der Grund ist grundsätzlich: am stehenden Fahrzeug schweigt CAN. Eine
+CAN-Frist verwirft damit ausgerechnet die Ruhespannung - die Größe, für die
+diese Aufzeichnung überhaupt existiert (siehe den Moduldocstring von
+`batterie.py`).
+
+### Der wirkliche Mechanismus, am Bestand nachgewiesen
+
+`zustand_oder_none()` liefert den zuletzt bekannten Zustand **unabhängig von
+seinem Alter**, und `pruefen()` stempelte ihn mit `jetzt`. Ein schweigender
+Dongle „misst" damit alle fünf Minuten weiter seinen letzten Wert.
+
+Der Beleg steht in den Daten selbst:
+
+| | |
+|---|---|
+| **2026-08-16** | Tageseintrag vorhanden (13,024 V @ 08:37:43) |
+| | Spannungsmeldungen an diesem Tag: **0** |
+| | Abstand zur nächsten echten Meldung: **885 Minuten** |
+
+Sieben von 19 Einträgen stehen mehr als fünf Minuten von jeder echten Meldung
+entfernt; die unstrittigen Fahrzeugtage dagegen exakt bei 0 s.
+
+Dasselbe zeigt der Sensor selbst, nach Epochen getrennt: bis zum 25.08. meldete
+er 2 bis 26 Mal am Tag mit **genau einem einzigen Wert** (13,024 bzw. 13,988 -
+eine Spannung, die sich nicht rührt), ab dem 27.08. 35 bis 871 Mal mit 28 bis
+487 verschiedenen Werten zwischen 0 und 15,4 V. Die Lücken der ersten Epoche
+hat der Livepfad mit Wiederholungen des letzten Werts gefüllt.
+
+### Was gebaut wurde
+
+`messzeitpunkt()` in `batterie.py` beantwortet beide Fragen an einer Stelle:
+ist das eine neue Messung, und wann wurde sie gemacht. `None` heißt „seit
+`MESSUNG_MAX_ALTER_S` nichts Neues - es gibt nichts aufzuzeichnen".
+
+* **`MESSUNG_MAX_ALTER_S = 600`.** Der Takt liegt bei 5 Minuten
+  (`TAKT_BATTERIE`); das Fenster muss mindestens eine Taktlänge betragen, sonst
+  ginge eine Messung verloren, die kurz nach einem Takt eintrifft. Verdoppelt
+  für einen verspäteten Takt - dieselbe Messung zweimal einzutragen ist
+  folgenlos, weil sie ihren eigenen Zeitstempel trägt und die Ablage min/max nur
+  erweitert.
+* **Gestempelt wird mit der Gerätezeit**, wenn sie sich über `ZUORDNUNG_MAX_S`
+  zuordnen lässt, sonst mit der Ankunftszeit. Das ist keine Stilfrage: der
+  Rückblick stempelt Batteriewerte längst mit Gerätezeit (`verlauf_lesen()`
+  bekommt in `historienimport.py` die Meldezeit-Entität mit). Ohne dieselbe Wahl
+  im Livepfad ergäben beide Wege für dieselbe Messung verschiedene Einträge -
+  genau die Divergenz, die dieses Projekt bei `UNPLAUSIBLE_KMH`,
+  `MINDESTDAUER_S` und `zaehlerstrecke()` schon dreimal bezahlt hat.
+* **Der Tag kommt aus der Messung**, nicht aus `date.today()` - sonst landete
+  eine Messung von 23:58 im Folgetag.
+* **Die Frischeprüfung steht VOR der Plausibilitätsgrenze.** Sonst warnt ein
+  offline gegangener Dongle alle fünf Minuten über denselben Wert: im laufenden
+  Testcontainer **77 identische Zeilen** „Batteriespannung 0.0 V unter der
+  Plausibilitätsgrenze" in 3000 Protokollzeilen, über einen Wert, der sich seit
+  5,5 Stunden nicht gerührt hatte. Jetzt warnt jede echte Messung genau einmal.
+
+**Der Rückblick brauchte keine Änderung** - er iteriert über echte
+recorder-Zeilen, von denen jede eine tatsächliche Messung ist, und stempelt sie
+mit ihrem eigenen Zeitstempel. Er war die ganze Zeit die richtige Umsetzung; der
+Livepfad war der abweichende.
+
+### Die erste Fassung hatte ein Loch, und nur die Live-Prüfung hat es gezeigt
+
+Gemessen wurde das Alter zunächst an `last_updated` des Spannungssensors. Nach
+dem Ausliefern in den Testcontainer warnte der erste Takt trotzdem - über
+denselben seit 15:30 stehenden 0-V-Wert. **Home Assistant setzt beim Hochfahren
+jede Entität neu; ihr `last_updated` steht danach auf der Neustartzeit**, auch
+wenn der Wert Stunden alt ist. Am 06.09.2026 im laufenden Container abgelesen:
+
+| Entität | `last_updated` | Wert |
+|---|---|---|
+| Spannung | 21:12:54 (= Neustart) | 0 |
+| Meldezeit | 21:12:54 (= Neustart) | 1788706007 -> **14:46:47** |
+
+Die Ankunftszeit log also, die **Gerätezeit übersteht den Neustart**: 395
+Minuten. Das Alter wird deshalb an der Messzeit gemessen, nicht an der Ankunft -
+`messzeitpunkt()` bestimmt erst die Messzeit und prüft danach das Alter.
+
+Ohne zugeordnete Meldezeit bleibt nur die Ankunftszeit; dann geht nach einem
+Neustart einmalig ein veralteter Wert durch. Das ist bekannt, im Docstring
+vermerkt und durch einen eigenen Test festgehalten, statt unbemerkt zu bleiben.
+
+**Die Lehre ist die alte:** kompiliert und getestet ist nicht verifiziert. Die
+16 Tests der ersten Fassung waren grün, 14 davon fielen gegen HEAD - und das
+Loch lag trotzdem darin, weil kein Test einen HA-Neustart nachstellte.
+
+### Geprüft
+
+18 Tests in `tests/batterie/` (`test_messzeitpunkt.py`, `test_pruefen.py`),
+darunter der 16.08.-Fall und der Neustart-Fall mit ihren echten Zahlen. **Gegen
+den Stand aus HEAD fallen 16 davon** - die zwei, die in beiden Ständen grün bleiben, sind die
+Wächter dafür, dass bestehendes Verhalten unangetastet ist (eine frische
+unplausible Messung warnt weiterhin und wird weiterhin nicht erfasst). Alle
+109 Backend-Tests grün.
+
+### Was offen bleibt
+
+**Werkbank und Fahrzeug lassen sich aus diesen Daten nicht sicher trennen.** Ein
+Netzteil bei 12,2 V sieht aus wie ein stehendes Fahrzeug, und die
+August-Verunreinigung stammt aus der Testphase, in der der Dongle zwischen
+Schreibtisch und Fahrzeugen wanderte. Was jetzt zuverlässig abgestellt ist, sind
+die **erfundenen** Einträge - Tage ohne Messung und Zeitstempel, die nicht zur
+Messung gehören. Wer die Werkbank wirklich ausschließen will, braucht einen
+Schalter, den der Eigentümer beim Abstöpseln umlegt; aus den Sensordaten allein
+ist die Frage nicht zu beantworten.
+
+**Die vorhandenen Einträge bleiben stehen** - das sind die Daten des
+Eigentümers. Zu entfernen sind sie über das Wischen in der Messwertliste, so wie
+schon in Abschnitt U/CB beschrieben.