Rückmeldungen 2.1.8 Release & Release Patch 1

[Yabba]

Alle 3-4 Tage ist der Speicherverbrauch so hoch, das entweder der OOM Killer zuschlägt oder ich es noch so gerade schaffe, über die Maintenance Seite den openwb Service neu zu starten.

Nahezu bei jedem Neustart bekomme ich einen PV Peak von rund 3000kW, der für eine Erzeugung von rund 500kWh sorgt. Soeben auch mit dem Einspielen des Patch 1.

Logs und Screenshots ohne Ende... Keine Fehlerbehebung und es wird einfach ein Release gemacht.



Ich ärgere mich einfach nur noch, nicht bei der 2.1.7 geblieben zu sein.

Michael

Du bist ein Sonderfall, weshalb man kein Release zurückhält, womit Tausende von lang ersehnten Weiterentwicklungen profitieren. Dennoch bleibt dein Problem im Fokus.

zu 2.1.7
Einfach dein Backup einspielen und alles läuft erstmal wieder auf 2.1.7. Wo ist da das Problem?

Das Problem ist dann primär das Ladeprotokoll. Die restliche Statistik ist leider sowieso unbrauchbar.

Wenn ich das Forum überfliege, haben mehrere User solche Peaks bei der PV und auch genauso auch unbedienbare Wallboxen. Von einem Einzelfall zu sprechen, ist etwas gewagt.

Ja, auf einige Änderungen der 2.1.8 habe auch ich gewartet, zum Beispiel die temporären Änderungen während der Ladung. Eigentlich auch auf die Speichersteuerung, welche aber nicht so funktioniert wie erwartet und somit ausgeschaltet werden musste. Für ausführlichere Tests fehlte aufgrund der anderen Probleme leider die Zeit.

Die 2.1.6 hatte bei mir falsche Einträge im Ladelog beschert, die 2.1.7 hatte "nur" das Problem, das Einphasiges PV Laden nicht immer richtig beendet wurde.

Also nicht wundern, wenn ich die openWB aktuell nicht bejubeln kann

[aiole]

Das Forum benutzt nur ein Bruchteil der openWB-user.
Wenn ich "Home Assistant + Modbus Proxy + openwb2mqtt" in deiner sig lese, ist deine Installation - so leid es mir tut - kein Standardfall, den openWB supportet.

Außerdem - wenn man auf 100% Funktion warten würde, ginge nie eine neue Version online. Software ist fast immer ein Kompromiss.

-> Blick weiten.
Wenn z.B. 90% user mit Standardkonfig keine Probleme haben, geht die sw raus. Der Rest wird on the fly gefixt, aber eben ohne andere Aufgaben zu vernachlässigen.

Du kannst nicht erwarten, dass das Team individuelle Probleme mit Eingriff ins Getriebe (MQTT) auf Abruf und ohne Rechnung löst. Das geht wirtschaftlich nicht abzubilden. Es ist immer eine Frage von Aufwand, Kapazitäten und Finanzierung. Bitte habe dafür Verständnis.

[therobbot]

Ob eine Änderung am Ladeprofil auch die aktuelle Ladung beeinflussen soll, ist diskutierenswert. Man war es aus der vorherigen Implementierung her gewohnt. Aber wenn nun Einstellungen in der Konfiguration von den Einstellungen für die aktuelle Ladung getrennt sind, das immer noch die richtige Wahl ist, möchte ich bezweifeln. Für mich sind beide Varianten OK. Aber das man für eine Änderungsübernahme im Ladepunkt einmal abstecken muss ist doof. Inbesondere, wenn man die Konfiguration bei abgestecktem Auto ändert. Dann muss man ja einmal an- dann wieder ab- und dann zum Ladebeginn wieder anstecken. Das halte ich nicht für vermittelbar.

Ich weiß, daß wäre aufwändiger zu implementieren, aber was ich eigentlich erwarten würde ist, dass manuell gemachte temporäre Änderungen nicht direkt überschrieben werden, alles andere aber schon.

Beispiel: Wenn ich im. Frontend auf Sofortladen gestellt habe, dann würde ich erwarten, dass das auch nach Änderungen im Backend so bleibt. Wenn ich aber im Frontend das SoC Limit beim Sofortladen nicht geändert habe, das aber im Backend angepasst habe, würde ich erwarten, dass es auch im Frontend geändert wird.

Ich kann aber auch mit der aktuellen Konfiguration leben. Es hat mich nur verwirrt. Ich bin der Meinung, es war im Master bis vor Kurzem noch anders, kann es aber auch nicht beschwören.

[therobbot]

Bei mir verhält sich die Wallbox mit der Release-Version jetzt total seltsam.

Ich habe im PV-Modus einen Mindest-SOC eingestellt, bis zu dem mit maximaler Anzahl Phasen geladen werden soll.

Jetzt startet die Box diese Ladung immer, schaltet dann aber nach einigen Minuten auf 1 Phase runter (Countdown wird angezeigt), dann lädt sie kurz mit 1 Phase und schaltet dann wieder auf 3 Phasen hoch und das ganze beginn von Neuem. Bis vor Kurzem in den Betas gab es dieses Verhalten noch nicht.

Main-Log: https://paste.openwb.de/ED4ivcPVc6KQtOt
Log des internen Ladepunkts: https://paste.openwb.de/

Braucht es noch was?

Gibt es dazu denn keine Ideen? Ist das nur bei mir so?

[Yabba]

Das Forum benutzt nur ein Bruchteil der openWB-user.
Wenn ich "Home Assistant + Modbus Proxy + openwb2mqtt" in deiner sig lese, ist deine Installation - so leid es mir tut - kein Standardfall, den openWB supportet.

Außerdem - wenn man auf 100% Funktion warten würde, ginge nie eine neue Version online. Software ist fast immer ein Kompromiss.

-> Blick weiten.
Wenn z.B. 90% user mit Standardkonfig keine Probleme haben, geht die sw raus. Der Rest wird on the fly gefixt, aber eben ohne andere Aufgaben zu vernachlässigen.

Du kannst nicht erwarten, dass das Team individuelle Probleme mit Eingriff ins Getriebe (MQTT) auf Abruf und ohne Rechnung löst. Das geht wirtschaftlich nicht abzubilden. Es ist immer eine Frage von Aufwand, Kapazitäten und Finanzierung. Bitte habe dafür Verständnis.

Ins Getriebe greife ich dahingehend ein, dass ich den SOC und die Reichweite beider Fahrzeuge an die openWB übermittle. Weitere Topics zum Schreiben sind nicht konfiguriert.

[blam09]

Ist denn der mit Patch 4 angekündigte Fix überhaupt in dieses Release eingeflossen und kann ich irgendwelche Infos liefern um euch bei der Analyse zu unterstützen ?

Logs sind immer hilfreich und unabdingbar zur Analyse! ( viewtopic.php?t=1526 )

Guten Morgen
ich habe gestern auf den Patch 1 aktualisiert, dies brachte auf den ersten Blick keine Veränderung, der SoC aus dem Fahrzeug wird nicht verwendet.
Heute morgen habe ich daher Loglevel auf Debug gesetzt, die Box heruntergefahren und per Stromunterbrechung neu gestartet.
Sie zeigt den gestern abend manuell veränderten SoC von 17% an und übernimmt nicht den aktuellen SoC von 46-47%

Anbei die Logs meiner openWB pro:
Main: https://paste.openwb.de/nxhSNokmPycHqs4
Int-LP: https://paste.openwb.de/eE2VY5cDdiolF3N
MQTT: https://paste.openwb.de/HMPUvqYqVagm5A9
SoC: https://paste.openwb.de/51Ex6KQ0Rsyca1G

Bin sehr gespannt auf euer Analyseergebnis

VG
B.L.

[BJ Axel]

...die vielen Meldungen zum Strom-Mix sind urplötzlich wieder verschwunden.
Entweder ist ein Puffer voll oder das Problem ist verschwunden.

[Gero]

Ich weiß, daß wäre aufwändiger zu implementieren, aber was ich eigentlich erwarten würde ist, dass manuell gemachte temporäre Änderungen nicht direkt überschrieben werden, alles andere aber schon.

Beispiel: Wenn ich im. Frontend auf Sofortladen gestellt habe, dann würde ich erwarten, dass das auch nach Änderungen im Backend so bleibt.

Das ist eine der wesentlichen Änderungen zu 2.1.8: Wenn im Haupt-UI am Ladepunkt (Du nennst es "Frontend") etwas verändert wird, wird das nicht in die Konfiguration ("Backend") geschrieben. Das ist gut und richtig so. Denn so wird die eigentliche Haupteinstellung am Ladepunkt nur temporär - also für die aktuelle Ladesitzung - überschrieben. Gut im Sommer, wenn man mal eben Strom per Sofortladen ins Auto bekommen muss, aber generell auf PV steht. Dann ist beim nächsten Ladevorgang wieder PV aktiv, ohne dass man dran denken muss, was umzustellen.

Das andere, was hier kritisiert wurde, ist der umgekehrte Weg: Wenn man in der Konfiguration ("Backend") etwas am Ladeprofil verändert, hat das aktuell keine Auswirkungen mehr auf die Einstellung am Ladepunkt ("Frontend"). Das könnte man ändern um das vorherige Verhalten wieder herzustellen. Allerdings hat das die Auswirkung, dass alle Ladepunkte, die auf dem Ladeprofil "Mitarbeiter" stehen bei einer Änderung auf Soforladen darauf umgestellt werden. Das ist im Privatbereich egal, aber bei Ladeparks sicherlich unerwünscht, dass auf einmal alle eingesteckten Autos anfangen zu laden. Ich halte die aktuelle Trennung von Konfiguration und aktuellem Ladevorgang für logisch.

[Mailoh]

Das Forum benutzt nur ein Bruchteil der openWB-user.
Wenn ich "Home Assistant + Modbus Proxy + openwb2mqtt" in deiner sig lese, ist deine Installation - so leid es mir tut - kein Standardfall, den openWB supportet.

Außerdem - wenn man auf 100% Funktion warten würde, ginge nie eine neue Version online. Software ist fast immer ein Kompromiss.

-> Blick weiten.
Wenn z.B. 90% user mit Standardkonfig keine Probleme haben, geht die sw raus. Der Rest wird on the fly gefixt, aber eben ohne andere Aufgaben zu vernachlässigen.

Du kannst nicht erwarten, dass das Team individuelle Probleme mit Eingriff ins Getriebe (MQTT) auf Abruf und ohne Rechnung löst. Das geht wirtschaftlich nicht abzubilden. Es ist immer eine Frage von Aufwand, Kapazitäten und Finanzierung. Bitte habe dafür Verständnis.

So nun muß ich auch einmal die Senftube öffnen, weil hier immer ein Grund gesucht wird, warum es bei bestimmten Usern nicht funktioniert.
Bei mir ist die Box ganz normal angeschlossen, ohne jegliches HA, MQTT, Smarthome oder oder oder.
Die Peaks haben ebenfalls meine Statistik versaut und das für immer, dafür habe ich die openWB immer gelobt, eine bessere Statistik kann bzw. konnte man sich nicht wünschen.
Derzeit kann ich immer nur hoffen, dass die Box sich gerade nicht aufgehängt hat und das ist für mich absolut inakzeptabel.
Ich möchte mein Auto laden, wenn ich es möchte und nicht, wenn die Box dafür eventuell gerade bereit ist, dafür habe ich nicht einen Haufen Geld investiert.
Ich möchte auch einmal behaupten, dass viele Besitzer so gut wie keine Updates machen und alleine deshalb schon nichts von so einem Problem bemerken werden. Die möchten einfach nur ihr Fahrzeug laden, wenn möglich mit Überschuss.
Ich habe an anderer Stelle ordentlich Kritik über openWB gelesen und das immer verteidigt, obwohl ich auch schon vorher immer einmal wieder Probleme hatte, der Support war aber immer vorbildlich und wir konnten alles beheben.
Das erwarte ich jetzt auch!
Vielen Dank...

[Meth]

Ich weiß, daß wäre aufwändiger zu implementieren, aber was ich eigentlich erwarten würde ist, dass manuell gemachte temporäre Änderungen nicht direkt überschrieben werden, alles andere aber schon.

Beispiel: Wenn ich im. Frontend auf Sofortladen gestellt habe, dann würde ich erwarten, dass das auch nach Änderungen im Backend so bleibt.

Das ist eine der wesentlichen Änderungen zu 2.1.8: Wenn im Haupt-UI am Ladepunkt (Du nennst es "Frontend") etwas verändert wird, wird das nicht in die Konfiguration ("Backend") geschrieben. Das ist gut und richtig so. Denn so wird die eigentliche Haupteinstellung am Ladepunkt nur temporär - also für die aktuelle Ladesitzung - überschrieben. Gut im Sommer, wenn man mal eben Strom per Sofortladen ins Auto bekommen muss, aber generell auf PV steht. Dann ist beim nächsten Ladevorgang wieder PV aktiv, ohne dass man dran denken muss, was umzustellen.

Das andere, was hier kritisiert wurde, ist der umgekehrte Weg: Wenn man in der Konfiguration ("Backend") etwas am Ladeprofil verändert, hat das aktuell keine Auswirkungen mehr auf die Einstellung am Ladepunkt ("Frontend"). Das könnte man ändern um das vorherige Verhalten wieder herzustellen. Allerdings hat das die Auswirkung, dass alle Ladepunkte, die auf dem Ladeprofil "Mitarbeiter" stehen bei einer Änderung auf Soforladen darauf umgestellt werden. Das ist im Privatbereich egal, aber bei Ladeparks sicherlich unerwünscht, dass auf einmal alle eingesteckten Autos anfangen zu laden. Ich halte die aktuelle Trennung von Konfiguration und aktuellem Ladevorgang für logisch.

Ich finde das so wie es jetzt ist auch nicht gut .
Da man jetzt von außen nur noch mit Änderungen der bestehenden Funktion über mqtt die lademode verstellen kann bin ich dazu gezwungen täglich wenn ich abends mein Auto anstecke zu prüfen ob auf Ziel Laden steht und nicht wieder PV gezogen wurde und mein Auto dann über Nacht nicht lädt
Es wäre halt jetzt echt toll wenn man den lademodi Zeiten vorgeven könnte .
Oder halt ein topic je ladepubkt das man einfach mit dem gewünschten lademodi beschreibt ...
Ich hoffe auch dass das Topic zum Sperren des ladepunktes noch gibt oder beschreibbar ist denn das ist ein Bestandteil meiner speicherzwangsladesteuerung
Oder ich muss leider wieder auf die Version zurückgehen die das noch nicht implementiert hat was aber sehr schade wäre