LBX-26: Datensatz auch beim Trennen der Verbindung senden
nicht nur beim Verbinden wird ein Datensatz an den Server gesendet sondern auch wenn die Verbindung getrennt wird.
LBX-25: Fehlende Datensätze — Ingestion vom Fertigungs-Tablet seit 25.06. gestoppt
Vom Tablet aus der fertigung liegt der neueste Datensatz vom 25.06. vor….seither kommen anscheinend keine mehr rein.
LBX-22: Cell Count in Lifecycle/SoH Analysis manchmal falsch
Unter Lifecycle/SOH Analysis sieht man manchmal für Cell count 2 (bei 12 V) oder 13 (bei 48 V) eingetragen.
LBX-21: CAN Send ID3/4 bei 12V-Akkus angezeigt (existieren nur bei 48V)
12V Akkus haben nur 3 CAN IDs (1 receive, 2 send). Im Dashboard und im exportierten Datensatz werden aber immer send ID 3&4 mit angezeigt, obwohl diese nur bei 48V Varianten existieren.
LBX-3: ErrorResolutionDialog: KS-Status live aktualisieren während Dialog offen ist
**Gemeldet von Valentin via Chat, 2026-05-05 (Motorsport-CAN-Test-Workflow)** Vale macht CAN-Tests an Motorsportakkus über einen Stecker + ein Modul am PC. Er prüft in der App live, ob die Funktionen ankommen, die er am PC eingibt — speziell ob der Killswitch (KS) aktiv ist oder nicht. Aktuell muss er den Error-Dialog jedes Mal schließen und wieder öffnen, um die Statusänderung zu sehen. **Felix hat in der Chat-Antwort schon zugesagt:** „Das ist möglich und kann ich so mit aufnehmen für die nächste Version". **Root Cause (verified auf github/dev @53b42db):** `lib/features/device_page/components/error_resolution_dialog.dart:290-305` — die `build()`-Methode nutzt zwar `BlocBuilder `, aber die `buildWhen`-Predicate triggert NUR auf `hasChargeOverrideAvailable` Änderungen: ```dart return BlocBuilder ( buildWhen: (previous, current) { return previous.currentSessionData?.hasChargeOverrideAvailable != current.currentSessionData?.hasChargeOverrideAvailable; }, builder: (context, state) { final currentGuide = _getCurrentGuide(state.currentSessionData); ... } ); ``` KS-State-Änderungen (`isKillswitchActive`, `powerSwitchReasonInt`, `isAntiTheftActive`, `hasResettableError`) sind nicht in der buildWhen-Predicate enthalten — der Dialog rebuildet also nicht, wenn sich der KS-Status während Vale's CAN-Test ändert. Er zeigt weiterhin den Snapshot der bei Dialog-Öffnung gerendert wurde. Der StreamSubscription in `_subscribeToSessionChanges()` (Z.96) hört zwar auf SessionBloc-Updates, aber NUR um nach Aktionen wie „Reset Error" das Dialog automatisch zu schließen — er triggert keinen Rebuild der UI. **Fix-Plan (klein, ~5 Zeilen):** Die `buildWhen`-Predicate erweitern auf alle Felder die `_getCurrentGuide()` und die UI verwenden: ```dart buildWhen: (previous, current) { final p = previous.currentSessionData; final c = current.currentSessionData; return p?.hasChargeOverrideAvailable != c?.hasChargeOverrideAvailable || p?.powerSwitchReasonInt?.value != c?.powerSwitchReasonInt?.value || p?.isKillswitchActive != c?.isKillswitchActive || p?.isAntiTheftActive != c?.isAntiTheftActive || p?.hasResettableError != c?.hasResettableError; }, ``` Alternative: `buildWhen` ganz entfernen (rebuildet bei jedem State-Tick). Für einen modalen Dialog ist das performance-mäßig unkritisch und robuster gegen zukünftig hinzukommende UI-Felder. **Wert:** Vale's Motorsport-CAN-Test-Workflow wird signifikant produktiver (kein ständiges Schließen + Öffnen mehr). Allgemein nützlich für jeden der die Wirkung eines Reset-/Override-Buttons live sehen will. Screenshots im Chat 2026-05-05 (Slack).