Eine Neuschreibung ist kein Wechsel - Wartezeit startet nicht mehr neu

Home Assistant schreibt denselben Zustandswert auch neu, wenn sich nur ein
Attribut geruehrt hat. Am 04.09.2026 gezaehlt: von 22 Zustandszeilen der
Zuendung waren nur 6 echte Wechsel, die uebrigen 16 Neuschreibungen - und
alle 6 Wechsel lagen ausserhalb der Fahrten. Das Zuendungssignal ist
unterwegs stabil.

Der Beobachter unterschied das nicht. Fiel eine Neuschreibung von "aus" in
die laufende Wartezeit, brach Zweig 2 die wartende Bestaetigung ab und
begann die 15 Minuten von vorn. Am 04.09. ist es nicht passiert - die
Neuschreibungen lagen hinter dem Fenster -, aber das Loch war da.

_signalwechsel() bekommt jetzt mit, ob es ein echter Wechsel war. Eine
Neuschreibung, waehrend fuer diese Fahrt schon eine Bestaetigung wartet,
laesst sie stehen.

Bewusst NICHT als Filter ganz oben: _spaetes_aus() verlaesst sich darauf,
ein Zuendungs-Aus auch als off -> off zu sehen - daran haengt das
Nachtragen vorlaeufiger Enden. Die Pruefung sitzt nur in Zweig 2, und ein
eigener Test belegt, dass der andere Weg weiter offen ist.

21 Tests (von 18), Gegenprobe mit ausgeschalteter Pruefung scheitert wie
erwartet an einem. py_compile sauber, audi_ha_test auf 2026.9.4.25 ohne
Traceback.

AGENTS.md haelt ausserdem fest: die Beschreibung des Beenden-Knopfes war zu
weit gefasst (die Korrektur zieht nur nach hinten, nie nach vorn), und der
flespi-Cache laesst sich ueber DELETE auf die Einstellung zum Neulesen
zwingen - mit dem Haken, dass dabei ausstehende Werte verloren gingen.

AGENTS.md

@@ -11230,3 +11230,89 @@ Staenden - so sollen sie sein.
   zweiten Fahrt hielt die Sitzung 18 Minuten durch und schloss normal, der
   Rueckstand lag durchgehend bei 1-3 Sekunden. **Das wirkt** - die
   Zustellluecke selbst ist damit aber noch nicht als behoben bewiesen.
+
+### Nachtrag: eine Neuschreibung ist kein Wechsel (2026.9.4.25)
+
+Beim Nachgehen der Frage des Eigentuemers - *"warum kommt bei laufendem Motor
+ueberhaupt ein Ignition-Signal?"* - kam heraus: **es kommt keines.**
+
+Ueber die Zustandszeilen der Zuendung am 04.09.2026 gezaehlt, getrennt nach
+echtem Wertwechsel und blosser Neuschreibung:
+
+| | |
+|---|---|
+| Zeilen gesamt | 22 |
+| **echte Wechsel** | **6** |
+| Neuschreibungen desselben Werts | 16 |
+
+Und die sechs Wechsel liegen alle ausserhalb der Fahrten: drei beim Anstecken
+(18:10:27 bis :30, drei Sekunden Einschwingen), zwei beim gepufferten Stapel
+(23:36:50) und einer am Ziel (23:46:04). **Waehrend beider Fahrten kein
+einziger.** Das Signal ist unterwegs stabil; das Flackern gehoert zum
+Anstecken und entfaellt, sobald der Dongle im Fahrzeug bleibt.
+
+**Der Beobachter unterscheidet das aber nicht.** `_fahrtsignal_geaendert()`
+reicht `neu` und `alt` ungefiltert weiter, jede Neuschreibung laeuft durch die
+volle Fahrterkennung. Faellt eine Neuschreibung von "aus" in die laufende
+Wartezeit, brach Zweig 2 die wartende Bestaetigung ab und begann die 15
+Minuten von vorn - bei genuegend vielen nie ein Ende.
+
+**Am 04.09. ist es nicht passiert** (die Neuschreibungen lagen 19,7 Minuten
+nach dem echten "aus", also hinter dem Fenster). Das Loch war trotzdem da.
+
+`_signalwechsel()` bekommt jetzt mit, ob es ein echter Wechsel war. Eine
+Neuschreibung, waehrend fuer DIESE Fahrt schon eine Bestaetigung wartet, laesst
+sie stehen.
+
+**Warum nicht einfach `if neu == alt: return` ganz oben:** `_spaetes_aus()`
+verlaesst sich ausdruecklich darauf, ein Zuendungs-Aus auch dann zu sehen, wenn
+es "unter Umstaenden zusammen mit dem naechsten on" ankommt - und entscheidet
+ueber die Geraetezeit, nicht ueber die Reihenfolge. Ein zweites, spaeter
+gepuffertes Aus bei bereits stehendem "off" waere ein `off -> off` und wuerde
+von so einem Filter verschluckt. Genau daran haengt das Nachtragen vorlaeufiger
+Enden. Die Pruefung sitzt deshalb **nur in Zweig 2**.
+
+**21 Tests** in `test_zuendungspause.py` (von 18). Gegenprobe mit
+ausgeschalteter Pruefung: **1 Test scheitert**, mit ihr laufen alle 21. Dazu
+ein Test, der belegt, dass ein `off -> off` ohne laufende Fahrt weiterhin bei
+`_spaetes_aus()` ankommt - sonst haette ich mir genau das kaputtgemacht, wovor
+der Kommentar dort warnt.
+
+### Zum Knopf "Fahrt beenden" - meine Beschreibung war zu weit
+
+Ich hatte geschrieben, das vorlaeufige Ende sei dafuer da, "dass ein spaeter
+nachgereichtes Zuendungs-Aus es korrigiert". Der Eigentuemer hat widersprochen,
+und er hat recht. `_vorlaeufiges_ende_korrigieren()` zieht **nur nach hinten**
+(`if echt <= ende_bisher: return False` - *"frueher waere kein Nachtrag,
+sondern eine Verkuerzung"*).
+
+Am Beispiel des Eigentuemers durchgerechnet - Tankstelle, Motor aus 11:59,
+Knopf 12:01, Zuendungs-Aus entsteht 12:02:
+
+    echt = 12:02 - 180 s = 11:59  <=  vorlaeufiges Ende 12:00  ->  keine Korrektur
+
+Die bewusste Entscheidung an der Zapfsaeule bleibt also stehen. Korrigiert wird
+nur, wenn danach **wirklich weitergefahren** wurde und der Rest gepuffert
+nachkommt. Und in beiden Reihenfolgen - Knopf vor oder nach den 180 s - gibt es
+keine Wartezeit, und das naechste Zuendungssignal beginnt eine neue Fahrt.
+
+### Der flespi-Cache laesst sich zwingen
+
+Der Eigentuemer hat auf den Panel-Knopf "clear cache and synchronize"
+hingewiesen. Die API-Entsprechung ist belegt (zwei Quellen):
+
+**`DELETE /gw/devices/{id}/settings/{name}`** - *"delete the cached value and
+thus force flespi to re-read the actual value from the device"*. Es loescht
+flespis Zwischenspeicher, **nicht** die Einstellung im Geraet.
+
+**Haken, der in die Umsetzung gehoert:** dasselbe DELETE verwirft auch einen
+**ausstehenden** Wert. Stuende gerade eine Aenderung in der Warteschlange - wie
+`1003`/`1004` am 04.09. acht Stunden lang -, waere sie damit weg, ohne dass es
+jemand merkt. Ein Cache-Loeschen muss jede Einstellung mit `pending`
+ueberspringen.
+
+Noch nicht gebaut. Offen bleiben damit:
+
+* "Jetzt lesen" als echtes Lesen (Cache loeschen, dann holen).
+* Der Waechter darf keinen Gleichstand melden, solange unbekannt ist, wann der
+  Wert zuletzt vom Geraet bestaetigt wurde.