Rückmeldungen 2.1.9 Alpha 2/3

[aiole]

Problem: der EV-SoC = 0 entspricht nicht der Realität und hätte unter keinen Umständen verwendet werden dürfen. Einen Ladevorgang zu starten auf Basis eines fehlerhaft ermittelten Wertes ist nicht wirklich sinnvoll.
Wäre nicht besser sich den letzten EV-SoC immer solange zu merken, bis ein neuer SoC durch fehlerfreie Kommunikation ermittelt wird?
Ggf. im Infofeld Textausgabe "Kommunkationsfehler, EV-SoC unbekannt .."

Wenn der SoC ausfällt, ist die Strategie "EV laden" die einzig sichere Methode, um vor zu geringem Akku bewahrt zu werden.

[openWB]

Ggf. im Infofeld Textausgabe "Kommunkationsfehler, EV-SoC unbekannt .."

Würde voraussetzen man schaut immer nach ob auch geladen wird.
Daher ist die Strategie im fehlerfall lieber das Laden forcieren als mit leerem Akku da zu stehen.

[Thrillhouse]

Hallo zusammen ich habe eine Frage etwas Off topic. Wird es irgendwann möglich sein, den Hausspeicher mit Netzstrom zu laden, gesteuert über die Open WB? Ich besitze den Kostal Plenticore Gen1 und der könnte theoretisch über Modbus den Befehl ausführen. Hoffe ihr könnt mir folgen.

[openWB]

Hallo zusammen ich habe eine Frage etwas Off topic. Wird es irgendwann möglich sein, den Hausspeicher mit Netzstrom zu laden, gesteuert über die Open WB? Ich besitze den Kostal Plenticore Gen1 und der könnte theoretisch über Modbus den Befehl ausführen. Hoffe ihr könnt mir folgen.

viewtopic.php?t=10763&start=60

[ChristophR]

Aktueller master (2025-11-18 10:36:19 +0100 [6371a6f8f])
Zielladen bei 2 Zielen mit gleichem Zeitpunkt.
Nun wird zwar nicht mehr zufällig eines der beiden Ziele genutzt, je nachdem in welcher Reihenfolge sie aktiviert wurden, aber es wird das falsche Ziel mit dem geringeren SoC gewählt.

[Meth]

Hallo zusammen ,

ich habe seit einer Woche wieder Hänger in der openWB
Ich habe nur MQTT Module die alle fleißig senden und auch im Broker ankommen aber irgendwie hängt die Ansicht .
Hier ein Bild (zwar Colour Theme) aber man sieht was ich meine .

Screenshot 2025-11-19 161235.png

(296.92 KiB) Noch nie heruntergeladen

Screenshot 2025-11-19 161252.png

(238.94 KiB) Noch nie heruntergeladen

Hier noch die Logs .
Main
https://paste.openwb.de/zF6MXFz74VqbxIl
mqtt
https://paste.openwb.de/vEb84Oggfn5jeuD
Thread Errors ist leer .

Die openWB läuft auf einer VM das zur Info

Bei miener Mutter ist ähnlich immer so ca 13:30 bleibt das system hängen .

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 .

Bildschirmfoto vom 2025-11-19 17-13-08.png (225.46 KiB) 134 mal betrachtet

Log habe ich leider keins da ich neustarten musste .


Mein Bruder hat keine MQTT Module .
Da passiert das nicht .
Das mal als Anhaltspunkt .

[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.

[JOGRA]

Problem: der EV-SoC = 0 entspricht nicht der Realität und hätte unter keinen Umständen verwendet werden dürfen. Einen Ladevorgang zu starten auf Basis eines fehlerhaft ermittelten Wertes ist nicht wirklich sinnvoll.
Wäre nicht besser sich den letzten EV-SoC immer solange zu merken, bis ein neuer SoC durch fehlerfreie Kommunikation ermittelt wird?
Ggf. im Infofeld Textausgabe "Kommunkationsfehler, EV-SoC unbekannt .."

Wenn der SoC ausfällt, ist die Strategie "EV laden" die einzig sichere Methode, um vor zu geringem Akku bewahrt zu werden.

Ggf. im Infofeld Textausgabe "Kommunkationsfehler, EV-SoC unbekannt .."

Würde voraussetzen man schaut immer nach ob auch geladen wird.
Daher ist die Strategie im fehlerfall lieber das Laden forcieren als mit leerem Akku da zu stehen.

Hallo aiole und openWB

Ich kann eure Argumentation verstehen.
Trotzdem ist die Reaktion des pauschal forcierten Ladens bei unsicherem Ladestand nicht optimal umgesetzt.

Es ist anzunehmen, dass bei den meisten Nutzern die Schwelle "Mindest-SoC für das Fahrzeug" auf 20 % eingestellt ist.
D.h. der Nutzer wünscht im PV-Modus forciertes Laden nur bis 20 % und danach ein Ende des Ladevorgangs.
Aktuell wird bei unsicherem EV-SoC der letzte bekannte SoC verworfen und durch Null ersetzt.
Als Folge davon wird forciert geladen, im Zweifelsfall bis 100 %, wenn das Auto nicht bei 80 % stoppt.


Maßnahme: Für mich habe ich das Problem insoweit entschärft, indem ich den "Mindest-SoC für das Fahrzeug" auf 0 % (AUS) gestellt habe.
Damit wird das Forcieren der Ladung ausgehebelt, was natürlich nicht Sinn der Sache ist.


Nachfolgend nochmals ein Bild von heute:
Wir sehen, dass kurz nach dem Start PV-Überschussladen der EV-SoC wieder einmal auf 0 % geht.
Auf Grund meiner oben genannten Maßnahme wird kein forciertes Laden gestartet, sondern weiterhin Überschuss geladen (schön oder?).
Was wäre passiert, hätte ich die Maßnahme nicht ergriffen?
Das Fahrzeug hätte ab 11:49 Uhr bis zur Rückkehr des EV-SoC (~14:30 Uhr) bis auf weiteres mit 11 kW geladen.

2025-11-19 Komm.fehler VW-Server SoC=0 .. startet PV-Laden.png (155.88 KiB) 87 mal betrachtet

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

[aiole]

Hallo Hans,
Danke für deine Vorschläge.

Ich persönlich denke, dass dies viele user überfordern würde. Generell sollten use cases in der aktuellen sw2 mit den vorhandenen oder sogar reduzierten Eingaben realisiert werden, da schon jetztige Eingaben etliche Leute an die Grenzen bringt. Die meisten wollen keine "Einstellungs-Orgie" durchmachen.

Des Weiteren forciere ich den Ansatz der Ursachenbehebung. Wenn nämlich der SoC nur sporadisch oder selten ausfällt, ist eine Sicherheitsvollladung (gern im Auto auf xx% begrenzt) m.E. akzeptabel.

Besser wären daher Mitentwickler, die die SoC-Module vermehrt pflegen.

[kai9555]

Die Ladekosten werden im Master nun wieder richtig berechnet. Vielen Dank für die Rückmeldungen.

Frage: Ist es so gewollt, dass beim Zielladen (andere Lademodi habe ich gerade nicht getestet) Der Ladevorgang so zerstückelt wird? Angesteckt habe ich am 18.11. Mittag und Zielladen war auf 19.11. 07 Uhr eingestellt. Fahrzeug wurde erst nach erreichen abgesteckt. Im Ladelog habe ich dann 5 Ladungen zu diesem "einzelnen" Ladevorgang. Die Aufteilung entspricht den 15min Blöcken vom Tibber Strompreis.

Feature oder Bug? Ich muss mir zumindest die Tabelle ziehen und die Summe bilden, um die Kosten für den Ladevorgang zu errechnen.