Daten senden
nicht nur beim Verbinden wird ein Datensatz an den Server gesendet sondern auch wenn die Verbindung getrennt wird.

Julian Binder 30 days ago
Feature Requests
Daten senden
nicht nur beim Verbinden wird ein Datensatz an den Server gesendet sondern auch wenn die Verbindung getrennt wird.

Julian Binder 30 days ago
Feature Requests
Fehlende Datensätze
Vom Tablet aus der fertigung liegt der neueste Datensatz vom 25.06. vor….seither kommen anscheinend keine mehr rein.

An Anonymous User about 1 month ago
Bug Reports
Fehlende Datensätze
Vom Tablet aus der fertigung liegt der neueste Datensatz vom 25.06. vor….seither kommen anscheinend keine mehr rein.

An Anonymous User about 1 month ago
Bug Reports
Cellcount manchmal falsch
Unter Lifecycle/SOH Analysis sieht man manchmal für Cell count 2 (bei 12 V) oder 13 (bei 48 V) eingetragen.

Roman Kempf about 1 month ago
Bug Reports
Cellcount manchmal falsch
Unter Lifecycle/SOH Analysis sieht man manchmal für Cell count 2 (bei 12 V) oder 13 (bei 48 V) eingetragen.

Roman Kempf about 1 month ago
Bug Reports
CAN-IDs
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.

Roman Kempf about 1 month ago
Bug Reports
CAN-IDs
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.

Roman Kempf about 1 month ago
Bug Reports
Completed
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).

Felix 2 months ago
Feature Requests
Completed
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).

Felix 2 months ago
Feature Requests