Fragen zur Mitarbeit an der SW

[hhoefling]

für 1.9 auf Python 3.5 laufen.

Das sind die Details die man früher hätte wissen müssen.
Gefragt wurde mehrfach nach details...

Also Backport 3.7->3.5 ?
Mein Soc-Script wird dann auf meinem Debian10 Host laufen und geht mit MQTT auf die Wallbox.

[LutzB]

für 1.9 auf Python 3.5 laufen.

Das sind die Details die man früher hätte wissen müssen.
Gefragt wurde mehrfach nach details...

Also Backport 3.7->3.5 ?
Mein Soc-Script wird dann auf meinem Debian10 Host laufen und geht mit MQTT auf die Wallbox.

Nunja, das ist aktueller Stand der Dinge. Wenn man ein eigenes Image aufsetzt, muss man sich auch über die Auswirkungen im Klaren sein. In diesem Fall die Unterschiede Stretch <-> Buster.

Ich nehme mal an, Du wolltest Deine Module auch schon jetzt allgemein zur Verfügung stellen? Dann bleibt es bei 3.5. Alles andere wäre ein 2.0-only Modul, was jetzt definitiv noch keinen Sinn macht, wo es noch nicht mal ein Alpha Release gibt.

[hhoefling]

Wegen der langen Lieferzeiten habe ich erst gestern erfahren das Phyton3 nicht Pyhton3 ist.
Das auf Python3 umgestellt wird war das einzigste was bekannt war.

Einfach macht ihr es einem wirklich nicht.

[yankee]

Letzlich ist es natürlich das Projekt von Kevin&Co und entsprechend deren Entscheidung was daraus wird. Ich würde aber schon gerne dazu anregen über das Feedback welches in diesem Thread hier zustand gekommen ist nachzudenken. Das ganze soll jetzt nicht als "Beschwerde" rüber kommen, sondern Verständnis für die Perspektive öffnen, die ich als "externer" Nutzer und Entwickler habe und Ideen geben, wie ein offenerer Umgang dem Projekt helfen könnte.

OpenSource hat einige große Vorteile. Als Hersteller bedeutet es, dass man viel mehr Input bekommt. Es gibt viel mehr Leute die irgendwas entwickeln und beisteuern. Wenn jemandem ein Feature fehlt... Ja, dann programmier' es doch und mach ein PR auf! Der größte offensichtliche Nutzen bei der openWB sind die ganze Module die beigesteuert wurden. In einer komplett geschlossenen Umgebung sähe es da wohl dünn aus. Das allerdings hätte man auch mit einer Closed-Source Architektur, die jedoch pluginfähig ist erreichen können. Der Nutzen liegt bei der oWB auch darin, dass es Entwickler gibt, die am Kern mitarbeiten. Der Vorteil erstreckt sich dabei nicht nur darauf, dass Code geschrieben wird, sondern auch, dass diskutiert, reviewed und verbessert wird. Auch mir als versierter Anwender gibt das Ganze Sicherheit. Ich weiß, dass wenn oWB eingestellt wird oder sich in eine Richtung entwickelt, die mir garnicht gefällt, dann kann das Projekt geforkt werden und in eine andere Richtung weiter gebracht werden.

Natürlich hat das OpenSource auch Nachteile. Man muss den ganzen Prozess "managen". D.h. man muss sich die PRs die rein kommen auch ansehen, reviewen und auf Anmerkungen und Tickets auch antworten. Also gut, "muss" man natürlich nicht, aber wenn man es nicht tut, dann vergeht den Leuten die Lust sich am Projekt zu beteiligen und dann kann man von den genannten Vorteilen nicht mehr so sehr profitieren.

Ich verstehe, dass das ganze Arbeit ist. Ich bin der Meinung, die Arbeit ist es wert.

Hier sind ein paar Dinge, die man tun könnte, um mehr aus dem Vollen zu schöpfen:

- Neben der README.md in Github eine CONTRIBUTING.md schreiben. Dort sollten so Dinge stehen wie "welche Abhängigkeiten gibt es (zum Beispiel die Info welche Python-Version)", "welcher Code-Style wird verwendet", "wie kann man seinen Code testen", "welche Art der Programmerung wird bevorzugt (Python vs. Bash)" etc.
- Sich die PRs die man bekommt auch ansehen. Ich habe am 26.05., also vor fast einem halben Jahr einen PR aufgemacht, der initial auch sofort Feedback bekam. Ich habe mich darüber gefreut und nochmal einige Stunden in den PR gesteckt und das ganze überarbeitet. Und danach kam einfach NICHTS mehr. Keine Zeit? Unter anderem habe ich in dem PR das Bash-Script für Discovergy auf Python umgeschrieben. Zwei Monate später hat dann auch nochmal jemand anders sich die Arbeit gemacht das Modul auf Python zu ändern. Es wäre doch viel einfacher und zeitsparender gewesen meine fertige Lösung zu nehmen. Vielleicht war meine Lösung ja so nicht gewollt. Das ist OK, manchmal muss man auch einfach mal "nein" sagen, wenn ein PR nicht ins Konzept passt. Aber dann wäre es zumindest nett mal einen Satz dazu zu sagen und den PR nicht einfach völlig zu ignorieren. So ist das ganze eine loose-loose Situation: Ich habe für die Tonne gearbeitet und das oWB-Team hat sich unnötig doppelte Arbeit gemacht.
- Sich frühzeitig und rechtzeitig zur zukünftigen Entwicklung äußern. Was kann man noch machen? Was wird über den Haufen geworfen? Ich hatte selber schonmal nachgefragt ob es noch Sinn ergibt sich mit der alten Version zu beschäftigen. Kevin sagte "nein". Das ganze ist nicht ganz 1 Jahr her. Ich habe damals gedacht "OK, gib dem ganzen mal ein paar Wochen, dann wissen wir mehr". Nun ja, das ist nicht passiert. oWB 2.0 ist seit über einem Jahr offiziell angekündigt. Seit dem ist es eigentlich nicht mehr gewünscht sich noch groß mit der 1.X zu beschäftigen. Nach mehreren Monaten der Nicht-Information, war ich dann aber tatsächlich von einem störenden Bug betroffen und wollte jetzt nicht monatelang warten bis oWB 2.0 kommt. Also habe ich einen PR mit Fix aufgemacht und natürlich kam prompt zurück: "Ist inkompatibel mit oWB 2.0.". Toll. In dem Fall war wenigstens ICH mir dem Risiko bewusst. Denn diese Info findet man nur, wenn man sehr aktiv danach sucht. Wer sich nichts-ahnend mit der 1.X beschäftigt, arbeitet potentiell für die Tonne und erfährt das dann danach. Es ist auch völlig unklar, was sich überhaupt wie in oWB 2.0 ändert.
Nachdem das EVNotify-Modul ausgefallen ist habe ich dafür einen Fix entwickelt. Im Rahmen meiner Arbeit habe ich mich darüber geärgert, dass Logging und Config-Zugriff so umständlich ist. An oWB2.0 habe ich allmählich den Glauben verloren. Insofern habe ich dann mal einen Vorschlag gemacht wie man es besser machen könnte. Prompt kam natürlich "da sind wir schon mit oWB 2 dran".

Gab es eigentlich mal eine offizielle Aussage, warum 2.0 im Geheimen entwickelt wird?

Um aus der Erfahrung der letzten Jahre zu schöpfen und das Grundgerüst stellen zu können.
Das verhindert das zu früh zu viel diskutiert wird.

Ich frage mich wie es aussieht, wenn man "zu früh zu viel diskutiert", bzw. wie oder ob das ganze technisch überhaupt möglich ist. Dinge die man erst diskutiert, wenn alles schon fertig ist sind müßig, denn es ist ja schon alles da. Besser ist doch, wenn man so früh wie möglich diskutiert. Ohnehin wird das Ziel ja nicht erreicht. Es wird jede Menge über 2.0 diskutiert. Wobei man vielleicht eher sagen könnte "spekuliert".

Letztlich ist ja mit dem PR #1592 doch ein bisschen was durchgedrungen. Ich habe mich daran beteiligt und ein umfangreiches Code-Review dazu gemacht. Den Reaktionen nach zu urteilen war das auch willkommen und ich sehe, dass im #1628 auch viel von meinen Vorschlägen umgesetzt wurde. Es freut mich natürlich sehr zu sehen, dass die Arbeit die ich mir damit gemacht habe auch angekommen ist (etwas schade, dass ich den 1628 erst jetzt sehe, aber gut...). War das jetzt die "zu frühe Diskussion"?



Ich finde oWB ein super cooles Projekt. Ich finde es toll, dass es OpenSource ist und dass ich mich daran beteiligen kann. Ich mache da gerne bei mit um das Projekt weiter zu bringen. Wenn ihr noch etwas offener wärt gegenüber weiteren potentiellen Beitragenden würde es noch mehr Spaß machen und es gäbe noch mehr Input.

[hhoefling]

Danke, hätte ich nicht besser sagen können.

Ich habe mich auch erst mal ausgeklinkt und werkel an meiner 1.9 weiter.

[aiole]

....
Ich finde oWB ein super cooles Projekt. Ich finde es toll, dass es OpenSource ist und dass ich mich daran beteiligen kann. Ich mache da gerne bei mit um das Projekt weiter zu bringen. Wenn ihr noch etwas offener wärt gegenüber weiteren potentiellen Beitragenden würde es noch mehr Spaß machen und es gäbe noch mehr Input.

Ich schätze, dass das nach dem ersten Alpha-release der v2.0 besser wird.

Auf der anderen Seite verstehe ich auch oWB, wenn sie die Erfahrungen und Wünsche (, deren Kenntnis sie durch Euch/Forum haben) zunächst selbst einbauen wollen. Es ist letztlich der Faktor Zeit, der eine große Rolle spielt und ich mag mir nicht vorstellen, wenn sich v2.x noch länger hinauszögern würde.

Die Verbesserungen sind in großen Teilen hier beschrieben viewtopic.php?f=3&t=3170 und ich denke, dass das ein richtig großer Schritt vorwärts wird.

Wenn ich entwickle, gehe ich übrigens ähnlich vor.
Erfahrungen u. Wünsche sammeln => Lastenheft, darauf aufbauend eigene Entwicklung, Prototyp, Präsentation, Verbesserungen zusammen mit der Community
Ich kenne genug Projekte die vorab "zerdiskutiert" werden und nie ein funktionstüchtiges Produkt herausbringen (oder ewig dafür brauchen). Das System "etappenweise lauffähige Produkte" zu bringen, hat für die Nutzer handfeste Vorteile.

Bezogen auf oWB 2.x => Für v2.0+ ist sicher wieder viel Mitarbeit nötig und gewünscht. Der erste Schritt ist eben der aufwendigste.

[gvz]

Hi Aiole,

Mich interessieren die aufgelisteten und von Dir zitierten "Verbesserungen" in 2.0 eigentlich überhaupt nicht. Ich benötige nicht unendlich viele Ladepunkte, mir reicht einer.
Um es doch mal ziemlich klar zu formulieren: Den Verbesserungsbedarf sehe ich "unter der Haube". Es gibt teilweise nicht einmal eine Systematik in der Variablenbenennung für die Ladepunkte 1-8 (ganz abgesehen davon, dass so etwas natürlich nach Arrays schreit). Es ist für mich unkonventionell, permanente Regelprozesse per cron-Job zu starten, statt als Daemon laufen zu lassen. Der MQTT-Client-Daemon schreibt ohne Lock oder atomares Rename auf die "Ramdisk-Platte" - das wird oft, aber nicht immer, gelingen. Sehr viel Code erscheint mir beim Auftreten eines neuen Usecases einfach dupliziert und für den neuen Fall angepasst worden zu sein - was Code zwar zunächst robust macht, danach aber die Wartbarkeit erschwert. Das nur als 4 Punkte, wo für mich alles ziemlich nach dem großen Rewrite schreit.

Bei so einem großen Rewrite wird viel kaputt gehen. Genau aber deswegen ist es doch wichtig, Leute, die willig sind, Fehler zu suchen und zu beheben, einzubinden - und sei es eine Pre-Alpha mit persönlicher Einladung. Meine gefühlte abolute Standardinstallation: 11 kW, 1 LP, PV um die 10 kW scheint ja schon im Regeltest nicht abgedeckt zu sein, siehe "meinen" 1/3-Phasen-Thread. Und ich bin da schon etwas frustriert, weil ich nun wirklich im Thread klar versucht habe, mit dem Autor zu kommunizieren und zu schreiben: "An der Stelle X hast Du den Fall Y nicht bedacht, deswegen passiert Z. Meine Lösung wäre ... - eine bessere Idee?". Und da geht es nicht um "Zerreden", sondern schlichtweg Bugs, die auch normale Kunden als solche empfinden.

In der Zusammenfassung ist das alles unglücklich: Die "stable-Version" bleibt buggy, die "hier geht es weiter"-Version ist klar hinter dem Zeitplan. Was soll man da anderes machen als die Hände in den Schoß zu legen oder über einen Fork nachzudenken?

Viele Grüße, Georg

P.S. Mal als ein Vorschlag: "Kommt am Samstag, den x.y. ins schöne Hessen. Handys müssen draußen bleiben, 2G-Nachweis mitgebracht werden, NDA unterschrieben werden - aber dann bekommt Ihr mal einen Einblick und wir können besprechen, was Sache ist".

[aiole]

...
In der Zusammenfassung ist das alles unglücklich: Die "stable-Version" bleibt buggy, die "hier geht es weiter"-Version ist klar hinter dem Zeitplan. Was soll man da anderes machen als die Hände in den Schoß zu legen oder über einen Fork nachzudenken?

Das halte ich persönlich für Schwarzmalerei. Nur weil bestimmte Dinge noch nicht optimal sind, heißt das nicht, dass ein Großteil unzufrieden mit dem System ist. Gerade bei Standardanwendungen wird oWB verglichen mit der Konkurrenz häufig gelobt. Außerdem - zeige mir DIE SW, die keinen bug hat .

zu "klar hinter dem Zeitplan":
Nun, MIT Vorabdiskussionen wäre das noch weit schlimmer. Komplexe Dinge müssen in Ruhe und ggf. auch unter Ausschluss der Öffentlichkeit durchdacht werden. Mir sind Zeitverzögerungen lieber als Qualitätseinbußen, denn letztere sorgen für deutlich mehr Frust als schnödes Warten.
Das gilt leider auch für mitwirkende Entwickler, die sich bis zum Erstrelease der v2.0 in Geduld üben müssen.

P.S. Mal als ein Vorschlag: "Kommt am Samstag, den x.y. ins schöne Hessen. Handys müssen draußen bleiben, 2G-Nachweis mitgebracht werden, NDA unterschrieben werden - aber dann bekommt Ihr mal einen Einblick und wir können besprechen, was Sache ist".

Keine Ahnung, ob mal ein "community-day" kommt. Da aber die HW closed source ist, wüßte ich nicht, was Dir ein Besprechungszimmer mit ein paar Rechnern, die die aktuelle SW zeigen nützt. Gut - man könnte Mehrfachladungen live sehen und viel wichtiger - direkter Erfahrungsaustausch.
Da bin ich voll bei Dir.
Aktuell sind die Prioritäten jedoch klar auf mehr Produktion und v2.0 festgelegt, weshalb die Zeit für einen "community-day" noch nicht gekommen ist. Ich bin da allerdings zuversichtlich.

VG