Rückmeldungen 2.1.9 Alpha 2/3

[Gero]

Frage: Ist es so gewollt, dass beim Zielladen (andere Lademodi habe ich gerade nicht getestet) Der Ladevorgang so zerstückelt wird?

Bislang war die Philosophie immer: Ladevorgang ist an- bis abstecken. Ich denke, das ist ein Bug.

[rleidner]

Nur mal ein paar Möglichkeiten wie das Problem gelöst bzw. entschärft werden könnte:

Man könnte sich den zuletzt bekannten Ladestand merken statt mit Null zu ersetzen, und wie folgt reagieren:

• wenn bei Ausfall SoC das EV angesteckt war und
  - letzter bekannter EV-SoC über "Mindest-SoC für das Fahrzeug" lag > nicht laden
  - letzter bekannter EV-SoC unter "Mindest-SoC für das Fahrzeug" lag > beschränkte Energiemenge laden
• Trigger "Fahrzeug wird angesteckt" und EV-SoC unbekannt > beschränkte Energiemenge laden

Beschränkte Energiemenge:

• 20 % von Batteriegröße, sofern diese vom Nutzer im Fahrzeugprofil hinterlegt wurde
• wenn Batteriegröße unbekannt, dann 20 % von pauschal 80 kWh
• oder im Fahrzeugprofil Eingabefeld "Max. Lademenge bei unbekanntem EV-SoC" [ ] kWh

Und wenn die Umsetzung der soeben genannten Punkte zu viel Aufwand bedeuten, dann könnte man wenigstens eine Nutzervorgabe ergänzen:
"Reaktion bei unbekanntem EV-SoC > forciert laden erwünscht:" (JA/NEIN)
Falls JA, dann könnte man optional noch ein Eingabefeld spendieren, "Max. forcierte Lademenge" [ ] kWh


Das waren nur mal ein paar Ideen. Gibt sicherlich auch noch andere Lösungswege.
Gruß Hans

Eine Alternative, die m.E. den Zweck erfüllt und relativ einfach zu realisieren sein sollte:
- Wenn ein SoC-Modul den Status nicht erfolgreich lesen kann, wird ersatzweise/Fallback eine Berechnung auf Basis des zuletzt gelesenen bzw. berechneten SoC durchgeführt.
Dazu könnte man in der Konfiguration bei "SoC während der Ladung berechnen" zusätzlich zu Ja/Nein eine 3. Option einführen z.B.: "Fallback"

[Gero]

Die Diskussion über SoC-Modul und Fehlerwert zusätzlich zu dem erfolgreich bestimmten Wert hatten wir schon ein paar-mal. (Auch ich war mal einer der Initiatoren) Das wurde bislang mit dem Grund abgelehnt, dass das zum einen zu kompliziert zu implementieren und zum Anderen zu kompliziert zu vermitteln wäre. Und vor allem, dass der resultierende Schaden sich in Genzen hält. Bei beiden Optionen (Laden oder nichtladen) im Fehlerfall wurde Laden mit höherer Akzeptanz als Nichtladen bewertet. (Was ich auch nachvollziehen kann: Denn besser ein bisschen teuren Strom bezahlt als am nächsten Tag nicht vom Hof zu kommen)

Ich finde den Vorschlag aber gut und würde im Falle von unbekanntem letzten Wert den Fallback genauso wie heute machen. Auf eine dritte Einstelloption würde ich aber verzichten und eine Zeitdauer nehmen, ab der ein in der Vergangenheit gelesener Wert als Fehlerwert interpretiert wird. Ob man den nun einstellbar machen muss, sei mal dahingestellt.

[LutzB]

Einen Fall könnte man noch unterscheiden: Wenn der SoC während einer Ladung nicht mehr abngefragt werden kann.
Oder etwas genauer: beim Anstecken.

Ist das SoC Modul beim Anstecken bereits im Fehlerzustand, muss von 0% ausgegangen werden. Das wäre die aktuelle Logik und wurde schon ausgiebig diskutiert und begründet.

Wenn aber beim Anstecken der SoC erfolgreich ausgelesen werden konnte, wird er sich vermutlich in der nächsten Zeit (ohne Ladung) kaum ändern. Wenn also nach dem Anstecken (mit oder ohne laufende Ladung) das SoC-Modul in den Fehlerstatus wechselt, sollte die Berechnung einspringen, um aktuelle Werte zu bekommen.

Es wäre auch denkbar, dass die Berechnung nach dem Anstecken immer aktiv ist und durch das konfigurierte SoC-Modul nur korrigiert wird. Also quasi wie bei dem manuellen SoC, wenn ich den von Hand eingebe. Das kann ja auch immer wieder zwischendurch erfolgen. Man hätte dann vermutlich im Abfrageintervall von den "Korrekturen" immer kleine Sprünge im SoC, aber aktuell ist es ja auch eine Treppe aus Einzelwerten.

[rleidner]

Ich habe in meinem Testsystem gerade mal eine einfache Version gebaut, die soweit gut funktioniert:

Code: Alles auswählen

 $ git diff configurable_vehicle.py
diff --git a/packages/modules/common/configurable_vehicle.py b/packages/modules/common/configurable_vehicle.py
index e3f608c76..872f043b0 100644
--- a/packages/modules/common/configurable_vehicle.py
+++ b/packages/modules/common/configurable_vehicle.py
@@ -125,7 +125,16 @@ class ConfigurableVehicle(Generic[T_VEHICLE_CONFIG]):
 
     def _get_carstate_by_source(self, vehicle_update_data: VehicleUpdateData, source: SocSource) -> CarState:
         if source == SocSource.API:
-            return self.__component_updater(vehicle_update_data)
+            _carState = self.__component_updater(vehicle_update_data)
+            if _carState:
+                if _carState.soc <= 0 and (self.calculated_soc_state.last_imported or vehicle_update_data.imported):
+                    log.info("_get_carstate_by_source: FALLBACK to calculated soc")
+                    _carState = CarState(soc=calc_soc.calc_soc(
+                                         vehicle_update_data,
+                                         vehicle_update_data.efficiency,
+                                         self.calculated_soc_state.last_imported or vehicle_update_data.imported,
+                                         vehicle_update_data.battery_capacity))
+            return _carState
         elif source == SocSource.CALCULATION:

Wenn das aufgerufene API keinen sinnvollen soc liefert (<=0) wird die Berechnung als Fallback versucht, falls die notwendigen Werte (...imported) definiert sind.
Das benötigt erst mal keine Anwenderkonfiguration. Im SoC-Log wird im Fall des Fallback dann eine Nachricht geschrieben:

Code: Alles auswählen

2025-11-20 13:36:31,497 - {modules.common.configurable_vehicle:132} - {INFO:fetch soc_ev2} - _get_carstate_by_source: FALLBACK to calculated soc

Ich kann das in einen PR packen, falls gewünscht.

[Till]

Hier ein Bild von meiner Mutter hier sieht man genau das ab ca 13:45 kein Hausverbrauch mehr angezeigt wird und ab da hängt die Anzeige .

Ich habe dieses Einfrieren des Hausverbrauchs auch.

Heute Nachmittag war es bei mir wieder so: ab ca. 13.30 Uhr bis 14:40 Uhr wurde kein Hausverbrauch mehr aufgezeichnet. Nach Neustart war es wieder oik.
Anbei mein Main Log: https://paste.openwb.de/rrUOctNOjXQMfSX
und das Bild dazu


Grüße
Till

[Meth]

Hier ein Bild von meiner Mutter hier sieht man genau das ab ca 13:45 kein Hausverbrauch mehr angezeigt wird und ab da hängt die Anzeige .

Ich habe dieses Einfrieren des Hausverbrauchs auch.

Heute Nachmittag war es bei mir wieder so: ab ca. 13.30 Uhr bis 14:40 Uhr wurde kein Hausverbrauch mehr aufgezeichnet. Nach Neustart war es wieder oik.
Anbei mein Main Log: https://paste.openwb.de/rrUOctNOjXQMfSX
und das Bild dazu


Grüße
Till

Bei meiner und bei der meiner Mutter das gleiche auch wieder

Hier das Log meiner Mutter
https://paste.openwb.de/JsLTaBVLr9EOaCd
Und hier das von mir
https://paste.openwb.de/Ahm9w2NtUto4NXA

Und noch 2 bilder die das ggf verdeutlichen .

Bildschirmfoto vom 2025-11-20 17-51-37.png (189.39 KiB) 215 mal betrachtet

Bildschirmfoto vom 2025-11-20 17-52-05.png (190.91 KiB) 215 mal betrachtet

[aiole]

@Till & Meth und nochmal für ALLE:

Wenn hier über Probleme mit screenshots berichtet wird, dann ist dafür entweder das openWB-Standard- oder das openWB-Koala-theme zu verwenden. Das colors-theme ist community-basiert (herzlichen Dank an electron!) und hat einen eigenen thread.

Auch wenn das Problem nicht primär mit dem theme zu tun hat, muss man - zumindest temporär - auf eines der beiden openWB-themes umstellen.

Hintergrund:
OpenWB-Entwickler:innen nutzen vorrangig die 2 genannten openWB-themes und arbeiten sich für ein Steuerungsthema nicht extra in colors ein. Bitte habt dafür Verständnis. Bei Nichtbeachtung wird das zumindest vom openWB-Team meist links liegengelassen.

Ich habe es auch hier nochmal ergänzt (mittlerer Abschnitt):
viewtopic.php?t=1526

[Schmeck]

Ich habe dieses Einfrieren des Hausverbrauchs auch.

Heute Nachmittag war es bei mir wieder so: ab ca. 13.30 Uhr bis 14:40 Uhr wurde kein Hausverbrauch mehr aufgezeichnet. Nach Neustart war es wieder oik.
Anbei mein Main Log: https://paste.openwb.de/rrUOctNOjXQMfSX
und das Bild dazu


Grüße
Till

Bei meiner und bei der meiner Mutter das gleiche auch wieder

Hier das Log meiner Mutter
https://paste.openwb.de/JsLTaBVLr9EOaCd
Und hier das von mir
https://paste.openwb.de/Ahm9w2NtUto4NXA

Und noch 2 bilder die das ggf verdeutlichen .
Bildschirmfoto vom 2025-11-20 17-51-37.png
Bildschirmfoto vom 2025-11-20 17-52-05.png

Ich habe seit ein paar Tagen das gleiche Problem. Heute ist der Hausverbrauch um 13.55Uhr eingefroren. Um 16.26Uhr erfolgte ein Neustart. Alle anderen Graphen sind OK.

Screenshot 2025-11-20 200850.png (102.12 KiB) 157 mal betrachtet

Screenshot 2025-11-20 201023.png (176.82 KiB) 157 mal betrachtet

[kai9555]

Na sowas..bei mir hat sich gestern (19.11.) auch der Hausverbrauch aufgehangen. Heute den gesamten Tag "0" - die Summen werden jedoch scheinbar korrekt gebildet.

https://paste.openwb.de/oCqPG4qkM1bDM47

Version: 2025-11-18 10:36:19 +0100 [6371a6f8f]
Konfigurierte Geräte siehe Signatur.