Page: Laden

erdbruegger commented

2026-08-28 02:20:25 +02:00

Owner

Neue Seite "Laden" direkt nach "Übersicht", bzw. "Fahrzeug" - wenn der andere Issue umgesetzt ist.
Hier eine schöne Lade-Ansicht, zeigt ein paar mehr Infos über den Akku, vielleicht eine schöne Grafik, die aktuellen Charge-Werte falls vorhanden,etc. Pp.

Neue Seite "Laden" direkt nach "Übersicht", bzw. "Fahrzeug" - wenn der andere Issue umgesetzt ist. Hier eine schöne Lade-Ansicht, zeigt ein paar mehr Infos über den Akku, vielleicht eine schöne Grafik, die aktuellen Charge-Werte falls vorhanden,etc. Pp.

erdbruegger added the

claude

label

2026-08-28 02:30:22 +02:00

claudecode added the

in-progress

label

2026-08-28 02:35:10 +02:00

claudecode referenced this issue from a commit

2026-08-28 02:57:38 +02:00

release: Fahrzeug/Laden/Mehr statt Uebersicht/Steuerung/Mehr (Issues #2-#5)

claudecode commented

2026-08-28 03:01:52 +02:00

Collaborator

Umgesetzt und live (http://192.168.1.85/, Release v1.0.23).

Neue Seite Laden, direkt nach „Fahrzeug" in der Bottom-Nav.

Was drauf ist:

Großer, senkrechter Akku mit Füllstands-Verlauf und SoC in der Mitte, Farbe kippt bei ≤20 % auf Gelb und ≤10 % auf Rot.
Klartext-Status: Lädt / Entlädt / Nicht am Laden, dazu Reichweite und Zeitstempel.
Voll in ca. — Hochrechnung aus aktueller Leistung und Restkapazität (nur wenn wirklich geladen wird).
Aktuelle Werte: Leistung (kW, hervorgehoben), Spannung, Strom.
Akku-Details: Zellanzahl, Zelle min/max, Spreizung in mV, Mittelwert, Temperatur min/max, Nennkapazität und die grob im Akku steckende Energie.
Ladestand-Verlauf als Chart über die Zeitreihe.

Drei Annahmen, bitte gegenlesen:

charge_state ist backendseitig nicht dokumentiert — die Live-Instanz liefert gerade 3, unser Code prüft historisch auf 1. Ich habe die Bedeutung deshalb nicht geraten: „lädt" entscheidet sich primär am Strom (pack_current < -1), und der Rohwert steht sichtbar in der Diagnose, damit wir die Bedeutung an echten Ladedaten ablesen können. Wenn du mir sagst, was 1/2/3 heißen, baue ich es sauber ein.
Pack-Kapazität mit 63 kWh angesetzt (U5 brutto) — das ist die Basis für „Voll in ca." und „Energie im Akku". Falls du den echten Netto-Wert hast, ist es eine Konstante in charging_screen.dart.
Zellspannungen und Temperaturen liefert die Telemetrie derzeit nicht — die Karten blenden sich automatisch ein, sobald cells/temps ankommen; bis dahin steht dort ein Hinweis statt einer leeren Fläche.

Umgesetzt und live (**http://192.168.1.85/**, Release `v1.0.23`). Neue Seite **Laden**, direkt nach „Fahrzeug" in der Bottom-Nav. **Was drauf ist:** - **Großer, senkrechter Akku** mit Füllstands-Verlauf und SoC in der Mitte, Farbe kippt bei ≤20 % auf Gelb und ≤10 % auf Rot. - **Klartext-Status:** Lädt / Entlädt / Nicht am Laden, dazu Reichweite und Zeitstempel. - **Voll in ca.** — Hochrechnung aus aktueller Leistung und Restkapazität (nur wenn wirklich geladen wird). - **Aktuelle Werte:** Leistung (kW, hervorgehoben), Spannung, Strom. - **Akku-Details:** Zellanzahl, Zelle min/max, **Spreizung in mV**, Mittelwert, Temperatur min/max, Nennkapazität und die grob im Akku steckende Energie. - **Ladestand-Verlauf** als Chart über die Zeitreihe. **Drei Annahmen, bitte gegenlesen:** 1. **`charge_state` ist backendseitig nicht dokumentiert** — die Live-Instanz liefert gerade `3`, unser Code prüft historisch auf `1`. Ich habe die Bedeutung deshalb *nicht* geraten: „lädt" entscheidet sich primär am Strom (`pack_current < -1`), und der Rohwert steht sichtbar in der Diagnose, damit wir die Bedeutung an echten Ladedaten ablesen können. Wenn du mir sagst, was 1/2/3 heißen, baue ich es sauber ein. 2. **Pack-Kapazität mit 63 kWh angesetzt** (U5 brutto) — das ist die Basis für „Voll in ca." und „Energie im Akku". Falls du den echten Netto-Wert hast, ist es eine Konstante in `charging_screen.dart`. 3. **Zellspannungen und Temperaturen liefert die Telemetrie derzeit nicht** — die Karten blenden sich automatisch ein, sobald `cells`/`temps` ankommen; bis dahin steht dort ein Hinweis statt einer leeren Fläche.

claudecode added

needs-review

and removed

in-progress

labels

2026-08-28 03:02:01 +02:00

erdbruegger commented

2026-08-28 10:53:49 +02:00

Author

Owner

Können wir auf der Lade-Seite noch ähnlich der FordApp eine Max-Charge hinterlegen? Also das man so einen Schieber hat, mit dem man einstellen kann, lade bis 85%

erdbruegger removed the

needs-review

label

2026-08-28 10:53:56 +02:00

claudecode added the

in-progress

label

2026-08-28 11:16:17 +02:00

claudecode referenced this issue from a commit

2026-08-28 11:22:31 +02:00

release: Ladelimit je Fahrzeug auf der Laden-Seite (Issue #3)

claudecode commented

2026-08-28 11:29:41 +02:00

Collaborator

Umgesetzt und live (http://192.168.1.85/, Commit 272e39b) — Strg+F5 wegen Cache.

Auf der Laden-Seite gibt es jetzt eine Karte Ladelimit — Schieber wie in der FordPass-App:

50 bis 100 % in 5er-Schritten, der eingestellte Wert steht groß daneben. 100 % = kein Limit, dann verhält sich alles wie bisher.
Der Wert wird je Fahrzeug gemerkt und überlebt den App-Neustart.
Im großen Akku markiert eine gestrichelte Linie das Limit, im Ladestand-Verlauf liegt eine gestrichelte Limit-Linie über der Kurve.
Die Hochrechnung rechnet aufs Limit statt auf 100 %: aus „Voll in ca.“ wird „Auf 85 % in ca.“. Ist das Limit erreicht, steht dort „Ladelimit erreicht“.

Eine Sache, die Du wissen musst: Das Auto kann den Wunsch noch nicht ausführen. Es gibt keinen BLE-Code für ein Ladelimit im verifizierten Prototyp und im Backend kein Feld dafür. Beim Loslassen des Schiebers geht der Wunsch deshalb als Befehl set_charge_limit mit {"limit": 85} in die normale Kette (Bluetooth → Backend) und liegt als Kommando im Backend bereit — sichtbar wie jeder andere Befehl. Sobald wir wissen, wie das Auto ein Limit entgegennimmt, ist das genau eine Zeile in bleTypeFor. Die App selbst rechnet und zeichnet aber schon vollständig mit dem Limit.

Tests für Hochrechnung, Speicherung je Fahrzeug und die Akku-Marke sind dabei (45 Tests grün, flutter analyze sauber). CI + Deploy grün (analyze/gate/release/deploy-web), live gegengeprüft.

Umgesetzt und live (**http://192.168.1.85/**, Commit `272e39b`) — Strg+F5 wegen Cache. Auf der **Laden**-Seite gibt es jetzt eine Karte **Ladelimit** — Schieber wie in der FordPass-App: - **50 bis 100 % in 5er-Schritten**, der eingestellte Wert steht groß daneben. **100 % = kein Limit**, dann verhält sich alles wie bisher. - Der Wert wird **je Fahrzeug** gemerkt und überlebt den App-Neustart. - Im großen Akku markiert eine **gestrichelte Linie** das Limit, im **Ladestand-Verlauf** liegt eine gestrichelte Limit-Linie über der Kurve. - Die Hochrechnung rechnet aufs Limit statt auf 100 %: aus „Voll in ca.“ wird **„Auf 85 % in ca.“**. Ist das Limit erreicht, steht dort **„Ladelimit erreicht“**. **Eine Sache, die Du wissen musst:** Das Auto kann den Wunsch noch nicht ausführen. Es gibt **keinen BLE-Code für ein Ladelimit** im verifizierten Prototyp und im Backend kein Feld dafür. Beim Loslassen des Schiebers geht der Wunsch deshalb als Befehl **`set_charge_limit`** mit `{"limit": 85}` in die normale Kette (Bluetooth → Backend) und liegt als Kommando im Backend bereit — sichtbar wie jeder andere Befehl. Sobald wir wissen, wie das Auto ein Limit entgegennimmt, ist das genau eine Zeile in `bleTypeFor`. Die App selbst rechnet und zeichnet aber schon vollständig mit dem Limit. Tests für Hochrechnung, Speicherung je Fahrzeug und die Akku-Marke sind dabei (45 Tests grün, `flutter analyze` sauber). CI + Deploy grün (analyze/gate/release/deploy-web), live gegengeprüft.

claudecode added

needs-review

and removed

in-progress

labels

2026-08-28 11:30:04 +02:00

claudecode referenced this issue

2026-08-28 11:53:23 +02:00

Bluetooth Funktionalität #8

erdbruegger commented

2026-09-01 14:51:51 +02:00

Author

Owner

In der Lade-Page ist aktuell unten eine kleine Karte für den "Ladestand-Verlauf", dort wird aber nur der aktuelle Akku-Prozent angezeigt. Ich fände es besser, wenn dort die Ladekurve für die aktuelle Ladesitzung angezeigt wird (also der Leistungsverlauf)

erdbruegger removed the

needs-review

label

2026-09-01 14:51:59 +02:00

claudecode added the

in-progress

label

2026-09-01 14:52:48 +02:00

claudecode referenced this issue from a commit

2026-09-01 15:04:13 +02:00

release: Ladekurve der aktuellen Ladesitzung statt Ladestand-Verlauf (Issue #3)

claudecode commented

2026-09-01 15:15:17 +02:00

Collaborator

Umgesetzt: Die Karte unten auf der Laden-Seite zeigt jetzt die Ladekurve der aktuellen Ladesitzung statt des reinen Ladestands (Commit 26a8538).

Was drin steht

Leistungsverlauf in kW über die Zeit der Sitzung — Achse links, Uhrzeiten unten.
Ladestand als zweite, gestrichelte Linie auf derselben Fläche, Skala rechts in %. Zusammen ist das die Ladekurve, wie man sie kennt.
Kopfzeile: „Aktuelle Ladesitzung · seit 09:39" mit Läuft-Marke, bzw. „Letzte Ladesitzung · ", wenn gerade nicht geladen wird.
Kennzahlen darunter: Jetzt/Zuletzt, Spitze, Ø, Geladen (kWh), dazu Dauer, Ladestand von→bis und die Zahl der Messpunkte.
Antippen zeigt zu jedem Punkt kW und Uhrzeit.

Zwei Dinge, die Du wissen solltest

Die TBox meldet den Pack-Strom nur beim dbcvpage-Sweep. In den letzten zwei Tagen tragen von ~3800 Telemetrie-Zeilen genau 59 überhaupt einen Strom, 21 davon einen Ladestrom. Eine glatt gezeichnete Kurve wäre deshalb gelogen: die Messpunkte bleiben sichtbar, solange es wenige sind, und bei großen Lücken sagt die Karte das auch dazu. Je öfter die Box sweept, desto dichter wird die Kurve — am Code muss dafür nichts geändert werden.
Wann ist eine Sitzung zu Ende? Nach 30 min ohne Ladezeile beginnt eine neue — außer der Ladestand ist über die Lücke hinweg weiter gestiegen, dann wurde durchgehend geladen und es kam nur nichts an (bis 6 h). Genau der heutige Fall: 09:39 (39 %) → 09:42 (40 %) → 2,5 h Funkstille → 12:46 (51 %). Das ist EINE Ladung, keine drei. Die nachgeladene Energie kommt deshalb aus dem Ladestands-Hub (12 % × 63 kWh ≈ 7,6 kWh) und nicht aus einem Integral über vier Messpunkte; Ø ist Energie/Dauer, Spitze der höchste gemessene Wert.

Die Zeilen holt die App serverseitig gefiltert (f_pack_current=<-1, neueste zuerst) statt 880 kB Zeitreihe zu laden. Gibt es noch gar keine aufgezeichnete Ladung, steht an der Stelle weiterhin der alte SoC-Verlauf.

Logik in lib/charge_session.dart, ohne Flutter-Abhängigkeit und gegen die echten Datenmuster getestet; die Karte selbst hat einen eigenen Widget-Test (u. a. 360-dp-Display — der hat prompt einen 11-px-Überlauf in der Kennzahlen-Zeile gefunden, ist behoben). flutter analyze sauber, 116 Tests grün.

Noch nicht live — und das liegt nicht am Code: mein Release-Lauf (#407) wurde um 15:12 von Deinem Push da375f7 („Fahrzeug hinzufügen — Kern") abgebrochen, und der trägt bewusst kein release, also gab es auch keinen Deploy. analyze ist auf beiden Ständen grün, meine Tests laufen auch mit Deinem Commit durch. Ich schiebe nicht ungefragt einen Release-Commit hinterher, weil damit auch Dein Wizard-Kern auf http://192.168.1.85/ ginge. Sag Bescheid, wenn ich das anstoßen soll — oder nimm es einfach mit Deinem nächsten release-Commit mit.

Umgesetzt: Die Karte unten auf der **Laden**-Seite zeigt jetzt die **Ladekurve der aktuellen Ladesitzung** statt des reinen Ladestands (Commit `26a8538`). **Was drin steht** - **Leistungsverlauf in kW** über die Zeit der Sitzung — Achse links, Uhrzeiten unten. - **Ladestand als zweite, gestrichelte Linie** auf derselben Fläche, Skala rechts in %. Zusammen ist das die Ladekurve, wie man sie kennt. - Kopfzeile: „Aktuelle Ladesitzung · seit 09:39" mit **Läuft**-Marke, bzw. „Letzte Ladesitzung · <Datum>", wenn gerade nicht geladen wird. - Kennzahlen darunter: **Jetzt/Zuletzt**, **Spitze**, **Ø**, **Geladen (kWh)**, dazu Dauer, Ladestand von→bis und die Zahl der Messpunkte. - Antippen zeigt zu jedem Punkt kW und Uhrzeit. **Zwei Dinge, die Du wissen solltest** 1. **Die TBox meldet den Pack-Strom nur beim dbcvpage-Sweep.** In den letzten zwei Tagen tragen von ~3800 Telemetrie-Zeilen genau **59** überhaupt einen Strom, 21 davon einen Ladestrom. Eine glatt gezeichnete Kurve wäre deshalb gelogen: die Messpunkte bleiben sichtbar, solange es wenige sind, und bei großen Lücken sagt die Karte das auch dazu. Je öfter die Box sweept, desto dichter wird die Kurve — am Code muss dafür nichts geändert werden. 2. **Wann ist eine Sitzung zu Ende?** Nach 30 min ohne Ladezeile beginnt eine neue — **außer der Ladestand ist über die Lücke hinweg weiter gestiegen**, dann wurde durchgehend geladen und es kam nur nichts an (bis 6 h). Genau der heutige Fall: 09:39 (39 %) → 09:42 (40 %) → **2,5 h Funkstille** → 12:46 (51 %). Das ist EINE Ladung, keine drei. Die **nachgeladene Energie** kommt deshalb aus dem Ladestands-Hub (12 % × 63 kWh ≈ 7,6 kWh) und nicht aus einem Integral über vier Messpunkte; **Ø** ist Energie/Dauer, **Spitze** der höchste gemessene Wert. Die Zeilen holt die App **serverseitig gefiltert** (`f_pack_current=<-1`, neueste zuerst) statt 880 kB Zeitreihe zu laden. Gibt es noch gar keine aufgezeichnete Ladung, steht an der Stelle weiterhin der alte SoC-Verlauf. Logik in `lib/charge_session.dart`, ohne Flutter-Abhängigkeit und gegen die echten Datenmuster getestet; die Karte selbst hat einen eigenen Widget-Test (u. a. 360-dp-Display — der hat prompt einen 11-px-Überlauf in der Kennzahlen-Zeile gefunden, ist behoben). **`flutter analyze` sauber, 116 Tests grün.** **Noch nicht live** — und das liegt nicht am Code: mein Release-Lauf (#407) wurde um 15:12 von Deinem Push `da375f7` („Fahrzeug hinzufügen — Kern") abgebrochen, und der trägt bewusst kein `release`, also gab es auch keinen Deploy. `analyze` ist auf beiden Ständen grün, meine Tests laufen auch mit Deinem Commit durch. Ich schiebe **nicht** ungefragt einen Release-Commit hinterher, weil damit auch Dein Wizard-Kern auf http://192.168.1.85/ ginge. Sag Bescheid, wenn ich das anstoßen soll — oder nimm es einfach mit Deinem nächsten `release`-Commit mit.

claudecode added

needs-review

and removed

in-progress

labels

2026-09-01 15:15:22 +02:00

Rows
Columns

Page: Laden #3