1/3 Phasenumschaltung bei 11 kW Begrenzung oft unbrauchbar

[gpr]

Hallo,

ich nutze eine Series2 mit 1.9.249 (2021-10-22) auf 11 kW begrenzt mit einem Model 3.
Die Steuerung der 1/3 Phasenumschaltung ist aus meiner Sicht sehr unglücklich gelöst. Bei einer verfügbaren PV-Leistung zwischen 3,6 kW und 4,3 kW wechselt die Steuerung alle 16 Minuten auf 3 Phasen und zurück auf eine Phase. Diese freie Leistung liegt bei mir zu bestimmten Jahreszeiten oft für einen langen Zeitraum vor, so dass ich die automatische Umschaltung nicht guten Gewissens nutzen kann.
Der Grund liegt darin, dass die Umschaltung ohne jede Prüfung ob sinnvoll erfolgt, sondern einfach nach x Minuten Maximal-/Minimalstrom. Das passiert entweder ab 3,6 kW (16 A) bei einer Phase oder bis 4,3 kW (6 A) bei drei Phasen. Die Steuerung ist offensichtlich für nicht auf 16 A begrenzte Anlagen gebaut, die keine Lücke sondern eine Überlappung haben und mit einer Phase 4,6 kW laden können.
Aus der Community hat gvzdus netterweise einen PR gestellt der genau dieses und andere Probleme behebt: https://github.com/snaptec/openWB/pull/1635
viewtopic.php?f=9&t=4063

Ich finde es sehr schade dass von openwb darauf überhaupt nicht reagiert wurde. Es dürfte eine ganze Reihe Nutzer geben die das durchaus teure Feature so kaum nutzen können.

[Andi]

Mir geht es auch so und ich kann diesen Wunsch nur zu sehr verstehen. Jetzt kommt dann bald wieder die Zeit wo man sich über diesen nicht übernommen Fix wieder ärgern wird. Wäre echt schön wenn es noch kommt, die 2.0 Release zieht sich gefühlt noch zu lang...

[Becker]

Das Problem hatte ein Nutzer hier im Forum schon längst gelöst, schade dass solche Entwicklungen vom openWB Team ignoriert werden, und es nicht in die offizielle Version schaffen.

[grothauu]

Ich kann das Gesagte nur unterstützen. Dadurch wird die Phasenumschaltung für viele Nutzer bei wolkigem Wetter unbrauchbar. Dabei liegt die Lösung auf der Hand. Es handelt sich hier um einen gravierenden Softwarefehler.

[aiole]

.... Es handelt sich hier um einen gravierenden Softwarefehler.

Also Fehler heißt bei mir - geht nicht
gravierender Fehler - feature nicht existent

Beides ist hier nicht gegeben und Verbesserungen werden sicher noch kommen. Der Support wird Gründe haben.

[therobbot]

Undurchdachter Hack trifft es vielleicht besser als gravierender Fehler. Warum ein PR, der deutlich durchdachter scheint, nicht übernommen wird, ist trotzdem schwer nachvollziehbar und wenn es Gründe gibt, könnten die ja zumindest kommuniziert werden.

Ich bin glücklicherweise zur Zeit nicht betroffen, da unser EV nur zweiphasig lädt. Aber dass die 1.9 so stiefmütterlich behandelt wird, finde ich auch traurig. Eigentlich sollte es jemand geben, der für Legacy Support abgestellt ist. So kenne ich das aus der Software Entwicklung. Aber es scheint ja insgesamt nur zwei wirklich aktive Entwickler zu geben und das ist für solch ein Projekt halt echt wenig.

Vielleicht hilft es ja, mal ein Ticket bei Github aufzumachen.

[Pjg]

Warum ein PR, der deutlich durchdachter scheint, nicht übernommen wird, ist trotzdem schwer nachvollziehbar und wenn es Gründe gibt, könnten die ja zumindest kommuniziert werden.

+1

[aiole]

Undurchdachter Hack trifft es vielleicht besser als gravierender Fehler. Warum ein PR, der deutlich durchdachter scheint, nicht übernommen wird, ist trotzdem schwer nachvollziehbar und wenn es Gründe gibt, könnten die ja zumindest kommuniziert werden.

Ich bin glücklicherweise zur Zeit nicht betroffen, da unser EV nur zweiphasig lädt. Aber dass die 1.9 so stiefmütterlich behandelt wird, finde ich auch traurig. Eigentlich sollte es jemand geben, der für Legacy Support abgestellt ist. So kenne ich das aus der Software Entwicklung. Aber es scheint ja insgesamt nur zwei wirklich aktive Entwickler zu geben und das ist für solch ein Projekt halt echt wenig.

Vielleicht hilft es ja, mal ein Ticket bei Github aufzumachen.

Ich gehe davon aus, dass man in v2.0 den gewachsenen code deutlich strukurierter aufzieht, was die Weiterentwicklung sicher stark vereinfacht.
Es ist immer eine Abwägung des Herstellers, wie man die Codepflege betreibt. Da alle oWB updatebar sein sollten, spricht m.E. nichts dagegen, sich für die Optimierungen voll auf 2.0 zu konzentrieren. Lassen wir uns überraschen.

[therobbot]

Ich weiß, dass das deine Meinung ist. Aber wer weiß schon, wann die 2.0 wirklich einsatzbereit sein wird. Immerhin war sie schon mal für letzten Sommer angekündigt. Ich kann ja verstehen, dass die Entwickler sich damit keine Arbeit mehr machen wollen und die Ressourcen auf die neue Version fokussieren. Aber in diesem Fall ist die Lösung ja schon da. Was spricht dagegen, sie in die Nightly zu übernehmen, testen zu lassen und dann vielleicht irgendwann auch mal noch eine neue Stable zu veröffentlichen?

[aiole]

Aber in diesem Fall ist die Lösung ja schon da. Was spricht dagegen, sie in die Nightly zu übernehmen, testen zu lassen und dann vielleicht irgendwann auch mal noch eine neue Stable zu veröffentlichen?

Jeder PR muss vor dem Merge geprüft werden. Kennst Du alle Abhängigkeiten? Ich nicht.
Ggf. gibt es auch weitergehende Gründe. Jeder PR birgt Risiken, die letztlich der Hersteller verantworten muss.
btw
Dir steht es frei, Deinen fork zu bauen und das Ganze umfänglich auszutesten.