Rückmeldungen 2.1.8 Release Candidate 1&2

[ChristophR]

Im aktuellen Master haben wir auf der "Maintenance" Seite einen Info-Button bei den Prozessen ergänzt.

Bei mir ist es der:
python3 /var/www/html/openWB/packages/main.py

Bei mir auch.

Ich hatte das Loglevel bei mir immer auf Details.
Habe das jetzt mal auf Warning and Error gestellt.
In den letzten 3 Stunden ist der Prozess nun nur um 0,2% gestiegen, sonst waren das immer schon 2-3% in der Zeit.

P.S: Kurz nachdem ich dies geschrieben habe, ist der Speicherverbrauch um weitere 0,4% gestiegen, also insgesamt von 6,8% beim Start auf 7,4%.
Jetzt, nach ca. 9 Stunden Betriebszeit liegt er immer noch bei 7,4%, sonst war er nach der Zeit meist schon bei 15-18%.
Es scheint also wirklich am Detail Logging zu liegen.

[LutzB]

Da der Bug noch nicht gemeldet wurde:
Auf dem integrierten Display kann man bei einem Fahrzeug die Pläne unter Zielladen nicht mehr durch Tippen aktivieren oder deaktiveren. (Theme: Cards) Stattdessen muss man es separat über den PC oder via Smartphone machen.

Danke für die Rückmeldung. Ist mit Merge des PR im Master Branch behoben.
https://github.com/openWB/core/pull/2764

[JOGRA]

Dein Auto scheint Phasen weg zu schalten, wenn es die Ladung beendet. Deshalb wird fälschlicherweise von einem zweiphasigen Fahrzeug ausgegangen. Beim Abstecken wird direkt die Ladung beendet ohne Phasen wegzuschalten, deshalb tritt das Problem da nicht auf.
ist behoben und wird in 2.1.9 gemergt.

Mal eine Verständnisfrage dazu: wir haben ein 2-phasiges und ein 3-phasiges Auto und mir ist auch vereinzelt mal aufgefallen, dass beim 3-phasigen die Ladestromvorgaben so waren, als wäre er zweiphasig.

Aber nach meinem Verständnis von Regelungsalgorithmen müsste der Strom dann doch trotzdem runterregeln, wenn der Soll ständig vom Ist abweicht. Normalerweise würde ich davon ausgehen, dass da irgendwie so was wie ein PID-Regler implementiert ist und die aus den Phasen berechnete Vorgabe nur bei schnellen Änderungen des Überschusses verwendet wird. Dann sollte die Regelung doch eigentlich nur kurz überschießen und sich dann trotzdem einregeln. Dass stattdessen die ganze Zeit mit falscher Vorgabe geladen wird, finde ich ungewöhnlich.

Unabhängig davon verstehe ich auch nicht, warum als Phasenzahl nicht einfach die aktuell vom EV angeforderten Phasen genommen werden. Die werden bei uns immer korrekt angezeigt.

Wenn die Basis (Anzahl Phasen) nicht korrekt ist, dann kann die beste Regelung das Problem nicht lösen.

Es scheint ja so zu sein ..., dass die PV-Leistung (nach Abzug aller sonstigen bekannten Verbraucher) = "verfügbare Ladeleistung", durch die Anzahl Phasen geteilt wird, die voraussichtlich vom Fahrzeug abgenommen werden. Anschließend wird als Sollwert für jede dieser Phasen der zu verabreichende Strom berechnet.

Beispiel:
verfügb. Ladeleistung = 6 kW
Anz. Phasen = 2
Sollwert = 6/2 = 3 kW je Phase

Die OpenWB kann mittels der eigenen Umschalttechnologie (Schütz) nur 1- oder 3-phasig, d.h. bei mehr als einer Phase wird der Sollwert immer auf allen drei Phasen ausgegeben (nach meinem Verständnis). Werden jetzt fälschlicherweise vom Fahrzeug drei statt der mitgeteilten zwei Phasen abgenommen, kommt es genau zu diesem Problem. Um beim obigen Beispiel zu bleiben werden dann 3 x 3 kW = 9 kW vom Fahrzeug abgenommen.

Wird die Wallbox von "Automatik" auf "Maximal" umgeschaltet, wird korrekt geregelt (so bei mir), weil scheinbar davon ausgegangen wird, dass jetzt auch alle drei Phasen abgenommen werden (6 kW / 3 Ph. = 2 kW Sollwert je Phase).
Wird wieder zurück geschaltet auf "Automatik", wird wieder falsch geregelt. Ist natürlich Unsinn, wenn im Modus "Maximal" die Basis Phasen = 3 gilt, und bei "Automatik" als Basis Phasen der zuletzt ermittelte Wert vom Fahrzeug.

Was fehlt? Eine Kontrollinstanz die prüft, ob die Summe der fließenden IST-Ströme aller Phasen und die daraus resultierende Gesamtladeleistung unterhalb der "verfügbaren Ladeleistung" liegt (9 kW < 6 kW). Ist diese Bedingung nicht erfüllt, muss bei mehrphasigem Laden die Anzahl der Phasen neu ermittelt werden (z.B. erneut vom Fahrzeug anfordern).
Alternativ bei mehrphasigem Laden die eigenen Ist-Ströme je Phase auswerten, Strom > 1 A bedeutet Phase aktiv, unabhängig von dem was vormals vom Fahrzeug gemeldet wurde.

Aber: LenaK hat ja bereits mitgeteilt, dass zu dem Thema für V2.1.9 bereits eine Verbesserung implementiert wurde, die das Problem lösen soll - vielen Dank dafür.


Ich hänge aber nochmals den Screenshot ran, weil ich darauf nochmals Bezug nehmen möchte:

Anzeige Phasen - Rechte Bildhälfte:
Es wurde zwar angenommen, dass nur mit 2 Phasen geladen werden kann, aber gemäß Anzeige (3) unterhalb des Graphen ist scheinbar längst bekannt, dass mit 3 Phasen geladen wird (roter Pfeil). Warum bei mehrphasigem Laden nicht diese Tatsache als Basis für die Regelung / Ermittlung des Sollwerts verwenden?

Außerdem, allgemeines Thema (was schon immer gestört hat):
Warum wird die Anzeige für Ladeleistung und -strom unterhalb des Graphen nicht synchron ermittelt und plausibel angezeigt?
Kann doch nicht sein, dass da steht: 0 kW / 16 A (linke Bildhälfte) oder 8,08 kW / 16 A (re. Bildhälfte) > WIDERSPRUCH!
Die Anzeige der Leistung ist jeweils korrekt, die des Stromes jeweils fehlerhaft, bitte bei Gelegenheit korrigieren!

Außerdem noch ein Schönheitsfehler:
Linke Bildhälfte zeigt die Situation um 14:01 Uhr, da steht "Ladevorgang wird gestartet ..." > ist falsch weil EV-SoC bei 80% steht (vom Fahrzeug 15 min zuvor beendet) und kein Ladevorgang möglich ist und auch keiner gestartet wird. Hier sollte natürlich ein anderer Meldetext ausgegeben werden.
Und noch eine Frage an dieser Stelle: könnte man vor dem Meldetext nicht pauschal einen Zeitstempel in Form von hh:mm:ss setzen?

2025-09-15a Anzeige Leistung, Strom, Anz. Phasen.png (96.51 KiB) 373 mal betrachtet

[Gero]

Es scheint also wirklich am Detail Logging zu liegen.

Ich stelle nun auch mal auf "Info", bei mir stand's auch auf Details. Der main.py hat bei mir gerade 20,2%

[therobbot]

Wenn die Basis (Anzahl Phasen) nicht korrekt ist, dann kann die beste Regelung das Problem nicht lösen.

Also zunächst mal: natürlich ist es ein Bug, wenn die Software nicht mit der korrekten Phasen Zahl rechnet und der sollte gefixt werden. Deine Aussage sehe ich aber unabhängig davon anders und ich habe in dem Bereich Regelungstechnik durchaus ein bisschen Erfahrung, auch wenn diese schon einige Zeit her ist und ich eher periphär damit zu tun hatte.

Der Sollwert sollte bei der Regelung sein, dass die Differenz von Ladeleistung und Überschuss 0 ist. Das ist erst einmal unabhängig von der Phasenzahl. Grundsätzlich würde ein Regler jetzt nach gewissen Regeln einfach so lange an der Stromvorgabe schrauben, bis der Zielwert erreicht ist und zwar immer weniger stark, je näher man am Zielwert ist. Solange man mit der Stromvorgabe dabei nicht an die "Ränder" kommt, muss er dafür nicht wissen, mit wie vielen Phasen Geraer geladen wird. Natürlich ist es in Wahrheit komplexer, weil sich Erzeugung und Überschuss ja ständig ändern, weswegen man normalerweise einen PID Regler mit geeigneten Parametern definieren würde. Wenn sich die Verhältnisse sehr plötzlich ändern, kann es zusätzlich sinnvoll sein, direkt zu berechnen, wo man gut hinspringen kann. Das ist die Stelle, wo man die Info über die Phasen braucht. Aber ich hätte eben erwartet, dass das nur passiert, wenn plötzlich starke Abweichungen von der Zielvorgabe auftreten. Solange die Verhältnisse recht konstant sind, hätte ich erwartet, dass der Regler sich unabhängig davon einschwingt.

[openWB]

Solange die Verhältnisse recht konstant sind, hätte ich erwartet, dass der Regler sich unabhängig davon einschwingt.

Wenn Fahrzeuge hast die sich alle immer gleich und gut verhalten bin ich bei dir.
Die Realität sieht leider vollkommen anders aus und führt dazu das eine so einfache Regelung, erst recht wenn mehr als ein Fahrzeug geladen wird, leider nicht ausreicht.
Daher die Phasenzahl, erlaubte Abweichung , usw...

Frühe 1.9er hatten das so gemacht. Mit gut folgenden Autos hat das auch super funktioniert. Leider ist das nicht die Regel.

[therobbot]

Solange die Verhältnisse recht konstant sind, hätte ich erwartet, dass der Regler sich unabhängig davon einschwingt.

Wenn Fahrzeuge hast die sich alle immer gleich und gut verhalten bin ich bei dir.
Die Realität sieht leider vollkommen anders aus und führt dazu das eine so einfache Regelung, erst recht wenn mehr als ein Fahrzeug geladen wird, leider nicht ausreicht.
Daher die Phasenzahl, erlaubte Abweichung , usw...

Frühe 1.9er hatten das so gemacht. Mit gut folgenden Autos hat das auch super funktioniert. Leider ist das nicht die Regel.

Danke für die Erklärung. Das kann ich nachvollziehen.

[mattberlin]

Die Kiste hängt sich leider immer noch auf:
- Ping geht noch
- Web-Interface: Der Balken beginnt auch nach Minuten nicht das Laufen
- auch http://deine-openwb/openWB/web/maintena ... minfo.html wird nicht geladen:
image_2025-09-15_101930788.png

Es verbleibt nur der harte Reset.

Es passierte schon wieder.

[wetty]

Hab bei mir 6A minimalen Dauerstrom eingestellt, damit die Ladung heute früh nicht ständig mangels Sonne unterbrochen wird.
Nun kommt genug PV Überschuss zusammen, das die Box auch auf 3 Phasen wechseln könnte.
Das macht sie aber nicht.
Nun die Frage warum der minimale Dauerstrom das Umschalten auf 3 Phasen verhindert. Wenn ich den Minimalen Dauerstrom raus nehm, dann erfolgt auch zeitnah die Umschaltung auf drei Phasen. Laut Screenshoot werden 1,9 KW in meinen Hausakku geladen. Das sollte eigentlich reichen um auch mit 3 Phasen zu laden. Aktuell ist das Auto priorisiert.


Hier meine Logs. Main und Ladepunkt
https://paste.openwb.de/7jNmA0fNuyooAO9

https://paste.openwb.de/xvGVIeKogeRBJbf

[wetty]

Schieb gleich ein Frage bezüglich des minimalen Dauerstroms hinterher.
In früheren Versionen z.B. 2.1.7 hab ich von extern per MQTT den minimalen Dauerstrom gesetzt.

Mit der 2.1.8 wurden ja einige MQTT Topics geändert. Aber wenn ich probieren nur den minimalen Dauerstrom in dem chargeTemplate zu setzen klappt das nicht.
Topic:
openWB/set/chargepoint/3/set/charge_template

Es scheint das man auf das Topic das komplette chargeTemplate Object schicken muss, nur um z.B. den minimalen Dauerstrom zu ändern.

Gibts da eine einfache Möglichkeit den minimalen Dauerstrom per MQTT zu setzen?