Update zur Sommerankündigung

[derNeueDet]

Nö.

[openWB]

Leider hab ich diese Sommerupdate-Threads hier erst jetzt gelesen - nachdem ich dummerweise vor paar Tagen gespendet hab (zum Glück zunächst nur 50€)

Schade das du den nicht folgen kannst.
Wenn du möchtest erhältst du deine Spende zurück.

[LutzL]

Leider hab ich diese Sommerupdate-Threads hier erst jetzt gelesen - nachdem ich dummerweise vor paar Tagen gespendet hab (zum Glück zunächst nur 50€)

Schade das du den nicht folgen kannst.
Wenn du möchtest erhältst du deine Spende zurück.

Ach was, das seh ich nicht so eng. So entspricht die Spende doch fast ein bissel der früher geplanten Lizensierungsgebühr, wenn auch nur für ca. 4 Monate (dafür Hochsaison) @ Summe ~800kWh PV-Ladung.
Ihr habt aber eine tolle Software gemacht, hatte Spaß gemacht meine goE damit zu steuern...

[aiole]

Wieso "hatte"? Lies am besten nochmal die letzten 5 Threadseiten.
Ich sehe nicht, dass man keine go-e-WB betreiben könnte. LM entfällt, aber doch nicht die WB-Unterstützung. Das sind 2 Paar Schuhe.

btw zu FHEM mit Perl
Ich hatte mir das vor 1/2 Jahr intensiv angesehen. Zumindest für Neueinsteiger gibt es mittlerweile deutlich Einfacheres/Komfortablers für HA. Für Nerds ist es sicher gut geeignet und Dank Langzeitprojekt sehr funktionsreich. Heutzutage wollen die Leute jedoch SCHNELL zum Ziel kommen.

Ich sehe eher, dass oWB das HA-Feld von hinten aufrollt. Smarthome 2.0 wird sicher mit oWB v2.x weiter voranschreiten, dann auf Python basierend.

Grüße ins FHEM-Forum!

[derNeueDet]

Aiole,

Da muss ich jetzt widersprechen. Ich setze auch FHEM ein und die Flexibilität bei der Kombination von unterschiedlichen Hardware Komponenten ist dort echt enorm. Es gibt ne Menge Features, die in Smarthome 2.0 noch nicht in Sicht sind. Aber es kommt einfach drauf an, ob meine Rollläden morgen und abends an Hand bestimmter Merkmale fahren sollen, oder ob ich mein Auto und die Wärmepumpe an Hand der PV Leistung optimieren will.

Daher werkelt bei mir eine Standard+ in der Garage und FHEM macht den Rest inklusive Alarmanlage, Aussenlicht, vernetzte Rauchmelder...

VG
Det

[aiole]

Det - ich bezog das nur auf NEUEINSTEIGER, die sich mit Perl sicher schwertun.
Echte Progger wie Du haben damit kein Problem.

Ich will nicht abdriften, aber IOBroker, HomeAssistant und ein paar andere haben doch einen deutlich moderneren Unterbau mit besserem Ausbaupotential. Bei der Modulmenge hängen sie FHEM noch hinterher (wie Smarthome 2.0 in openWB). Mit v2.x sollte es sich lohnen, mehr SH in oWB zu integrieren.

ps
Mein SH ist aus 2006, läuft mit einem Beck-IPC 24/7, hat ein web-gui und ist in C geschrieben. Konservativer geht's fast nicht mehr . Ein re-write würde ich aber nicht mit FHEM anfangen.

[FosCo]

Performance und Nachvollziehbarkeit spricht allerdings auch für FHEM (der schön über MQTT meine openWB Daten aufs Display schmeißt).
Die steile Lernkurve dagegen.
Ist nun aber wirklich OT

On Topic: werde auch weiterhin openWB empfehlen, grade erst passiert, da jemand 2 Heidelberg hängen hat und ne Lösung sucht, die mit dem dummen ksem zu verbinden für PV Überschuss.
Lastmanagement können die untereinander selbst.
Das wird natürlich erstmal nen raspi gebastel, aber wenn es läuft wird's vielleicht ne Standalone, mal sehen.

Das schicke Einzel-Display gibt es nicht mehr, oder?

[philipp123]

Nur mal so - als rel. neuer Gast hier - meine bescheidene Meinung:

ElektroMotor hat meines Erachtens hier viewtopic.php?p=44753#p44753 eine gute Beurteilung des Themas geschrieben.

Das Argument von openWB bzw. Kevin ist für mich hinsichtlich Produkt Standalone und Support-Aufwand nachvollziehbar, aber auch anders lösbar.
Allein die Diskussion wie damit umgegangen werden sollte und was nun daraus wird, finde ich persönlich als absolut unschön für openWB als Firma, als Open Source, als Community.

Die Begründung der Funktionsbeschneidung über Software (und nicht nur im Produkt, wo man das auch über Dokumente hätte regeln und auf Anwendungsfälle beschränken können) ist m.E. nur ein Vorwand, Fremd-WB's nicht mehr zu unterstützen um das Produkt openWB stärker zu vermarkten.
Da solltet ihr - offensichtlich kommerziell getrieben - doch vielleicht erwägen, ob ihr 2.0 nicht Closed Source macht und euer Produkt umbenennen.

Ich hoffe, dass ihr die künftige Weiterentwicklung auf der Produktseite gut kommuniziert, da viele auf die openWB gerade wegen der Vielzahl ihrer Schnittstellen inkl. goE aufmerksam gemacht wurden. Dummerweise wurde dies anderen goE-Nutzern in etlichen Foren und leider zuletzt auch durch mich, als tolle Steuerungslösung empfohlen.

Leider hab ich diese Sommerupdate-Threads hier erst jetzt gelesen - nachdem ich dummerweise vor paar Tagen gespendet hab (zum Glück zunächst nur 50€) und geplant hatte, einen Bastel-Pi für 2 goE schön in ein Gehäuse zu packen und laufen zu lassen - mit den Perspektiven nun nicht mehr (im Forum hier demnach Kategorie "Billigheimer", hätte aber auch gern mitgewirkt , und sei es per Spenden oder Code).
Und da hatte ich mich gerade noch geärgert, im Herbst 2020 einen 2. goE statt einer openWB gekauft zu haben - was für ein Glück im Nachhinein!
Die goE hatte ich aber gekauft, weil ich sie über ihre API super in die vorhandene, sehr umfangreiche Hausautomatisierung Fhem einbinden konnte!
Also für mich: zurück zu PlanA und @ all zufriedene goE-Nutzer: kommt mit zur Open Source Hausautomatisierung Fhem (auch z.B. nur ein Pi) und lasst uns dort eine nicht kommerziell getriebene Lösung für PV-Ladung, Lastmgmt. und Loadsharing für die goE fortführen - die wesentliche Basis ist bereits da (es gibt es viele Module für EVU, PV, Speicher, SoC und vor allem noch viel viel mehr zur Hausautomation)...

Hast du mal darüber nachgedacht, in wievielen Foren so ein Beitrag akzeptiert worden wäre? Vielleicht, da viele aktive zufriedene Nutzer und Mitwirker sich davon einfach nicht aufwiegeln lassen? Also viel Spaß dir mit FHEM.

[Smove]

Hallo Zusammen
Gibt es denn schon einen Termin, wann die Beta zum Testen zur Verfügung steht?

VG Tobias

[Bugi]

OK, wenn ich eine Fremd-WB autark betreibe und z.B. 22 kW für die beiden WB freigegeben bekommen habe und/oder eine Begrenzung am Bezugspunkt, dann kann die oWB aber einen eingestellten Wert am EVU-Punkt berücksichtigen und den oWB-LP entsprechend regeln, richtig?

Ich hoffe sehr, dass sich die VNB mehr in die Richtung entwickeln, eine Begrenzung am Bezugspunkt vorzugeben und zu akzeptieren. Gerade für alle mit PV wäre das wünschenswert und nur logisch. Das ist aus meiner Sicht auch ein wesentliches Plus von oWB, das bislang noch gar nicht so zur Geltung kommt. Denn viele andere können ja nur ein Lastmanagement der WB untereinander, nicht aber die Begrenzung am Bezugspunkt.

Kurze Bestätigung: mein VNB, StromNetz Berlin, hat das neulich so akzeptiert. Ich habe zuhause ein oWB und cFos Wallbox. Ursprunglich hatte ich vor letzteres vom oWB steuern zu lassen, aber ich habe bisher weder Zeit noch Anlass rauszusuchen wie ich das einzustellen hätte.
Da er aber standardmäßig auch selbst Lastmanagement und alles erdenkliche an Standards unterstützt habe ich also nun 2x11kW mit Begrenzung auf 11kW am Übergabepunkt beantragt (d.h. unabhängig voneinander) und das ist genehmigt worden.
Leider nicht die schönste Lösung, aber machbar.