Rückmeldungen 2.1.8 Beta 2

[LenaK]

Hallo,

nachdem die 2.1.7 keinerlei Peaks in der Auswertung mehr hatte, gibt es jetzt in der 2.1.8 Beta 2 wieder einen (den ersten) Ausrutscher heute gegen 6:40 Uhr:


Screenshot 2025-09-02 215118.png


Screenshot 2025-09-02 215727.png


202509.json: https://paste.openwb.de/kKEUzzy0h1Sx1KV
20250902.json: https://paste.openwb.de/sjZbvzJ5gVJ2Vy0

Ein Log gibt es leider nicht, da ich es eben erst bemerkt habe

Gibt es ein Chance, das Remote zu korrigieren?

Gruß,
Michael

Ich habe eben noch einen Fix dazu gemergt, bitte nochmal ein Update im Master machen.

Hi Lena,

zum Master gewechselt und zack, wieder ein Peak:

Screenshot_20250903_172942_Chrome.jpg

Main.log:
https://paste.openwb.de/IOiG25I9VkaNO6Z

Version: 2025-09-03 15:44:59 +0200 [7334f498f]

bitte nochmal im Mouseover schauen, um wie viel Uhr genau der Peak war. Das Update war um 2025-09-03 16:22:35, im Log habe ich nichts auffälliges entdeckt.

[Gero]

Aha, vereinfachte Darstellung also. Aber warum der Eco-Lademodus bei der vereinfachten Darstellung nicht dabei ist, ist irgendwie unschön. Dass der seltsame "Standby" nicht dabei war, kann ich ja noch verstehen. Aber Eco - nur als Lademodus, ohne die Einstellungen - sollte doch schon sein. Platz ist ja auch noch.

[kai9555]

Sorry für die schlechte Qualität der Fotos beziehungsweise die Reflektionen aber ich musste los. In meinem Display wird der Eco Modus nicht angezeigt.

Wenn Du natürlich die komplexeren Lademodi in den Einstellungen des Displays ausblendet, wird das auch nicht angezeigt.

Danke Lutz das war es! Mir ist es jedoch nicht bewusst, dass ich den vereinfachten Modus jemals angeschaltet hätte. Möglich ist es natürlich. Sollte der einfache Modus jedoch standardmäßig aktiviert sein, sollte dort meiner Meinung nach auch der Eco Modus geführt sein.

[ChristophR]

@Lutz:
Kann das maintenance auch Logfiles schreiben, dann kann ich die auch noch einfangen...

Nein, geht so nicht.

Dein "Absturz" scheint zumindest eigentlich keiner gewesen zu sein. Der openWB Dienst ist kontinuierlich durch gelaufen. Sieht eher so aus, als ob der Mosquitto gesteorben ist und/oder auch andere Prozesse beendet wurden. Also ein klassischer out-of-memory Fall. Nach meinem jetzigen Kenntnisstand ist der Chromium für das Display der Prozess mit dem höchsten Speicherbedarf und der wächst auch kontinuierlich an (besonders der ausgelagerte Speicher). Das Reload des Themes scheint keine großartigen Auswirkungen zu haben, demnach müsste die Ursache im Chromium selber zu finden sein. Mal sehen, ob ein geordneter Neustart in der Nacht machbar ist und Erfolge zeigt.

Hallo Lutz,

ja, die letzten beiden Abstürze waren anders.
Vorher wurden die Diagramme nicht mehr geladen (0% Daten verfügbar), bei den aktuellen wurden die gleichen Werte weiter angezeigt, obwohl sie nicht mehr kamen. Außerdem war wie gesagt selbst der SSH-Login tot, der ging vorher noch.

Ich habe jetzt mal das interne Display auf "Nein" gestellt. Hilft das, damit die Prozesse nicht laufen?

Wenn das Problem hauptsächlich die Auslagerung ist, kann man die auch genauer erkennen?
Meine RAM-Auslastung lieg aktuell ca. bei 60%, 40% Phyton3. Durch das Ausschalten des Displays hat sich daran nichts geändert.

[LutzB]

Das muss manuell aktiviert werden, ist nicht der Standard.

[LenaK]

Ladeprotokoll Fehler beim Zeitstempel Ende PV-Laden (03.09.2025 von 10:05 - 12:33)
Mir ist aufgefallen dass in der Tabelle unter Menü Auswertungen > Ladeprotokoll eine falsche Endezeit eingetragen ist (sowie auch in den CSV-Daten).
In meinem Fall wurde als Endezeit der 04.09. - 7:11 Uhr eingetragen.
Dieser Fehler ist bei mir mit einer älteren 2.x Version auch schon vor Monaten aufgetreten.
Meiner Vermutung nach liegt die Fehlerursache darin, dass der Ladevorgang vom Fahrzeug und nicht von der OpenWB beendet wurde.

Seit V2.1.8 gibt es laut eurer Beschreibung einen Trigger (SoC-Abfrage nach Ladestop), im übrigen eine sehr gute Optimierung, diese hat bei mir auch funktioniert als der Ladevorgang bei 80% durch das Fahrzeug beendet wurde.

Abhilfe zum Problem: Man könnte optional den gleichen Trigger zum Erfassen des Ende-Zeitstempels im Ladeprotokoll verwenden.


Screenshot 1 Ladeprotokoll Fehler Endezeit 03.09.25 - 12.33.png
:

Screenshot 2 PV-Laden 03.09.25 von 10.05 - 12.33.png
:

Ist für 2.1.9 geplant.

[LenaK]

Sofortladen morgens 04.09.2025 ab 7:00 Fehler beim Ladestart
Am 04.09. hatte ich eine längere Fahrt vor mir, so dass ich mittels Sofortladen auf 100% laden wollte.
Anmerkung: Tags davor hatte ich per PV-Laden bis 80% geladen, dieser 3-phasige Ladevorgang wurde vom Fahrzeug bei 80% gestoppt.
Am 04.09.25 morgens VW-APP Fahrzeug Max.SOC auf 100% freigegeben.
Dann OpenWB Weboberfläche von PV auf Sofortladen gestellt (Einstellungen 3-phasig mit 16 A).

Das Sofortladen wurde danach erst im 3. Versuch korrekt 3-phasig gestartet.
1. Ladestart: VW-APP BEV-SOC auf 100% gestellt, Ladestart 1-phasig, Ladevorgang wurde unmittelbar wieder beendet
2. Ladestart: Zirka 1 min später erneuter Start Ladevorgang, wieder 1-phasig.., wurde nach einer weiteren Minute wieder beendet
(vmtl. wegen der unter "Fahrzeug-Profile > Mindestzeit zwischen Umschaltungen" > bei mir 60 s)
3. Ladestart: Im dritten Versuch Start Ladevorgang 3-phasig OK

Warum startete der Ladevorgang 1-phasig (sogar 2x) und nicht im 1. Versuch korrekt 3-phasig so wie in den Einstellungen hinterlegt?

Vgl. Screenshots und MainLog 7:07 - 7:14

Screenshot 1 Sofortladen niO 2025-09-04.png
:
Main Log 2025-09-04_7.07-7.14 Uhr.txt
:

Anmerkung 1: Die Ladung wurde bei 100% durch das Fahrzeug gestoppt;
Ab ca. 95% wurde die Ladung mit geringerer Leistung (Laut OpenWB Anzeige nur noch 2-phasig mit 16 A) ausgeführt, das habe ich zum ersten Mal beobachtet. Vmtl. ausgelöst vom Fahrzeug, nachdem ich den ID.3 vor zwei Wochen auf V3.8 aktualisierte - nur als Randnotiz, kein Fehler


Screenshot 2 Sofortladen ok 2-phasig 16A ab 95%.png
:

Das liegt an der "Mindestzeit zwischen Umschaltungen", wenn nach der hier eingestellten Zeit nicht mit der vorgegebenen Phasenzahl geladen wird und unter Übergreifendes-> Phasenumschaltung wiederholt anstoßen aktiviert ist, wird nochmal eine Umschaltung gemacht, falls es beim ersten Mla nicht geklappt hat. Entweder Du beobachtest, wie lande dein Auto braucht, bis es wirklich lädt und passt die "Mindestzeit zwischen Umschaltungen", an oder du deaktivierst die Wiederholung der Umschaltung.

[Meth]

Hallo owb Team ,

ich glaube das Huawei Emma Modul ist nicht ganz Richtig .
Es zeigt zwar die PV Leistung richtig an .
Aber in der Summe zeigt es einen wert an der um den Faktor 1000 nicht Stimmt .
Es müssten in etwa 40 Kw ertrag heute sein

Huawei Emma.jpg

(168.32 KiB) Noch nie heruntergeladen

Hier das Log , was aber nichts mit dem Scale Faktor zu tun hat
https://paste.openwb.de/iWbG0URiIcT2XI2

[LenaK]

Da scheint der dreiphasige Ladestart bei ausreichend Sonnenschein kaputt gegangen zu sein, oder er rechnet bei einer 22kW-Box zu vorsichtig. Ladestart war einphasig, kurz danach wurde umgeschaltet:

https://paste.openwb.de/bVONzJC2dKNsVQE

Das Log lädt nicht. Ich habe den dreiphasigen Ladestart bei ausreichend Überschuss probiert, bei mir funktioniert es.

[LenaK]

SOC Modul "manuelle Berechnung" bei Fahrzeugwechsel fehlerhaft.

ich habe folgendes verhalten, wenn ich Fahrzeug A lade und dann auf Fahrzeug B wechsle wird zu beginn der letzte SOC vom Fahrzeug B richtig übernommen, aber beim 1 durchlauf werden die letzten geladenen kwh vom Fahrzeug A zum aktuellen ladenden Fahrzeug B dem SOC Wert dazugerechnet. Beide Fahrzeuge haben das manuelle SOC Modul und tritt nur auf wo beide Fahrzeuge am gleichen Tag geladen werden.

Hast Du das Fahrzeug zwischendurch abgesteckt? es funktioniert nur, wenn zwischendurch abgesteckt wird, weil auch der manuelle SoC einem physischen Fahrzeug entspricht.
Wenn ja, brauche ich bitte einen Auszug vom soc-Log im Level Details, wo der SoC von Fahrzeug A und B drin ist.