Neue Daten aus Backend #11

New issue

Closed

opened 2026-08-31 12:15:10 +02:00 by erdbruegger · 1 comment

erdbruegger commented

2026-08-31 12:15:10 +02:00

Owner

Unser Backend (Link) hatten wir zuletzt um die reichhaltigen Daten aus dem dbcvpage TBox command ergänzt. Könntest du die App entsprechend aktualisieren, dass diese Daten angezeigt werden? Ich denke unter "Mehr>Diagnose" passt vielleicht am besten?

Unser Backend [(Link)](https://forgejo.timo-erdbruegger.de/aiways/Backend/issues/9) hatten wir zuletzt um die reichhaltigen Daten aus dem dbcvpage TBox command ergänzt. Könntest du die App entsprechend aktualisieren, dass diese Daten angezeigt werden? Ich denke unter "Mehr>Diagnose" passt vielleicht am besten?

erdbruegger added the

claude

label

2026-08-31 12:16:53 +02:00

claudecode referenced this issue from a commit

2026-08-31 13:18:46 +02:00

release: dbcvpage-Daten in der Diagnose — Sweep, Reifen, Fehlerspeicher, Messwerte (Issue #11)

claudecode added the

in-progress

label

2026-08-31 13:20:20 +02:00

claudecode commented

2026-08-31 13:20:53 +02:00

Collaborator

Umgesetzt — Mehr → Diagnose war der richtige Ort, die Seite gab es schon, sie zeigte bisher nur die Kerngrößen aus /latest. Jetzt hängt der ganze dbcvpage-Ertrag daran.

Was die Diagnose-Seite jetzt zeigt

Neu ganz oben: „Letztes Auslesen" — Zeitpunkt (samt Alter, „vor 2 Tagen"), Quelle (dbcvpage), Zahl der Messwerte, Fehlerflags und davon aktive. Damit ist auf einen Blick klar, wie frisch die Daten sind und wie viel der Sweep überhaupt geliefert hat.

Neu: „Reifen" — Druck in bar und Temperatur je Rad, in der Reihenfolge vorne links/rechts, hinten links/rechts. Die kamen mit dem Sweep dazu und standen bisher nirgends in der App.

Drei Einstiege unten:


Fehlerspeicher	Zeigt in der Zeile schon, wie viele Meldungen aktiv sind — bei mehr als null wird das Icon bernsteinfarben.
Messwerte	Alle ~490 Signale des letzten Sweeps.
Verlauf	wie bisher, die Zeitreihen.

Fehlerspeicher

Voreingestellt nur die aktiven Flags — das ist ja die Frage, die man an eine Diagnose stellt. Ein Schalter blendet die stillen dazu (236 insgesamt), zum Gegenlesen. Je Zeile: Signalname, Steuergerät, Seite, Rohwert, Zeitpunkt, und ein roter bzw. grauer Punkt für aktiv/still.

Ehrlich dazugesagt: was ein einzelnes Flag bedeutet, wissen wir nicht — VCUFltSN17 ist alles, was wir haben, eine Klartext-Tabelle dazu existiert in unserem Katalog nicht. Die Seite behauptet auch nichts anderes; sie nennt das Steuergerät und sagt, dass gesetzt eben gesetzt ist. (Bei Deinem Fahrzeug stehen aktuell 16 aktive Flags, alle aus dem VCU.)

Messwerte

Alle ~490 Signale, nach Kategorie gruppiert (Batterie-Zellspannung, Laden/Wandler, Karosserie/12V/Reifen, Klima …), mit Suchfeld über Signalname, Steuergerät und Kategorie und Kategorie-Chips zum Eingrenzen. Je Zeile: Signalname, darunter klein Domäne · Tier · Seite, rechts der physikalische Wert mit Einheit. Wo eine Skala den Rohwert verändert hat, steht der Rohwert mit dabei — bei BCMTpmsFLWhlPress also „264 kPa" und „roh 96", damit die Umrechnung nachprüfbar bleibt. Unten die Fußzeile „x von y Signalen", damit nie unklar ist, ob gefiltert wurde.

Eine deutsche Bezeichnung je Signal gibt es bewusst nicht: die führt auch der Backend-Katalog nicht, und ich wollte 490 Namen nicht erfinden. Kategorie + Suche sind der Weg zum Wert.

Technisch

Neue Modelle VehicleSnapshot, VehicleSignal, VehicleFault, Tires. Der Sweep-Kopf kommt vom Backend in zwei Schreibweisen (camelCase aus /latest, snake_case aus /snapshots) — die App nimmt beide.
ApiClient.snapshots/details/diagnostics. Das Limit steht auf 5000, also weit über den ~490 Signalen — so wird die Liste nicht stillschweigend abgeschnitten.
Ältere /latest-Antworten ohne snapshot/tires bleiben gültig, die Karten fehlen dann einfach.
Gegen die Live-Instanz geprüft (Fahrzeug 7, Sweep vom 29.08.): /details 490 Zeilen, /diagnostics 16 aktiv bzw. 236 gesamt, /snapshots 1 Zeile.
flutter analyze sauber, 94 Tests grün (14 neue: Parsing der echten Backend-Antworten, Filtern/Gruppieren, Smoke-Test der beiden neuen Seiten). Web-Build lokal gebaut.

Was noch fehlt: Release und Deploy

Forgejo legt seit ca. 12:24 für neue Pushes keine Actions-Runs mehr an. Drei Pushes sind auf main angekommen (325abd2, 116412d, 951023c), es startet aber schlicht kein Lauf — der letzte Release-Lauf wurde nur „cancelled". An die Runner-Verwaltung komme ich als claudecode nicht heran (nicht Repo-Owner).

Heißt: der Code liegt fertig auf main, es gibt aber noch keine neue APK und keinen Web-Deploy. Auf http://192.168.1.85/ steht weiter v1.0.45. Sobald der Runner wieder läuft, baut der nächste Push Release + Deploy und ich melde die Version hier nach. Verifiziert ist bis dahin nur, was lokal geht: Analyse, Tests, Web-Build und die Endpunkte gegen die Live-Instanz.

Umgesetzt — **Mehr → Diagnose** war der richtige Ort, die Seite gab es schon, sie zeigte bisher nur die Kerngrößen aus `/latest`. Jetzt hängt der ganze dbcvpage-Ertrag daran. ## Was die Diagnose-Seite jetzt zeigt **Neu ganz oben: „Letztes Auslesen"** — Zeitpunkt (samt Alter, „vor 2 Tagen"), Quelle (`dbcvpage`), Zahl der Messwerte, Fehlerflags und davon aktive. Damit ist auf einen Blick klar, wie frisch die Daten sind und wie viel der Sweep überhaupt geliefert hat. **Neu: „Reifen"** — Druck in bar und Temperatur je Rad, in der Reihenfolge vorne links/rechts, hinten links/rechts. Die kamen mit dem Sweep dazu und standen bisher nirgends in der App. **Drei Einstiege unten:** | | | |---|---| | **Fehlerspeicher** | Zeigt in der Zeile schon, wie viele Meldungen aktiv sind — bei mehr als null wird das Icon bernsteinfarben. | | **Messwerte** | Alle ~490 Signale des letzten Sweeps. | | **Verlauf** | wie bisher, die Zeitreihen. | ### Fehlerspeicher Voreingestellt nur die **aktiven** Flags — das ist ja die Frage, die man an eine Diagnose stellt. Ein Schalter blendet die **stillen** dazu (236 insgesamt), zum Gegenlesen. Je Zeile: Signalname, Steuergerät, Seite, Rohwert, Zeitpunkt, und ein roter bzw. grauer Punkt für aktiv/still. Ehrlich dazugesagt: **was ein einzelnes Flag bedeutet, wissen wir nicht** — `VCUFltSN17` ist alles, was wir haben, eine Klartext-Tabelle dazu existiert in unserem Katalog nicht. Die Seite behauptet auch nichts anderes; sie nennt das Steuergerät und sagt, dass gesetzt eben gesetzt ist. (Bei Deinem Fahrzeug stehen aktuell 16 aktive Flags, alle aus dem VCU.) ### Messwerte Alle ~490 Signale, **nach Kategorie gruppiert** (Batterie-Zellspannung, Laden/Wandler, Karosserie/12V/Reifen, Klima …), mit **Suchfeld** über Signalname, Steuergerät und Kategorie und **Kategorie-Chips** zum Eingrenzen. Je Zeile: Signalname, darunter klein Domäne · Tier · Seite, rechts der physikalische Wert mit Einheit. Wo eine Skala den Rohwert verändert hat, steht der Rohwert mit dabei — bei `BCMTpmsFLWhlPress` also „264 kPa" und „roh 96", damit die Umrechnung nachprüfbar bleibt. Unten die Fußzeile „x von y Signalen", damit nie unklar ist, ob gefiltert wurde. Eine deutsche Bezeichnung je Signal gibt es bewusst nicht: die führt auch der Backend-Katalog nicht, und ich wollte 490 Namen nicht erfinden. Kategorie + Suche sind der Weg zum Wert. ## Technisch - Neue Modelle `VehicleSnapshot`, `VehicleSignal`, `VehicleFault`, `Tires`. Der Sweep-Kopf kommt vom Backend in zwei Schreibweisen (camelCase aus `/latest`, snake_case aus `/snapshots`) — die App nimmt beide. - `ApiClient.snapshots/details/diagnostics`. Das Limit steht auf 5000, also weit über den ~490 Signalen — so wird die Liste nicht stillschweigend abgeschnitten. - Ältere `/latest`-Antworten ohne `snapshot`/`tires` bleiben gültig, die Karten fehlen dann einfach. - Gegen die Live-Instanz geprüft (Fahrzeug 7, Sweep vom 29.08.): `/details` 490 Zeilen, `/diagnostics` 16 aktiv bzw. 236 gesamt, `/snapshots` 1 Zeile. - `flutter analyze` sauber, **94 Tests grün** (14 neue: Parsing der echten Backend-Antworten, Filtern/Gruppieren, Smoke-Test der beiden neuen Seiten). Web-Build lokal gebaut. ## Was noch fehlt: Release und Deploy **Forgejo legt seit ca. 12:24 für neue Pushes keine Actions-Runs mehr an.** Drei Pushes sind auf `main` angekommen (`325abd2`, `116412d`, `951023c`), es startet aber schlicht kein Lauf — der letzte Release-Lauf wurde nur „cancelled". An die Runner-Verwaltung komme ich als `claudecode` nicht heran (nicht Repo-Owner). Heißt: **der Code liegt fertig auf `main`, es gibt aber noch keine neue APK und keinen Web-Deploy.** Auf http://192.168.1.85/ steht weiter v1.0.45. Sobald der Runner wieder läuft, baut der nächste Push Release + Deploy und ich melde die Version hier nach. Verifiziert ist bis dahin nur, was lokal geht: Analyse, Tests, Web-Build und die Endpunkte gegen die Live-Instanz.

claudecode added

needs-review

and removed

in-progress

labels

2026-08-31 13:21:03 +02:00

erdbruegger closed this issue

2026-08-31 14:36:41 +02:00