Ein Update-Knopf, Modell als Auswahlfeld, abgestellt schliesst fahrend aus

- Die Update-Kachel hat genau einen Knopf am Ende. Er traegt in jedem
  Zustand den naechsten faelligen Schritt (suchen, installieren, Neustart,
  Neuladen); Beschriftung und Fuellung wechseln mit. Die Abschnitte
  darueber behalten ihre Werte und verlieren nur ihre Knoepfe.
- Abstand unter der Trennlinie von 28 auf 16 px: das padding-top verhindert
  das Kollabieren des margin der Werteliste, also zaehlt jetzt nur noch das
  padding.
- Modell ist in der App ein Auswahlfeld statt eines Textfelds, wie im
  Panel. Die Liste liegt als Zweitschrift in daten/fahrzeugmodelle.ts;
  fahrzeugmodelle.test.ts liest die Panel-Quelle ein und vergleicht sie
  Eintrag fuer Eintrag, damit die beiden nicht auseinanderlaufen.
- Faehrt der Wagen, sagen Uebersicht und Sicherheitsseite das, statt
  "sicher abgestellt" zu behaupten. Die Zuendung meldet der Dongle in
  Sekunden, Tuer- und Schlossmeldungen kommen verzoegert - die schnellere
  Quelle hat Vorrang, weil sonst das Wort nicht stimmt.
- tankerkennung: der Tiefststand wird vor dem Anlegen gesetzt. Ein
  gepufferter Schwung Datensaetze legte sonst denselben Tankvorgang
  zweimal an, weil der zweite Zustandswechsel waehrend des Wartens noch
  den alten Tiefststand las (04.09.2026, 29,8 l und 29,7 l).
- flespi: nach dem Leeren des Zwischenspeichers wird nur abgeglichen, wenn
  ein Geraetewert vorliegt. Sonst ueberschrieb der Waechterfehler den
  frisch gelesenen Stand in der Kachel.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-09-05 17:12:51 +02:00
co-authored by Claude Opus 5
parent 1838ab0401
commit 255a593b50
14 changed files with 469 additions and 73 deletions
+138 -1
View File
@@ -1,6 +1,6 @@
# AGENTS.md — Project state, review findings, open items, and working rules
**Last updated: 2026-09-04** (Tankstelle zweizeilig und antippbar, die Belegkarte sagt bei
**Last updated: 2026-09-05** (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
@@ -7633,6 +7633,143 @@ verwerfen - was sie fangen soll, liegt Jahrzehnte daneben.
An acht Faellen geprueft: Epoche, beide ID-Verwechslungen und 366 Tage
verworfen; jetzt, 2 Tage und 364 Tage angenommen.
## DA. Ein Knopf statt drei, abgestellt schließt fahrend aus, und zwei Tankvorgänge aus einem Datensatz (2026.9.5.35)
### Die Update-Kachel hat genau einen Knopf
Rückfrage des Eigentümers: *„update installieren ist ein separater button unter
integration. warum nicht den update suchen button dafür verwenden und nur die
optik und schrift zur installation anpassen?"* — berechtigt: über dem Suchknopf
stand je nach Zustand ein zweiter, gleich aussehender Knopf.
Der eine Knopf am Kachelende trägt jetzt in jedem Zustand den **nächsten
fälligen Schritt**, Beschriftung und Füllung wechseln mit:
| Zustand | Knopf |
|---|---|
| läuft gerade | Kreisel im Knopf, „Installiere …" / „Home Assistant startet neu …" / „Prüfe …" |
| installiert, Neustart nötig | „Installation abschließen und neu starten" (gefüllt) |
| installiert, nur Oberfläche (Panel) | „Seite neu laden" (gefüllt) |
| Update verfügbar | „Update installieren" (gefüllt) |
| sonst | „Auf Update prüfen" |
Die Reihenfolge ist eine **Rangfolge, keine Auswahl**: liegt ein Neustart an,
ist das der nächste Schritt, egal was sonst bereitliegt. Ein gleichzeitiges
Integrations- UND App-Update gibt es dabei praktisch nicht — `buendelPasst()`
bietet ein Bündel erst an, wenn es zur laufenden Serverfassung passt, also nach
der Integration.
Die Abschnitte darüber behalten ihre Werte- und Meldungszeilen und verlieren nur
ihre Knöpfe. Der Abstand unter der Trennlinie war 28 px (16 px `padding` plus
12 px `margin` der Werteliste, die wegen des `padding` **nicht** kollabieren) —
`.dm-kachelabschnitt > :first-child { margin-top: 0 }` lässt nur noch das
`padding` zählen.
### Modell ist auch in der App ein Auswahlfeld
Vom Eigentümer bemerkt: *„einrichten/modell ist in der app kein dropdown"*. Das
Panel hatte seit jeher ein `<select>` aus `FAHRZEUG_MODELLE`, die App ein freies
Textfeld — ein frei getippter Titel führt zu keinem oder zum falschen
Typenschild, denn das Bild wird über den Modellnamen gesucht.
Die Liste steht jetzt in `companion-app/src/daten/fahrzeugmodelle.ts` als
Zweitschrift. **Zwei Codebasen, eine Liste** — dass sie gleich bleiben, sichert
`fahrzeugmodelle.test.ts`, der die Panel-Quelle einliest und Eintrag für Eintrag
vergleicht; ein Auseinanderlaufen fällt damit im Testlauf auf, nicht erst beim
Nutzer. Übernommen ist auch das Verhalten des Panels, einen gespeicherten, nicht
mehr gelisteten Titel voranzustellen, statt die Auswahl still auf den ersten
Eintrag zurückfallen zu lassen.
### Abgestellt und unterwegs schließen einander aus
Ansage des Eigentümers: *„es kann nicht sein dass das fahrzeug sicher abgestellt
ist und zeitgleich fährt"* und *„genauso parken und fahren geht nicht
gleichzeitig"*.
Die beiden Aussagen kommen aus verschiedenen Quellen: Tür-, Fenster- und
Schlossmeldungen liefert der EU Data Act mit spürbarer Verzögerung (vom
Eigentümer ausdrücklich hingenommen), die Zündung meldet der Dongle in Sekunden.
Die schnellere Quelle hat Vorrang — **nicht weil die andere falsch wäre**
(verriegelt ist der Wagen während der Fahrt tatsächlich), sondern weil das WORT
„abgestellt" dann nicht stimmt.
Beide Oberflächen fragen dafür `standortZustand().faehrt`, also dieselbe
Funktion, die das Standortmenü schon benutzt — und übernehmen deren Wortlaut
„Zündung an" statt „fährt": einen Bewegungssensor gibt es nicht, die Zündung
steht auch im Stand mit laufendem Motor auf an. Auf der Sicherheitsseite lautet
die Sammelzeile „Zündung an - Fahrzeug in Betrieb", mit dem Punkt des
Standortmenüs statt Haken, Kreuz oder Fragezeichen; die vier Gruppenzeilen
darunter zeigen unverändert, was die Sensoren melden.
Die Parkanzeige war bereits richtig — `standortZustand()` unterdrückt „Geparkt
seit" bei laufender Zündung seit jeher.
### Zwei Tankvorgänge aus einem gepufferten Schwung
Frage des Eigentümers zu zwei Einträgen vom 04.09.2026, 21:36:17, über 29,8 l
und 29,7 l. In der Aufzeichnung nachgesehen: `can_fuel_volume` stand den ganzen
Tag auf **7**, dann lieferte der Dongle um 21:36:50 einen gepufferten Schwung
(`message_timestamp` in Zehnsekundenschritten über gut fünf Stunden) und meldete
in derselben Sekunde **36,8** und **36,7**.
Kein echtes Tanken, sondern der Sprung vom Wert des Prüfstands auf den ersten
echten CAN-Wert. Dass daraus **zwei** Einträge wurden, ist ein Wettlauf:
`_automatisch_anlegen()` wartet auf Gerätezeit und Ablage, in dieser Zeit kommt
der nächste Zustandswechsel dran und liest oben noch den ALTEN Tiefststand. Der
Tiefststand wird jetzt **vor** dem Anlegen gesetzt (`tiefststand_liter_setzen()`
belegt das Feld als erste Anweisung, also bevor es selbst wartet), in beiden
Zweigen. Dieselbe Klasse Fehler wie der Signalwechsel-Wettlauf in Abschnitt BU.
**Die beiden Einträge bleiben stehen** — das sind die Daten des Eigentümers.
### Der Dongle steht auf Ultra Deep Sleep
`config_26.cfg` gegen `config_25.cfg` (beide gzip-gepackt, `gunzip` liest sie),
feldweise verglichen: **genau zwei Unterschiede**.
| Parameter | 25 | 26 | Bedeutung |
|---|---|---|---|
| `102` | 2 | **4** | Sleep Mode: Deep Sleep zu Ultra Deep Sleep |
| `19002` | 60 | **120** | Movement Stop Delay |
Die 120 s sind die richtige Konsequenz: in UDS weckt die Zündung nicht mehr,
also muss das Aufwachen über den Beschleunigungssensor lange genug tragen, bis
der Motor läuft und RPM kommt.
**Noch nicht bestätigt:** die Dongle-Kachel liest über flespi weiterhin
`sleep_mode.mode.type = 2`, bestätigt vom Gerät am 05.09.2026 um 14:44:40 UTC,
bei `timeout = 15` (passend zu `103`). Ob die USB-Übertragung vor oder nach
diesem Zeitpunkt lag, ist von hier aus nicht feststellbar und beim Eigentümer zu
klären.
**Zu `107` (Records saving/sending without TS): keine Änderung nötig.** Der
Eigentümer sieht im Configurator „After Time Sync"; die Zeitquelle ist wegen
`902:pool.ntp.org`/`903:time.nist.gov` das Mobilfunknetz, nicht GPS — ein
fehlender Fix hält deshalb keine Pakete zurück. `Always` wäre ein Rückschritt:
seit Abschnitt AY kommen Fahrtbeginn und -ende aus der Geräteuhr, und Datensätze
mit ungestellter Uhr würden die Fahrtgrenzen verschieben.
**Merkposten aus derselben Frage:** ich hatte `107:2` aus der Reihenfolge dreier
Beschriftungen in einem Binärabzug des Configurators als „Always" gelesen — die
Reihenfolge dort ist alphabetisch, keine Enumeration. Eine Reihenfolge in einem
Abzug, einem Verzeichnis oder einer Ausgabe ist keine Semantik.
### Verifiziert
Backend-Suite (aktualisierung, verlauf, fahrterkennung, belegparser) vollständig
grün, App **303 Tests**, Panel als Modul geparst, `audi_ha_test` auf
`2026.9.5.35` mit **0 Tracebacks**. Live im Panel: die Update-Kachel trägt genau
einen Knopf („Auf Update prüfen"), Zündung auf „an" gesetzt zeigt die Übersicht
„Zündung an" statt „Sicher abgestellt" und die Sicherheitsseite „Zündung an -
Fahrzeug in Betrieb" mit Punkt statt Kreis; danach zurückgesetzt. „Jetzt lesen"
in der Dongle-Kachel liefert wieder die Werte statt der Wächtermeldung — damit
ist auch die Reihenfolge-Korrektur in `flespi.py` (Cache leeren, erst danach
abgleichen, und nur bei bekanntem Wert) live belegt.
**Nicht live geprüft:** dieselben Änderungen in der App. Sie brauchen einen
gespeicherten Zugang; belegt sind sie über `tsc`, die 303 Tests und den
Listenvergleich gegen die Panel-Quelle.
## Working conventions (observed — keep them)
- German is the project language: identifiers, comments, commits, UI texts. Exceptions: