Erstmal vielen Dank für die tollen Inhalte hier und auf dem YouTube-Kanal. Ich bin ein langjähriger Follower und erfreue mich immer wieder an den wissenschaftlichen Ausarbeitungen, denen es anderen Kanälen, die sich mit diesen Themen auseinandersetzen, meist mangelt.
Ich steuere diverse Verbraucher im Haus schon seit mehreren Jahren intelligent mit Hilfe von Open Source Projekten, bisher allerdings noch im eher kleinen Rahmen. Meine Themen sind da PV+Speicher sowie eine Wärmepumpe. E-Auto haben wir noch keines, weil wir es fast ausschließlich für Urlaub, sprich Langstrecke, benötigen. Dynamische Tarife machen für mich aktuell noch wenig Sinn.
Angefangen habe ich mit Solaranzeige, welches ich an meine Bedürfnisse angepasst habe. Besonders die Überschusssteuerung ist da eher noch rudimentär umgesetzt. Ich war auch bestrebt, etwas an die Community zurückzugeben. Mangels Interesse habe diese Pläne dann wieder verworfen. Kürzlich bin ich auf evcc aufgesprungen. Das konnte auf Anhieb alles, was ich in Solaranzeige reingehackt habe und mehr. Installation und Handhabung sind deutlich einfacher.
Jetzt Frage ich mich, was EOS besser kann oder ob es nicht sinnvoller gewesen wäre, die Kräfte zu vereinen? evcc hat halt bereits eine sehr große Basis an unterstützten Geräten. EOS hat wahrscheinlich eine ausgefeiltere und umfassendere Regelung? Ich muss zugeben, dass ich mir EOS bisher noch nicht angesehen habe...
Ich bin da bei Dir - EVCC diskutiert auch gerade eine prognosebasierte Steuerung immer aber mit dem Ansatz simple to use. Denke letzteres ist auch extrem wichtig, wenn man die "Masse" mitnehmen will. Aktuell ist evcc ja fast nur reaktiv unterwegs bzw. plan anhand des dynamischen Strompreises, aber mit festen Schwellen. Ich habe das mit Victron DESS kombiniert, so dass auch unabhängig von den Schwellen in EVCC der Akku geladen wird wenn die Preisdifferenz über den Tag sagt speichern lohnt sich. Würde aber eine einzige Stelle im System die regelt bevorzugen. EVCC finde ich auch sinnvoll, da sie 14A EnWg und EEBUS kompatible Lösungen implementiert haben/werden.
Evtl. macht es ja Sinn, wenn sich die EOS Versteher mal mit den EVCC Jungs (und Mädels) zusammensetzen und diskutieren ob oder wie man beides bzgl. Prognoseauswertungen verheiraten kann.
Ich bin auch die Meinung dass die EOS Funktionalität besser in weit verbreitete EMS integriert werden soll. Ein Standalone System wird höchstens von uns Nerds gebraucht, und Homeassistant ist kein große Verbesserung.
Ich glaube die meisten Wechselrichter und EMS Herstellern haben dynamische Stromtarif schon auf den Schirm.
Alle beste wäre wenn ein großteil von die bestehende Heimspeicher netzdienlich agieren nach ein "software update". Unsere Beitrag ist dann das Minimale Funktionalität zu spezifizieren, und mit Hersteller kommunizieren. In erste Instanz geht es um den Preissignal zu beachten beim Einspeisung und Entladen. Idealerweise auch wen kein dynamische Tarif benutzt wird.
Ich nutze seit einem halben Jahr EVCC und bin begeistert, besonders welche breite Gerätevielfalt das System unterstützt, gerade in Bezug auf Wechselrichter, Wallboxen und Fahrzeuge.
Ich weiß nicht wieviele Nutzer EVCC hat, die Comunnity die Daten teilt, umfasst über 6500 User, daher denke ich, wäre eine Fusion von EVCC und EOS eine gute Sache, da beide Projekte davon profitieren würden, das EOS müsste nicht alle Systeme neu einpflegen und EVCC könnte von dem prognosebasierten Ansatz profitieren.
Also erstmal danke, dass ihr euch hier engagiert und Gedanken macht. Aber ein paar Dinge, um die ganze Situation etwas besser zu verstehen. Natürlich haben wir auch schon darüber gesprochen und es wird sicherlich auch Kontakt geben. Wir verschließen uns dem absolut gar nicht, es ist ja kein kommerzielles Projekt und in dem Sinne: Gibt's einfach keine Konkurrenz, das wäre völlig albern.
EVCC und EOS tun nicht dasselbe, das wird gerne verwechselt. Man kann evcc in EOS einbinden, aber zusammen programmieren wird schwierig bis unmöglich. Aber die Projekte schließen sich überhaupt nicht aus. Wenn wir soweit sind, adss wir eine gute HomeAssistant Integration haben, dann sehe ich auch eher die Möglichkeit, Gemeinsamkeiten zu finden. Aber das Ziel ist aktuell: Integration in Homeassistent!!! Nicht in evcc und Co.
Auch stellt ihr euch die Verbindung von 2 Software Projekten dieser Größe, viel zu einfach vor. Das klingt auf den ersten Blick immer toll, die Realität sieht da oftmals aber ganz anders aus, das würde uns aktuell nicht helfen, sondern überfordern. Ich weiß, dass denkt man nicht (denn man bündelt ja) aber auch eine Bündelung ist krass kompliziert und wir haben aktuell ganz andere Punkte ->
Der wichtigste Punkt: Wir sind aktuell gar nicht an dem Stand, dass wir über sowas nachdenken könnten, aktuell geht es um sehr profane Dinge, wie Dokumentation, Leute engagen, Code aufräumen, Testen Testen Testen. Aber auch neue Modelle einbauen usw. Aktuell ist ein ganz schlechter Zeitpunkt / würde uns vollkommen überfordern (wir sind 4 Entwickler die regelmäßig daran arbeiten). Es benötigt Leute, die es testen, anwenden, in HA einbinden, mithelfen beim Code, Doku schreiben, anderen erklären wie es funktioniert usw.
Spannender könnten die Anbindungen von OpenEMS sein, aber auch das würde uns aktuell 100% überfordern. Bitte denkt immer daran: Alle machen das in ihrer Freizeit, entsprechend ist sowas zum jetzigen Zeitpunkt nicht machbar.
Die Diskussion ist echt nett gemeint, aber zum jetzigen Zeitpunkt (noch) nicht sinnvoll. Das würde jetzt vermutlich eher zum Stillstand führen und unsere knappen Ressourcen völlig überfordern
Und bitte stellt euch doch auch mal ganz ehrlich die Frage: Habe ich wirklich im Detail verstanden, was wir und auch die anderen Projekte tun, wie sie es tun, wie der Code aufgebaut ist usw. Also bin ich fachlich in der Lage solche Tipps auszusprechen?
@Akkudoktor
Danke für Dein Feedback - also ich glaube nicht, das es hier zwingend um die Einbindung in EVCC geht - eher drum das EOS nicht im from Nerds for Nerds Status hängen bleibt. Integration in "egal" welches weiter verbreitete System damit es mehr genutzt werden kann war zumindest mein Punkt.
Gut EOS ist noch nicht so weit, das verstehe ich vollkommen. Selbst wenn da jemand Vollzeit dran arbeitet ist so etwas nicht mal in ein paar Wochen/Monaten erledigt - geht meist eher um Jahre.
Ich sehe das aus Nutzer Sicht (habe aber SW Entwicklungs Hintergrund) - OpenEMS sieht gut aus, ist es aktuell für Endanwender einfach nutzbar? Vermutlich eher noch nicht, sondern eher an Entwickler/DIY die sich intensive damit bechäftigen wollen gerichtet. Ist quasi der OpenSource Ansatz von Fenecon (FEMS) wenn ich das richtig verstanden habe. EVCC und OpenEMS Integration gibt es ja schon seit längerem, weil was Wallboxen und Speicher angeht EVCC eben schon im Praxisbetrieb bei vielen usern ist. Aktuell hat EVCC ein rudimentäres WB (inkl. 14a EEBUS) Last und Speicherlademangement (keine Prognose nur preisreaktiv). PV prognose nein - es wird nur der aktuelle Überschuss betrachtet (mein stand). Von daher macht EOS in OpenEMS und EVCC in OpenEMS sicher mehr Sinn.
Auf der anderen Seite suchen wir ja auch pragmatische Lösungen, die man möglichst schnell einsetzen kann. Daher die Idee Daten die vorhandene und verbreitete System schon bereitstellen zu nutzen und anders herum Prognosen und steuerinput wieder zurückzugeben. Z.b. über EVCC die Wallbox anzuwerfen oder den Speicher zu füllen, wenn denn so eine Umsetzung einfach zu realisieren wäre. Aber was ist schon einfach. Du hast schon recht, schnell mal ein paar Boxen und Pfeile in ein PPT gemalt macht noch keine funktionierende Implementierung. Wie oft habe ich schon die Fragen gehört "warum dauert das so lange und kostet so viel... muss doch schneller gehen".
Also Logo Fokus erstmal auf die Kernfunktionalität von EOS, dann schauen wie man am besten Infrastruktur einbindet bzw. mit welchem System man sich verbindet/merged. HA ist auch OK (auch wenn ich es noch nicht nutze - historisch noch auf IPSymcon). Alles auf einmal geht eben nicht mit begrenzten Ressourcen.
Naja die einfache Antwort ist: Das hängt davon ab, ob viele mitmachen. Es ist definitiv mein Plan, dass es nicht nur für Nerds nutzbar ist
Wobei aktuell schafft man es auch, wenn man etwas Ahnung von NodeRed/Homeassistant usw. hat. Weiß nicht, ob das noch Nerd ist, wo ist die Grenze?
OpenEMS:
Was OpenEMS angeht, so muss ich sagen: Darüber habe ich sogar schon mit einigen Leuten die involviert sind gesprochen, sehe da aber strukturelle Probleme:
Code / Architektur ist sehr altbacken
Java ist für sowas (in meinen Augen) ungeeignet und wird die Entwicklung einschränken
Das math. Konzept wirkt nicht sehr durchdacht (es ist eher eine Regelung / Steuerung als eine Optimierung) und ebenfalls auf kurzfristige Dinge ausgelegt, aber irgendwie auch nicht so richtig. (zumindest war das mein Verständnis). Rein mathematisch ist die Trennung kurz- / Langfristig in meinen Augen aber essentiell und die wurde in meinen Augen vernachlässigt:
Kurzfristig lineare Optimierung = schneller Code = eher Regelung/Steuerung (nicht sehr weitsichtig) Ausreichend für einfache Systeme/Entscheidungen (E-Auto alleine / Überschussladen oder einfache kurzfristige Probleme)
Langfristig: hochgradig nichtlinear, hohe Parameter Anzahl = sehr komplexe Optimierung = langsamer Code = echte Optimierung die ALLES berücksichtigt und langfristig plant, für dyn. Einspeisung, größere Akkus und Systeme mit E-Auto, dyn. Einspeisung + dyn. Stromtarife + PV und Akku = absolut sinnvoll
Beides gekoppelt: Super interessant
Warum mache ich nicht mit / supporte?
Also ich finde es toll, dass die so früh sowas auf die Beine gestellt haben und es ist auch ein schönes Projekt, aber aus oben genannten Gründen möchte da nicht mit entwickeln/nutzen und glaube ganz persönlich auch nicht, dass das wirklich eine große Zukunft hat.
Es fällt mir aber schwer, das öffentlich auszusprechen, da ich eine große Reichweite habe und dem Projekt auf garkeinen Fall schaden möchte. Deswegen mag ich diese Fragen nicht so gerne. Es kann ja auch gut sein, dass ich mit irre (was ich schön finden würde) und generell ist es super, dass hier etwas getan wird. Denn wir alle wollen letzten Endes nur der Energiewende helfen.
EVCC:
Bei EVCC sehe ich das völlig anders, das ist sehr gelungen, auf modernen Beinen und wird/ist in meinen Augen sehr erfolgreich. Zudem ist das eher unter "kurzfristig" zu sehen und das ist auch sinnvoll und gut. Für viele Leute wird das sogar schon völlig ausreichend sein. Aber von der math. Hierarchie ist eine Integration von EOS in EVCC (in meinen Augen) nicht sinnvoll
Ha auch ein Frühaufsteher (oder hmm nicht überall ist Feiertag)..
Von der Hierarchie her yupp EOS in EVCC passt nicht.
Mir reicht EVCC auch ... fast.
Preisschwellen sind fest - funktioniert nur, wenn auch regelmäßig, ein Niedrigpunkt erreicht wird. Oft Sonntags, wenn entweder stürmisch oder/und sonnig. Jetzt könnte man das manuell immer anpassen, das macht man aber nur am Anfang weil Neugierde und dann lässt man es und verschenkt Potential.
Den Speicher lasse ich deswegen noch mit Victron DESS parallel füllen. Das funktioniert bei mir recht gut (hoher konstanter Verbrauch, keine Einspeisevergütung und großer Speicher) von daher fast nur Faktor Preisdifferenz über den Tag entscheidend ob sich ein Laden lohnt oder nicht. Viele sind mit DESS nicht zufrieden - PV Prognose stimmt oft nicht (obwohl das noch recht einfach sein müsste). Störfeuer durch EV laden etc. bringt es auch durcheinander -> taugt eben für viele nicht wirklich. Will aber keine Diskussion pro/con DESS anfachen.
OpenEMS:
Ich denke auch nicht, dass es sich durchsetzen wird. Nicht zwingend wegen Java als Sprache, Java taugt prinzipiell schon. Setzt aber durchaus eine höhere Hürde für Einsteiger. Python ist ja wieder topmodern (2023 fast schon Hype) für KI, Datenanalyse und ist eine interpretierte Sprache.
Generell ist es aber in OpenEMS komplex die ersten Schritte zu gehen. Evtl. ist auch nur die Doku schlecht um Einsteiger mitzunehmen. Die Architektur hat sich mir beim durchblättern nicht wirklich erschlossen (Doku lückenhaft). Da Prognose vor Jahren nicht wirklich ein Thema war wird das allein historisch bedingt vermutlich nicht so einfach hineinpassen. Vermutlich ist das jahrelang (2017ff) auch nur von 1-2 MA betreut worden von daher ist das was dort gefordert war eben in deren Stil umgesetzt worden (ist prinzipiell nicht schlecht man kommt schnell vorwärts, aber es fehlen Innovationen und andere Meinungen).
Von daher ist eine Integration in ein übergeordnetes und verbreitetes System ala HA vermutlich der aktuell bessere/erfolgversprechendere Weg.
Mein Hauptgrund gegen OpenEMS war eher der math. Ansatz, der mir nicht ganz sauber zu sein scheint und das kann natürlich größere Probleme nach sich ziehen. Optimierung ist ja mein Fachgebiet und ich arbeite ja an einer sehr großen industriell eingesetzten Optimierungssoftware mit. Deswegen habe ich da vermutlich einen anderen Blick drauf.
Am Ende geht es mir aber nur darum, dass meine/unsere Entscheidung nachvollziehbar ist. Ich habe jetzt nicht jede Software bis ins letzte Detail analysiert, aber mir zumindest angesehen und auch Gespräche geführt und natürlich auch in Erwägung gezogen mitzuarbeiten usw.
Aber mein Eindruck war einfach: Da gibt es durchaus noch eine Lücke und die möchte ich gerne füllen.
Hallo Andreas,
das EOS Projekt finde ich total spannend. Aktuell nutze ich ioBroker als Smart Home System und bin damit auch sehr zufrieden, was Darstellungs- und Anzeigemöglichkeiten angeht.
Ich würde mich auch gerne mit einbringen, da ich als Rentner Zeit habe, aber momentan fängt es bei mir schon damit an, dass nicht einmal die Hardware Vorraussetzungen auf Github angegeben sind.
Also wenn Ihr Hilfe von einem nicht Nerd benötigt gebt mir Bescheid.
(auch wenn ich es noch nicht nutze - historisch noch auf IPSymcon). Alles auf einmal geht eben nicht mit begrenzten Ressourcen.