openWB Forum

Die Frage ist dann aber was fällt darunter?
Änderung in der Schnittstelle eines dritt drittherstellers?
Neues SoC Modul? ( das könnte im Zweifel noch andere Abhängigkeiten haben )

Man muss halt auch sagen das gerade die Mieterstrom und größeren Installationen ohne große externe Eingriffe am stabilsten laufen.

LTS klingt nicht schlecht.

Bei so etwas wie SOC Modul und Komponenten wäre es doch eigentlich sinnvoll, dass das so modular gehalten wird (Stichwort: Treiber), dass es keine Abhängigkeiten gibt. Meiner Meinung nach müsste das über eine fest definierte Schnittstelle laufen, sodass zumindest Rückwärtskompatibilität gegeben ist, man also zb ein neues SOC Modul ohne Änderung in einer älteren Software hinzufügen können sollte.

Ja, meistens ist das so, aber halt auch nicht immer zwingend.
Siehe aktuell z.B. die odometer Erweiterung die mit älteren nicht kompatibel.

Meiner Erfahrung nach kann man Erweiterungen meistens aber auch so implementieren, dass sie rückwärtskompatibel sind. Ich komme aus der Objektorientierung. Da würde ich halt einfach dem SOC Modul eine getOdo() und eine getSoc() Methode geben. In der alten Softwareversion würde die getOdo() dann einfach nicht aufgerufen.

openWB hat geschrieben: Do Apr 16, 2026 4:13 pm Die Frage ist dann aber was fällt darunter?
Änderung in der Schnittstelle eines dritt drittherstellers?
Neues SoC Modul? ( das könnte im Zweifel noch andere Abhängigkeiten haben )

Man muss halt auch sagen das gerade die Mieterstrom und größeren Installationen ohne große externe Eingriffe am stabilsten laufen.

Ja, also praxisnah würde ich behaupten (bis auf ein paar Ausnahmen, die es immer gibt) wird dort das Thema Zielladen und soc Module von Autos eher weniger relevant sein. Die Mieter oder Angestellte bei der Arbeit wollen: im Sofortladen Modus eine definierte Ladung die Funktioniert ohne wenn und aber (ausgenommen vom Lastmanagement). PV Laden Modus soll bevorzugt PV, Batterie und ggf. Keinen bzw. Also letzten Anteil Strom aus dem Stromnetz verwenden ( je nach Konfiguration. Es muss den useren vermittelt werden, dass dieser Modus zuverlässig funktioniert aber natürlich von den Bedingungen abhängig ist und kein "sicheres laden" bezogen auf die Energiemenge bietet. Hierbei ist der Preisanreiz dafür gegeben.
Ggf..kann je nach System der Modus Eco mit dem Laden in NT Zeiten verwendet werden. Mehr ist aber in Größeren Einheiten kaum umsetzbar ohne sich als Betreiber und das "Ladeerlebnis des Kunden" zu verkomplizieren.

Alle anderen Features sind in Gewerblichen als auch in Bereichen mit Mieterstrom/WEG aus meiner Sicht und der aus KMU/ Industrie und Mieterstrom Sicht nicht zielführend. Das führt zu oft zu vielen Eingriffen und Problemem, Frust und ggf. einem Gefühl, dass OpenWB als " unzuverlässig" angesehen wird. (Hierfür ist dann ggf. Für manche der Preis der WB "zu hoch"? )

Das sollte so nicht sein.

Zu deinem Punkt mit dem wo zieht man den Schlussstrich? Ja ist immer schwierig. Aber ich hätte gesagt, man teilt den Bereich der Kunden in private und Gewerbliche ( inkl. Mieterstrom/WEG/LM/HEMS) ein. Hierbei sind verschiedene Punkte für die Zielgruppeen zu definieren. IdR ist im gewerblichen Ansatz Zuverlässigkeit und Sicherheit besonders wichtig ( Soc Module für Pkw sind meist nicht umsetzbar). Auch sind Gewerbe meist mit größeren Anbietern im Bereich Solar unterwegs aus den oben genannten Gründen. Hierfür sind die Schnittstellen wohl im Moment soweit alle aktuell und laufen.

Aus dem Feedback der nicht LTS Versionen der "Bastler" und der Heimanwender ( Feedback via Support Ticket Auswertungen) profitiert die LTS Version.

Das Bild was sich bei den Firmen, KMU und Mieterstrom Nutzern somit ergibt, ist eine verlässliches Produkt. Und somit zu empfehlungen unter den KMU und Mieterstromanbietern. Positiv könnte ich mir vorstellen wäre auch zu nennen, dass OpenWB weniger selbst mit Tickets zu "kämpfen" hat weil LTS Versionen " laufen". -> spart Support Kapazitäten?

Wichtig ist denke ich, dass das Grundkonzept jetzt mit der 2.2.0 inkl. BV den Grundstein legt um so flexibel wie möglich auf die Kundenbedürfnisse eingehen zu können. Das ist meiner Meinung nach zu 80 Prozent (ich muss es in meiner Mieterstrom Funktion noch testen) gegeben. Dann kann man es für viele verschiedene Szenarien einsetzen.

Da nun ja auch geplant ist die Förderung von MFH's mit seitens der Regierung aus her zu fördern, sehe ich die OpenWB mit der 2.2.0 und dem Positionieren von Mieterstrom, gewerblichen Möglichkeiten als sehr gut an.

Was mir in Hinblick auf Elektroinstallationsbetriebe einfällt: die meisten ( nicht alle) wollen mit der Installation nach dem installieren nichts mehr nzuntun haben und sich auch nicht ndrum kümmern, da die Kunden in der Regel nicht bereit sind die Support kosten im Nachgang zu bezahlen und somit der Betrieb selbst drauf Sitzen bleibt.

Hier wurde schon viel Wichtiges und Richtiges gesagt. Ich warne davor, zu einfache Lösungen zu suchen. Ich sehe zwei große Themen die sich gegenseitig potenzieren:

1. Die Software ist komplex und kompliziert.
2. Der Entwicklungsprozess ist der Komplexität keinesfalls angemessen.

Die Kombination hat das Potenzial für erheblichen Schaden. Deswegen meine unbedingte Empfehlung:

1. Komplexität reduzieren. Was ist der Kern von openWB? Was sind Features für Leute die lieber Home Assistant & Co zusätzlich betreiben? Die können raus, dafür eine professionelle Schnittstelle zu einem solchen Produkt. Dazu ein stringenter Prozess wie über neue Features entschieden wird. Und, mindestens so wichtig, ein Weg, um dem Hang Einhalt zu gebieten, komplizierte Lösungen zu finden. Dafür wird externe Beratung genauso wie Schulung notwendig sein.
2. Entwicklungsprozess professionalisieren. Home Assistant ist ungleich komplexer als openWB. Bugs habe ich noch keine gefunden (natürlich gibts welche). Ein erhebliches Investment in Testautomatisierung ist hierfür der Schlüssel, d.h. die Umsetzung einer ganzheitlichen Teststrategie. Via AI bezahlbarer als noch vor 3 Jahren. Auch hierfür, externe Beratung, Schulung.

Ich hoffe die deutlichen Worte sind als Blick von außen ok und werden nicht als Anmaßung verstanden. Ich komme als Kunde mit dem Produkt schon zurecht wie es ist, überlege mir aber genau wann und wie oft ich noch Updates mache. Ich denke einfach, das Produkt hätte viel mehr Potenzial am Markt in anderer Qualität.

Die ultimative Lösung kann ich auch nicht beitragen, würde gerne nochmal das Thema Feedbackthread aufgreifen:
- Ich sehe, dass z.T. die Entwickler sich die Zeit nehmen, um Meldungen zu bearbeiten, die dann doch an fehlerhaften Einstellungen liegen.
Diese Energie fehlt dann natürlich an anderen Stellen.
- Zu anderen Meldungen, die dann ggf. tatsächliche Fehler enthalten, kommt z.T. keine Rückmeldung, das haben ja schon einige hier bemängelt.
- Es werden Sachverhalte z.T. mehrfach gemeldet, manchmal ist aber auch nicht auf den 1. Blick erkennbar, dass es sich um die gleiche Ursache handelt. Es gibt durchaus sehr ähnliche Fehlerbilder, die dann doch verschiedene Ursachen haben können.

Aus dem ganzen würde ich auch den Schluss ziehen, dass man eine Art Ticketsystem benötigt, in dem die Meldungen von qualifiziertem Personal zunächst in Probleme oder Supportfälle aufgeteilt werden.
Ich denke, das könnte man durchaus so ähnlich wie oder mit Github Issues lösen, so dass die Meldungen im Forum z.B. zu Issues in Github werden. Das war hier ja schon angeregt.
Das Problem ist, dass die master-Versionen nicht vom normalen Support bearbeitet werden, vermutlich da ja durchaus Änderungen, die gerade entwickelt werden, dort noch nicht geschult werden konnten.
Es müsste also eine Art Spezialteam geben, das diese Einordnung vornehmen kann. Dies aus der Community zu realisieren halt ich nicht für so zielführend, da evtl. ein "kurzer Dienstweg" zum Entwicklungsteam zur Einordnung der Meldungen benötigt wird.

Als weiteres Problem sehe ich die Entwicklungszweige selbst:
Zunächst wird die Entwicklung neuer Funktionen als Alpha-Version bezeichnet, die Phase läuft ziemlich lange.
Dann gibt es einen Feature-Freeze und es geht zur Beta und RC Version über, in der nur noch Fehler behoben werden.
Diese sind nach meinem Verständnis in letzter Zeit viel zu kurz gekommen.
Aktuell sehe ich z.B. noch Fehler in der aktuellen RC-Version, die aus meiner Sicht gegen das Veröffentlichen einer Release-Version sprechen.
Es wurde aus RC1 aber RC2 ohne dass diese behoben sind, daher befürchte ich, dass wir kurz vor Veröffentlichung des Releases stehen und Angst haben müssen, dass die Fehler nicht behoben werden.
Auch sehe ich ein Problem darin, wie bzw. wo die Änderungen ab der Beta-Phase erfolgen. Es werden Korrekturen im master vorgenommen, die dann noch in die Beta-Version einfließen, dabei bleibt dann aber gar keine Zeit mehr diese Änderungen auf Wechselwirkungen o.ä. zu prüfen, da sie dann ja auch nur kurze Zeit im master getestet wurden, bevor sie dann als neue Beta, RC oder sogar Release veröffentlicht werden.
In der Beta und RC-Phase steigt die Anzahl der aktiven Nutzer auf jeden Fall, so dass diese Phase auf jeden Fall ausgedehnt werden sollte, um eine stabile Release Version zu veröffentlichen, die nicht später mit Patches nochmal korrigiert werden muss.
Es gibt zwar anderseits den Druck, das Release schneller zu veröffentlichen, weil die Features offiziell verfügbar werden sollen, aber das würde ich zum Wohle der Stabilität lieber "aussitzen".
Wenn das ganze dann zu stabileren Release-Versionen führt, ist die Einführung einer LTS-Version vielleicht gar nicht mehr so elementar, wäre aber auf jeden Fall eine Idee.
Ich wüsste aber nicht, wie man openWB vereinfachen sollte, ohne auf wichtige Features zu verzichten. Mir gefällt sie aktuell sehr gut und ich bin froh, dass mich mein Solarteur damals darauf hingewiesen hat und ich sie trotz Mehrkosten genommen habe.

Ich habe aktuell das Gefühl, dass die Version 2.2.0 das Potential zu einem ruhigerem Fahrwasser hat, da die Major Changes in der Vergangenheit, wie temporäre Ladeprofile, die Änderungen in der Speichersteuerung und die Benutzerverwaltung ja wirklich große Brocken sind, auf deren Basis nun eine Optimierung mit nicht ganz so elementaren Änderungen, die auf der neuen Basis aufbauen, zu unfallfreieren Features führen kann.

Ich hoffe ich konnte hier noch etwas beitragen, was noch nicht geschrieben wurde.

Ich sehe LTS als Antwort auf die notwendigerweise schlechter werdende Softwarequalität der Philosophien „SCRUM-Sprint“ und „continuous Delivery“. Letzteres führt zu häufigeren, notwendigerweise schlechter getesteten, Updates und LTS ist da die Bremse für diejenigen, die die Software - ich sage mal provokant „produktiv im Echteinsatz“ nutzen wollen.

Beides beschreibt Dinge, die wir heute schon unter anderem Namen haben: das eine heißt „Release“ und sollte eigentlich ein produktiv einsetzbarer Softwarestand sein. Jemand, der auf Release bleibt, sollte niemals darum fürchten müssen, dass Funktionalität kaputt geht oder die Ladeprotokolle unbrauchbar werden. Das wird durch die Release-Versionen nicht sicher gestellt. (Das ist übrigens einer der Gründe, warum ich die openWB nur sehr selektiv weiterempfehle) das andere heißt aktuell „master“ und ist die Entwicklungsversion mit den neuesten Features und dementsprechend „wackelig“. (Ich bin immer auf „master“ und habe glücklicherweise erst einmal auf meinen noch vorhandenen Juice-Booster zurückgreifen müssen. Allerdings wird der Ion mittlerweile per Ladeziegel geladen)

Wenn man LTS erwägt, könnte man genauso die Release-Zyklen verlängern. Damit wäre der Sache mehr geholfen, als weiterhin instabile Software zu releasen und dafür dann mit LTS ein Stabilitätsversprechen zu geben. (Und sich danit eine neue Stufe der Komplexität einzuhandeln)

Zum Thema Support: ja, ich glaube auch, dass das Forum als Input für internes Ticketing gentzt werden sollte. Ein Feedback-Thread mit ein paar Testern, die naturgemäß nur das testen, was sie gerade interessiert, ist nicht ausreichend.

LTS ist eine gute Idee für Haus-Installationen und "nur Anwender", oder wie auch immer man das nennen möchte. Was ich persönlich und einige andere sicher auch an openWB schätzen, ist aber auch die schnelle Umsetzung von Innovationen - dynamische Strompreise, Speicherbeachtung etc. Ich selbst würde deshalb eher keine LTS nutzen. Gleichzeitig brauch ich meine Wallbox aber auch und hab keine Zeit, ständig irgendwas neu aufzusetzen - der Master taugt deshalb ebenfalls nur bedingt.

Wichtig finde ich deshalb, dass es klar abgetrennte Entwicklungszweige gibt. Bei Linux gibt es ja auch noch viel mehr als LTS und Alpha. Auf meinem PC, den ich produktiv benötige (und zwar als Marketingfuzzi, nicht als Programmierer...), läuft ein Linux mit Rolling Release Modell (Tuxedo OS). Das finde ich ziemlich super, weil ich hier früh von neuen Features profitiere, nicht erst mit der nächsten LTS-Version (die es da m.W. auch garnicht gibt). Dennoch ist die Software so gut getestet, dass ich nie wirklich Probleme habe. Genau so würde ich mir das auch für openWB wünschen.

Eine Zeitlang habe ich sogar den openWB Master-Branch verwendet. Das Problem war aber, dass man speziell nach einem Release nicht ganz sicher sein konnte, ob das nächste Update nun ein Patch für die Release-Version mit weiteren Verbesserungen ist, oder eine "Nightly-Build", in der quasi nix mehr funktioniert...