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:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user