openWB Forum

krebs8 hat geschrieben: ↑So Mär 28, 2021 8:32 amAber ich habe schon gemerkt, dass hier einige einfach nur dagegenreden, dass ein Wunsch, den sie nicht als wichtig erachten oder gar wahr haben möchten, implementiert wird, obwohl es ihnen egal sein könnte, da sie es ja auch nicht machen müssen.[..]Bin gespannt, wenn diejenigen mal einen Wunsch haben, ob sie das dann nicht auch tun oder doch lieber "4-stellige Summen ausgeben". Haha.

Schade, aber gut zu wissen, dass ich nicht der einzige bin, der das so empfindet. Weiter bringt uns das leider nicht. Insofern nur die Hoffnung, dass das Ausprechen zu mehr Konstruktivität führt.

openWB hat geschrieben: ↑Mi Mär 24, 2021 7:01 pmWenn hier nun ein verfälschter Wert zum Tragen kommt (semi PV Ladung), wie würdest du es finden wenn du den Strom mit einem Mieter abrechnest aber dabei drauflegst?

Also nur nochmal so zur Zusammenfassung:

Für Leute die keine PV haben macht das Feature keinen Unterschied.

Für Leute die eine PV haben und das Feature nur nutzen um für sich selbst abzuschätzen wie gut sie dastehen mit der PV-Nutzung gibt es keine Differenz die sie drauf zahlen müssten o.ä.

Leute die eine PV haben und den Strom an Dritte liefern müssen per Gesetz den PV-Anteil mit einem geeichten Zähler messen und die EEG-Abgabe abführen. Man kann es drehen und wenden wie man will: Das geht mit oWB nicht und lässt sich auch nicht durch Software darstellen. Dafür muss ein zusätzlicher Zähler in den Zählerkasten. Das ist auch kein Hexenwerk und hat der Elektriker schnell gemacht. Die Berechnung in der oWB wird dann nicht gebraucht.

Dann gibt es noch die Gruppe, die es alles nicht so genau nehmen, insbesondere nicht mit dem Gesetz, Strom an Dritte liefern, dabei die EEG-Abgabe hinterziehen und immerhin so nett sind der Person die den Strom bezieht etwas Rabatt für die Verwendung von PV-Strom einzuräumen und dafür gerne so eine ungefähre Berechnung haben wollen. Und die ganze Argumentation zielt jetzt darauf ab, dass genau diese Personengrupppe möglicherweise ihre Kunden mit einem ungenauen Wert abrechnet? Und dann... ähm... ja was eigentlich? Die Kunden dieser Personengruppe die Betreiber der oWB verklagt, weil die ja die Schätzwerte zur Verfügung gestellt haben oder was?

aiole hat geschrieben: ↑Sa Mär 27, 2021 12:41 pmDas Risiko, dass es doch jemand für Letzteres nutzt, ist hoch.

Man könnte einen Warnhinweis dran machen, der darauf hinweist, dass die Werte nur eine Schätzung sind und sich nicht für eine Abrechnung eignen. Wer es dann doch macht ist wirklich selber schuld.

aiole hat geschrieben: ↑Sa Mär 27, 2021 12:41 pmDu kannst anfangen, es umzusetzen. Der code steht frei zur Verfügung.

Es passt zwar nicht ganz so gut zu dem Thema hier, aber da es gerade hier immer wieder auftaucht: Erstmal das positive: Ja das geht, ja ich habe schon zwei PRs aufgemacht, beide wurden zügig bearbeitet und schnell gemergt. Etwas, was nicht bei allen Projekten so gut klappt.

Andererseits waren meine bisherigen zwei PRs Kleinigkeiten. Hier steht die ganze Zeit "oWB 2" im Raum. Es soll sich ja einiges ändern, wohl alles auf Python umgeschrieben werden und damit wird das Projekt vielleicht ein großer "Rewrite". Das ist eine gute Idee. Der aktuelle Quelltext ist wirklich... ähh.. garnicht schön. Eine Überarbeitung bekommt dem Projekt bestimmt gut. Aber leider ist oWB 2 (noch) nicht OpenSource und nichtmal irgendwie bekannt wohin die Reise geht und auf Nachfrage wird offiziell abgeraten an der alten Logik noch viel zu machen.

Also ja, ich würde mir gerne den Quelltext ansehen und ja, ich würde mich gerne damit beschäftigen wie aufwendig es dann tatsächlich ist da was zu machen, aber ich will es auch nicht machen, damit dann morgen oWB 2 kommt und alles für die Tonne war. Ich würde mich auch gerne in oWB 2 einlesen, aber der Quelltext ist leider nicht OpenSource. Oder existiert vielleicht noch nichtmal überhaupt und ist nur ein Gedankenkonstrukt. Keine Ahnung. Wenn es dazu mehr Infos gibt dann gerne. Solange bleibt nichts anderes übrig als erstmal nur über das Thema zu reden.

openWB hat geschrieben: ↑So Mär 28, 2021 9:13 am Nochmal, wäre es für dich im Zweifel ok wenn der Betrag bedeutend zu niedrig wäre und die Differenz draufzahlen müsstest?

Verstehe ich nicht.
Ich muß doch nichts draufzahlen, sondern als PV-Nutzer nur meinen tatsächlichen kWh-Preis besser abschätzen.
Und diese einfachen PV-Nutzer sind wohl viel viel mehr als die, die zusätzlich noch mit jemanden abrechnen wollen.

Edit:
Sehe gerade erst, daß mein Vorredner genau das Gleiche ebenso angesprochen hat.

krebs8 hat geschrieben: ↑So Mär 28, 2021 12:03 pm

openWB hat geschrieben: ↑So Mär 28, 2021 9:13 am Nochmal, wäre es für dich im Zweifel ok wenn der Betrag bedeutend zu niedrig wäre und die Differenz draufzahlen müsstest?

Verstehe ich nicht.
Ich muß doch nichts draufzahlen, sondern als PV-Nutzer nur meinen tatsächlichen kWh-Preis besser abschätzen.
Und diese einfachen PV-Nutzer sind wohl viel viel mehr als die, die zusätzlich noch mit jemanden abrechnen wollen.

Da die openWB keine Analyse Daten erhebt ist das schwierig zu beantworten. Ich weiß aufjedenfall das einige das tun.

Edit:
Sehe gerade erst, daß mein Vorredner genau das Gleiche ebenso angesprochen hat.

In deinem Fall trifft das zu. Aber nicht in jedem. Daher sollte das wenn auch schon brauchbar passen.

@yankee
Richtig, dabei geht es aber um die Ladelogik.
Das Ladelog ist losgelöst davon.

Die oWB-Entwickler können den Aufwand sicher am besten einschätzen. Es ist erörtert worden, dass dieser nicht trivial ist und auch der Support mehr gefordert werden würde, da Ihr damit einfach ein "neues Feld" aufmachen würdet.

Beides ist kontraproduktiv, wenn wichtigere Dinge anstehen, die da aktuell mind. sind:
* Produktion (Es gibt noch immer lange Lieferzeiten.)
* rewrite 2.x (Es wurde geschrieben, dass zunächst lauffähige Erstversionen erstellt werden, ohne dass alle mitwirken können, um sich einfach auf den rewrite zu konzentrieren und nicht ständig von Diskussionen abgelenkt zu sein.)

Hätte ich gewusst, dass das Preisthema mal so wie hier von manchen Leuten gepusht wird, hätte ich doch glatt mein Zugeständnis zum Festpreis widerrufen.

Mal ehrlich - was ist wichtiger?
Die solide Regelung der Energieflüsse oder Preiscontrolling/Optik, die "nice to have" sind?

Die tatsächlichen Stromkosten ergeben sich aus der oWB-Regelung, die anhand von Diagrammen gut geprüft werden können. Wenn man dort nicht an der Spitze mitmischt (v2.x), ist alles Nachgelagerte auch sinnfrei.

Der Ansatz, mit gehörigem Aufwand trotzdem nur eine Kosten-SCHÄTZUNG zu ermöglichen, entspricht m.E. nicht dem Qualitätsanspruch von oWB.

Des Weiteren finde ich es bedenklich, wie Nichtprogrammierer einschätzen wollen, was es kostet. 4-stellig ist im IT-Bereich sehr schnell erreicht und wenn man nicht einmal zur Finanzierung steht, hat sich das Thema eh erledigt.

Es gab mal eine feature-Liste, die mit Zusatzmitteln realisiert werden sollten. Bis auf 1...2 haben es keine weiteren geschafft. Genauso sehe ich das bei hiesigem Preisfeature, außer es fällt irgendwann bei einer SW-Rev. mit ab.
Ist hart, aber logisch.

VG aiole

ps
Ein wohlgemeinter Tip eines langjährigen Nutzers:
Erfreut Euch an der Regelung, statt Euch mit Preisoptik zu verzetteln.

openWB hat geschrieben: ↑So Mär 28, 2021 12:12 pmRichtig, dabei geht es aber um die Ladelogik. Das Ladelog ist losgelöst davon.

Also um die `regel.sh`? Oder auch noch was anderes? Das wäre schon echt gut zu wissen, womit man sich noch gefahrlos beschäftigen kann.

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmDie oWB-Entwickler können den Aufwand sicher am besten einschätzen. Es ist erörtert worden, dass dieser nicht trivial ist[..]

So wie du es sagst klingt es so, als wäre erörtert worden, dass die Entwicklung des Features nicht trivial ist. Aber dem ist nicht so. Wir haben lediglich erörtert, dass die Entscheidung wie genau das Feature aussehen soll aufwendig ist.

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pm[..]und auch der Support mehr gefordert werden würde, da Ihr damit einfach ein "neues Feld" aufmachen würdet.

Das "neue Feld" wäre also eine Aufbereitung von Messwerten. Voll neu.

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmBeides ist kontraproduktiv, wenn wichtigere Dinge anstehen

Und du bist der Zuständige für die Bewertung was "wichtig" ist? Wieviele dieser "wichtigeren" Dinge wären denn schon fertig, wenn du die Zeit, die du darauf verwendet hast diesen Wunsch (und andere) hier schlecht zu reden, in diese "wichtigeren" Dinge gesteckt hättest?

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pm* rewrite 2.x (Es wurde geschrieben, dass zunächst lauffähige Erstversionen erstellt werden, ohne dass alle mitwirken können, um sich einfach auf den rewrite zu konzentrieren und nicht ständig von Diskussionen abgelenkt zu sein.)

Dieser Thread dürfte dann ja bewiesen haben, dass die Diskussionen dadurch nicht aus bleiben. Tatsächlich hätte ich jetzt gerade mehr Lust mich mit dem Code zu beschäftigen, als diese Diskussion hier fortzuführen, deren Wirkung fraglich ist.

Ich finde die Entscheidung oWB 2 zunächst nicht OpenSource zu entwickeln sehr bedauerlich, aber natürlich kann jeder Projektbetreiber selbst darüber entscheiden wie er seine Software entwickelt und dann ist das halt so.

Aber wo ist genau das Problem, wenn in der Zwischenzeit Leute, die an dem Feature Interesse haben sich darüber austauschen, wie die Funktion sinnvoll gestaltet werden könnte?

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmHätte ich gewusst, dass das Preisthema mal so wie hier von manchen Leuten gepusht wird, hätte ich doch glatt mein Zugeständnis zum Festpreis widerrufen.

Äh was? Wenn du gewusst hättest, dass eine Funktion in die Software kommt, die die Leute tatsächlich haben wollen, dann hättest du dich dagegen gestellt?

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmMal ehrlich - was ist wichtiger?
Die solide Regelung der Energieflüsse oder Preiscontrolling/Optik, die "nice to have" sind?

Ist die Regelung aktuell nicht solide? Wird durch dieses Feature hier die Regelung weniger solide? Schließt das eine das andere aus?

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmDie tatsächlichen Stromkosten ergeben sich aus der oWB-Regelung, die anhand von Diagrammen gut geprüft werden können.

Entweder wir haben da eine unterschiedliche Definition von "gut" oder du kennst da eine Möglichkeit, die ich nicht kenne. Wie würdest du denn vorgehen?

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmDer Ansatz, mit gehörigem Aufwand trotzdem nur eine Kosten-SCHÄTZUNG zu ermöglichen, entspricht m.E. nicht dem Qualitätsanspruch von oWB.

Ja, den tatsächlichen PV-Anteil zu zählen fände ich auch deutlich besser als ein "Preis pro Lademodus". Da sind wir uns immerhin einig.

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmEin wohlgemeinter Tip eines langjährigen Nutzers:
Erfreut Euch an der Regelung, statt Euch mit Preisoptik zu verzetteln.

Ein wohlgemeinter Tipp eines langjährigen Softwareentwickler und Unterstützer von OpenSource-Projekten: Investiere deine Energie da rein, die Themen weiter zu bringen, die dir wichtig sind und nicht da rein die Themen von anderen Leuten schlecht zu reden.

So und nachdem das alles gesagt ist... Ich finde es wirklich schade, dass der Thread so sehr von Argumenten abgedriftet ist. Ich hatte auf Seite 2 dieses Threads mal wirklich aufwendig, mit Begründung und Rechenbeispiel ein Konzept erörtert wie das ganze implementiert werden könnte. Von @openWb kam der Einwand, dass die Priorisierung auch anders gewünscht sein könnte.. Ich finde das einen nachvollziehbaren Einwand, denke aber, dass das von mir aufgestellte Konzept trotzdem sehr hilfreich ist, was ich dann nochmal ausführlich begründet habe. Leider kam darauf keine einzige Reaktion mehr. Von @WRE kam nochmal ein etwas einfacherer, aber ähnlicher Vorschlag, der aber auch kaum Beachtung fand. Dann ging es mit diesem Thread langsam, aber stetig bergab. Jede Menge Argumente nach dem Prinzip "der Idee ist doof", "ist sie garnicht", "sehr wohl", "wie wäre es dann mit einem vereinfachte Konzept mit Preis pro Lademodus", "nein auch doof".

Das ganze könnte aber auch darauf hindeuten, dass alle Argumente ausgetauscht sind und es einfach nichts mehr zu sagen gibt. Insofern könnte man vielleicht eine Umfrage draus machen um zu schauen wie das Meinungsbild aussieht oder die Diskussion hier gut sein lassen und einfach gucken ob sich jemand findet, der es implementiert. Dafür wäre es nützlich zumindest einigermaßen Gewissheit zu haben, dass man nicht für die Tonne arbeitet, also dass nicht alles durch oWB2 obsolet ist und dass es nicht nachher mit der Begründung "zu viel Supportaufwand" abgelehnt wird.

Das ganze könnte aber auch darauf hindeuten, dass alle Argumente ausgetauscht sind und es einfach nichts mehr zu sagen gibt. Insofern könnte man vielleicht eine Umfrage draus machen um zu schauen wie das Meinungsbild aussieht oder die Diskussion hier gut sein lassen und einfach gucken ob sich jemand findet, der es implementiert. Dafür wäre es nützlich zumindest einigermaßen Gewissheit zu haben, dass man nicht für die Tonne arbeitet, also dass nicht alles durch oWB2 obsolet ist und dass es nicht nachher mit der Begründung "zu viel Supportaufwand" abgelehnt wird.

Gerne eine Umfrage starten.


Obsolet wird in 2.0 erstmal alles was mit der Laderegelung zu tun hat, also sofortpaden/minpv/nurpv/Nachtladen bzw. die jeweiligen .sh

Das ladelog wird von Nutzung der ramdisk auf auf mqtt umgebaut.

Ich werde die Tage etwas dazu schreiben ist hier schlicht fehl am Platz.

@yankee: Ich finde die Idee der Kosten gut. Noch habe ich kein E-Fahrzeug. Möglicherweise juckt mich dass Thema später so, dass ich mich dran versuche. Im Prinzip muss das doch mit Grenzkosten zu rechnen sein. Wenn ich zum Laden eine kWh aus dem Netz beziehe, kostet die 29ct. Wenn ich sie bei Überschusseinspeisung aus der PV nehme, kostet sie 12ct Gestehung plus 7,9ct entgangene Einspeisevergütung plus Umsatzsteuer für Selbstentnahme. Wenn ich sie aus dem Akku hole, sind es 12ct Gestehung plus USt für Selbstentnahme plus 40ct Akkuabschreibung (Zahlen nur Beispiel). Es muss für eine Kostenbetrachtung eigentlich nur klar sein, welche zusätzlichen Kosten die momentan zusätzlich geladene kWh verursacht.
Die momentanen Grenzkosten müssen dann mit hinreichend zeitlicher Auflösung integriert werden. Ich werde das Mal im Hinterkopf behalten. Momentan komme ich nicht mal dazu, die openwb- SW von Aufbau her kennenzulernen.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmDie oWB-Entwickler können den Aufwand sicher am besten einschätzen. Es ist erörtert worden, dass dieser nicht trivial ist[..]

So wie du es sagst klingt es so, als wäre erörtert worden, dass die Entwicklung des Features nicht trivial ist. Aber dem ist nicht so. Wir haben lediglich erörtert, dass die Entscheidung wie genau das Feature aussehen soll aufwendig ist.

Ja / nein ist einfach. Selbstverständlich geht es um den Umsetzungsaufwand.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pm[..]und auch der Support mehr gefordert werden würde, da Ihr damit einfach ein "neues Feld" aufmachen würdet.

Das "neue Feld" wäre also eine Aufbereitung von Messwerten. Voll neu.

Ich korrigiere Dich mal. => von Schätzwerten. Das ist ein Unterschied, der einiges an Klärung im laufenden Betrieb nach sich ziehen kann. Das muss der oWB-support dann zusätzlich stemmen oder bietest Du Dich dafür an .

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmBeides ist kontraproduktiv, wenn wichtigere Dinge anstehen

Und du bist der Zuständige für die Bewertung was "wichtig" ist? Wieviele dieser "wichtigeren" Dinge wären denn schon fertig, wenn du die Zeit, die du darauf verwendet hast diesen Wunsch (und andere) hier schlecht zu reden, in diese "wichtigeren" Dinge gesteckt hättest?

Genausosowenig wie ich "DER Zuständige" bin, bist Du es oder andere. Ich kenne oWB schon lange und lege mit diesen Erfahrungswerten natürlich meinen Standpunkt dar. Das ist in Diskussionen Standard und deswegen solltest Du nicht persönlich werden.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pm* rewrite 2.x (Es wurde geschrieben, dass zunächst lauffähige Erstversionen erstellt werden, ohne dass alle mitwirken können, um sich einfach auf den rewrite zu konzentrieren und nicht ständig von Diskussionen abgelenkt zu sein.)

Dieser Thread dürfte dann ja bewiesen haben, dass die Diskussionen dadurch nicht aus bleiben. Tatsächlich hätte ich jetzt gerade mehr Lust mich mit dem Code zu beschäftigen, als diese Diskussion hier fortzuführen, deren Wirkung fraglich ist.

Diskussionen sollen nicht aus bleiben. Sie dienen dazu, Informationsaustausch zu fördern. Man sollte jedoch die eigene Anwendung nicht permanent in den Vordergrund stellen, wenn es auch Argumente gegen die bestimmte features gibt. Dies wurde hier bereits mehrfach und von beiden Seiten erläutert.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm Ich finde die Entscheidung oWB 2 zunächst nicht OpenSource zu entwickeln sehr bedauerlich, aber natürlich kann jeder Projektbetreiber selbst darüber entscheiden wie er seine Software entwickelt und dann ist das halt so.

Aber wo ist genau das Problem, wenn in der Zwischenzeit Leute, die an dem Feature Interesse haben sich darüber austauschen, wie die Funktion sinnvoll gestaltet werden könnte?

Ich schätze, vornehmlich Zeit. OWB ist hocheffizient unterwegs und ich kann verstehen, wenn anfängliche, ellenlange Diskussionen diesem Anspruch als nicht förderlich entgegen stehen. Wir machen das bei der smartWB-SW übrigens genauso und fahren gut damit.

Bedenke, dass durch oWB 1.x bei den Entwicklern massig Erfahrungswerte vorliegen, die in v2.x weiterentwickelt werden. Man sollte ihnen schon zugestehen, das zunächst auf ihre Art zu realisieren, schließlich pflegen sie zu >90% den code. Letztlich trägt oWB die Hauptverantwortung.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmHätte ich gewusst, dass das Preisthema mal so wie hier von manchen Leuten gepusht wird, hätte ich doch glatt mein Zugeständnis zum Festpreis widerrufen.

Äh was? Wenn du gewusst hättest, dass eine Funktion in die Software kommt, die die Leute tatsächlich haben wollen, dann hättest du dich dagegen gestellt?

Bitte genau lesen.
Wenn der Aufwand zu hoch gewesen und andere wichtigere Dinge liegen geblieben wären - ja.
Das Thema erinnert nunmehr an "Reiche den Finger, so wird bald der ganze Arm genommen."

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmMal ehrlich - was ist wichtiger?
Die solide Regelung der Energieflüsse oder Preiscontrolling/Optik, die "nice to have" sind?

Ist die Regelung aktuell nicht solide? Wird durch dieses Feature hier die Regelung weniger solide? Schließt das eine das andere aus?

Es gibt sicher Baustellen und v2.x erfordert nach meinem Kenntnisstand auch ordentlich Entwicklungskapazitäten. Dann noch Support und Produktionshochlauf. Für ein Startup sind das 'ne Menge Aufgaben, die bis dato gut gemeistert werden. Dein Preisthema ist daher aktuell sekundärer Natur.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmDie tatsächlichen Stromkosten ergeben sich aus der oWB-Regelung, die anhand von Diagrammen gut geprüft werden können.

Entweder wir haben da eine unterschiedliche Definition von "gut" oder du kennst da eine Möglichkeit, die ich nicht kenne. Wie würdest du denn vorgehen?.

Wir reden hier von "Sowieso"-Kosten, denn die Kenntnis der verschiedenen Strompreise ändert nichts an der jährlichen Abschlussrechnung. Preisthema = "Optik"
Bei mir haben solide Regelcharakteristik inkl. individueller LP-Steuerung (v2.x) absoluten Vorrang vor Schätzpreisen, deren korrekte Werte am Ende des Jahres immer Abweichungen aufweisen und so oder so bezahlt werden.
Anhand der Diagramme sehe ich die Nutzungshäufigkeit und auch die entsprechende PV-Leistung, die in den Haushalt bzw. die LP fließen.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmDer Ansatz, mit gehörigem Aufwand trotzdem nur eine Kosten-SCHÄTZUNG zu ermöglichen, entspricht m.E. nicht dem Qualitätsanspruch von oWB.

Ja, den tatsächlichen PV-Anteil zu zählen fände ich auch deutlich besser als ein "Preis pro Lademodus". Da sind wir uns immerhin einig.

yup
Und deswegen müssten Abfanglogiken etc. eingebaut werden, wenn PV nicht separat gemessen wird. Gerade dies erfordert viel Zeit und Tests, um Nutzererlebnisse zu schaffen, die nicht von "komischen" Effekten geprägt sind. Ansonsten stirbt der Support unter den Anfragen.

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm

aiole hat geschrieben: ↑So Mär 28, 2021 12:54 pmEin wohlgemeinter Tip eines langjährigen Nutzers:
Erfreut Euch an der Regelung, statt Euch mit Preisoptik zu verzetteln.

Ein wohlgemeinter Tipp eines langjährigen Softwareentwickler und Unterstützer von OpenSource-Projekten: Investiere deine Energie da rein, die Themen weiter zu bringen, die dir wichtig sind und nicht da rein die Themen von anderen Leuten schlecht zu reden.

Da bin ich nun wieder bei Dir. Lege los, wenn Dir das Thema wichtig ist!

yankee hat geschrieben: ↑So Mär 28, 2021 5:52 pm Das ganze könnte aber auch darauf hindeuten, dass alle Argumente ausgetauscht sind und es einfach nichts mehr zu sagen gibt. Insofern könnte man vielleicht eine Umfrage draus machen um zu schauen wie das Meinungsbild aussieht oder die Diskussion hier gut sein lassen und einfach gucken ob sich jemand findet, der es implementiert. Dafür wäre es nützlich zumindest einigermaßen Gewissheit zu haben, dass man nicht für die Tonne arbeitet, also dass nicht alles durch oWB2 obsolet ist und dass es nicht nachher mit der Begründung "zu viel Supportaufwand" abgelehnt wird.

In der Tat sind genug Für und Wider ausgetauscht.

btw
Umfragen helfen nicht wirklich weiter, denn was ändern sie? Es gibt einfach Dinge, die aktuell Vorrang haben und da können wir uns vieles wünschen. Ich betone AKTUELL, denn ich habe nie gesagt, das das Preisthema für immer vom Tisch ist.

Ich denke Auswertungen dieser Art müssen nicht unbedingt in openWB integriert sein.

openWB ist eine sehr gute - wenn nicht die beste - Wallbox.
Die Kernfunktionen sind hinreichend komplex daher sollte die Platform nicht mit unnötigen Reporting-Aufgaben belastet werden.
Die bestehenden Logs und Graphen die hilfreich für den aktuellen Betrieb sind, sollten so bleiben!

Vorschlag:
Separierung dieser Reports in eine besser geeignete Anwendung/Platform (z.B. Influx/Grafana, Crystal, Excel, ...).
Die notwendigen Log-Daten aus openWB sind relativ einfach auszulesen.

Wenn sich genügend User zusammenfinden und sich auf gemeinsame Anforderungen und Design einigen können, kann das als weiteres opensource Projekt aufgesetzt werden.
Alternativ kann mit den Log-Daten jeder seine Auswertungen selbst realisieren.

VG

Danke yankee für Deinen Beitrag.