Fahrtende ohne den Nachlauf des Geraets (2026.9.1.4)

Das Trip-Signal endet nicht mit der Zuendung, sondern "Ignition OFF Timeout"
spaeter - beim FMM003 900 s. Das Fahrtende lag damit systematisch 15 Minuten
zu spaet. _echtes_ende() zieht NACHLAUF_S = 900 ab.

Die Rechnung stammt vollstaendig aus der Logik des Geraets und ueberlebt
deshalb ein Funkloch: der Datensatz kommt spaeter, traegt aber seine eigene
Zeit (2026.9.1.2/.3).

Die Klemme ist der wichtigere Teil: war das Signal nicht laenger als der
Nachlauf, wurde nicht gefahren - Ende auf den Beginn geklemmt, MINDESTDAUER_S
verwirft den Vorgang. Ohne sie entstuende aus dreissig Sekunden Zuendung eine
Viertelstunde Fahrt.

_nachlauf_gegenpruefen() vergleicht das gerechnete Ende mit dem beobachteten
Zuendungswechsel und warnt ab 120 s Abweichung, ohne zu korrigieren. Wie genau
"Zuendung aus" bekannt ist, haengt am Operanden des Zuendungs-I/O-Elements; er
steht auf 3 (nach der Reihenfolge in der Teltonika-Doku "Monitoring", also
kein eigener Datensatz je Wechsel). Solange das nicht feststeht, waere ein
Umschalten auf den beobachteten Wert eine Verschlechterung.

Keine Einstellung in der Oberflaeche: die Zahl gehoert zum Geraet, nicht zum
Nutzer - dieselbe Linie wie UNPLAUSIBLE_KMH. flespi koennte sie liefern
(GET /gw/devices/{id}/settings/all), aber die Integration liest heute nur
Telemetrie; ein zweiter Zugang samt Token waere unverhaeltnismaessig.

Verifiziert in audi_ha_test: Signal 1200 s -> Fahrt 300 s; Signal 930 s ->
keine Fahrt (Bestand 12 -> 12); Gegenprobe mit 887 s Abweichung ausgeloest.
Testfahrt ueber fahrt_loeschen entfernt, Bestand unveraendert 11 Fahrten.

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

AGENTS.md

@@ -1,6 +1,7 @@
 # AGENTS.md — Project state, review findings, open items, and working rules
 
-**Last updated: 2026-09-01** (Fahrtbeginn und -ende kommen jetzt vom Gerät (`MELDEZEIT_SENSOR`),
+**Last updated: 2026-09-01** (Fahrtende ohne den 900-s-Nachlauf des Geräts, Manifest `2026.9.1.4`,
+siehe Abschnitt AZ. Davor am selben Tag: Fahrtbeginn und -ende kommen vom Gerät (`MELDEZEIT_SENSOR`),
 Manifest `2026.9.1.3`, siehe Abschnitt AY: dazu die Trennung von
 Trip- und Zündungsrolle und die Gerätezeit für Tankvorgänge. Davor am selben Tag: Phantomfahrten beim Neustart abgestellt, Tankstand auf `wert_bei()`
 nachgezogen, zwölf Nullfahrten gelöscht, „Open items" von vier MQTT-Karteileichen befreit;
@@ -6518,6 +6519,54 @@ sonst testet man gegen ganze Kilometer.
 `11807` (Odometer Value) steht auf 0. Für die geplante Rechnung ist das gleichgültig, weil sie mit
 Zuwächsen arbeitet; wer den absoluten Wert lesbar haben will, trägt dort den echten Kilometerstand ein.
 
+## AZ. Das Fahrtende ohne den Nachlauf des Geräts (2026.9.1.4)
+
+Das Trip-Signal endet nicht mit der Zündung, sondern `Ignition OFF Timeout` später — beim
+FMM003 900 s. Als Auslöser ist es deshalb ideal (es prellt nicht, es bringt die Pausentoleranz
+mit), aber das Fahrtende lag systematisch **15 Minuten zu spät**.
+
+`_echtes_ende()` zieht `NACHLAUF_S = 900` ab. Die Rechnung stammt vollständig aus der Logik des
+Geräts und überlebt deshalb ein Funkloch: der Datensatz kommt später, trägt aber seine eigene
+Zeit (Abschnitt AY).
+
+**Die Klemme ist der wichtigere Teil.** War das Signal nicht länger als der Nachlauf, wurde nicht
+gefahren — dann wird das Ende auf den Beginn geklemmt und `MINDESTDAUER_S` verwirft den Vorgang.
+Ohne sie entstünde aus dreißig Sekunden Zündung eine Viertelstunde Fahrt, also genau die Sorte
+Nulleintrag, die Abschnitt AW ausgeräumt hat.
+
+**Warum keine Einstellung in der Oberfläche.** Die Zahl gehört zum Gerät, nicht zum Fahrzeug und
+nicht zum Nutzer — dieselbe Linie wie `UNPLAUSIBLE_KMH` und `MIN_STRECKE_VERBRAUCH_KM`. flespi
+kann die Gerätekonfiguration zwar liefern (`GET /gw/devices/{id}/settings/all`, 127 benannte
+Einstellungen, darunter `trip_scenario.ign_off_timeout`), aber dafür bräuchte die Integration
+einen zweiten Zugang samt Token; sie liest heute ausschließlich Telemetrie. Verworfen als
+unverhältnismäßig.
+
+### Die Gegenprobe meldet, statt zu korrigieren
+
+`_nachlauf_gegenpruefen()` vergleicht das gerechnete Ende mit dem letzten beobachteten
+Zündungswechsel auf „aus" und **warnt ab 120 s Abweichung, ohne etwas zu ändern**.
+
+Der Grund für „nur warnen": wie genau „Zündung aus" bekannt ist, hängt am Operanden des
+Zündungs-I/O-Elements. Er steht in der `.cfg` auf **3**; nach der Reihenfolge in der
+Teltonika-Dokumentation (On Exit, On Entrance, On Both, Monitoring, On Hysteresis, On Change, On
+Delta Change) ist das **Monitoring** — laut Wiki „No event at all. Values are recorded only when
+other triggers worked". Der Wechsel erzeugte dann keinen eigenen Datensatz, sondern führe im
+nächsten mit, und der beobachtete Zeitpunkt wäre zu spät statt exakt. Der Standard ist 5 (On
+Change). **Offen und am Gerät zu prüfen** — explizit nummeriert steht die Operandenliste nicht in
+der Dokumentation, und die Messung ist durch eigene Testschaltvorgänge verunreinigt. Steht der
+Operand tatsächlich auf Monitoring, wäre `On Change` die bessere Einstellung: ein zusätzlicher
+Datensatz je Zündungswechsel, keine zusätzliche Übertragung (Priorität bleibt Low).
+
+Verifiziert in `audi_ha_test`:
+
+| Fall | Ergebnis |
+|---|---|
+| Signal 1200 s (5 min Fahrt + Nachlauf) | Fahrt **300 s** gespeichert |
+| Signal 930 s (30 s Zündung) | **keine** Fahrt, Bestand 12 → 12 |
+| Gegenprobe | Warnung mit 887 s Abweichung ausgelöst und protokolliert |
+
+Testfahrt anschließend über `fahrt_loeschen` entfernt; Bestand unverändert 11 Fahrten.
+
 ## Working conventions (observed — keep them)
 
 - German is the project language: identifiers, comments, commits, UI texts. Exceptions: