Hallo,
ich bin leitender Entwickler bei OpenEMS und habe diesen Thread gefunden.
...
Wir haben uns z. B. viele Gedanken gemacht, was einen Speicher ("ManagedSymmetricEss"), einen Zähler ("ElectricityMeter"), eine Ladesäule ("ManagedEvcs"), eine Erzeugungs-/Verbrauchsprognose ("Prediction24Hours"), einen dynamischen Stromtarif etc. ausmacht und wie man Echtzeitregelung ("Controller") gestalten muss. Hier haben wir uns stark an SPS-Steuerungen orientiert (z. B. unveränderliche Prozess-Images während eines Cycles).
In unserer Optimierung für die Be-/Entladung eines Stromspeichers auf Basis dynamischer Stromtarife und Vorhersagen für Erzeugung und Verbrauch nutzen wir auch Methoden der künstlichen Intelligenz. Allerdings nicht selbstlernende Systeme (diese sind wenn dann nur für die Vorhersagen geeignet) sondern Genetische Algorithmen um aus einem riesigen Lösungsraum schnell einen nahe-optimalen Fahrplan zu errechnen.
Die Softwarearchitektur hatten wir beim letzten OpenEMS Hackathon in Göttingen mit den Experten aus der Community diskutiert und dann umgesetzt. Sie ist so designed, dass auch die Beladung (ggf. auch Entladung) von E-Autos, Heizzeiten der Wärmepumpe, etc. mit in den Fahrplan integriert werden können. Bei so komplexen Problemen ist man sonst mit linearer Programmerung und Schwellwerten tatsächlich schnell am Ende.
Ich komme aus der Realtime Embedded Welt und wir programmieren von Kaffeemaschinen, Truewireless Kopfhörers und hin zu speziellen Produktionssensoren und auch Frequenzumrichtern so ziemlich alles für unsere Kunden.
Wir haben erst letztens ein Forschungsprojekt (PV / Speicher / Wallbox ) mit einer Uni und namhaften Komponentenherstellern gemacht. Zum Einsatz kam OpenEms.
Architektur:
Eure Architektur vor allem das Pattern der SPS Zyklen finde ich eigenwillig und in Kombination mit synchronen und asynchronen Datenaustausch kommen da total undetermistische Laufzeiten heraus. Was ja hätte eigentlich durch das Pattern vermieden werden sollen. Ich verstehe euren Ansatz, allerdings hat man in SPSen alle HW-Schnittstellen unter Kontrolle und kann diese sychronisieren. Machen wir auch bei Multiachssystemen im Machinenbau.
Allerdings funktioniert das in PC Systemen halt nur mäßig weil Windows / Linux so nicht "echtzeitfähig" ist. Eurer Ansatz läuft dann allerdings total ins Leere durch die hauptsächlich asynchronen Schnittstellen. Kann man nur durch kurze Zykluszeiten kompensieren, was dann aber wieder die Controller aufwendig macht, weil man "wait cycles" einbauen muss und die CPU Last unnötig steigt. Eigentlich existieren aber auch keine "echte" Regelkreise in den zugrundeliegenden Anwendungen, sondern eigentlich soll nur auf "Events" reagiert werden. Z.B. Wenn Überschuss größer 2kwh dann starte Waschmaschine oder was auch immer. Selbst Smartmeter arbeiten mit 15min Rastern. Oder wenn Speicher 80% dann mach X.
Echte Regelkreise gibt es in der Welt eigentlich nicht. Schon gar nicht mit den Kommunkationsprotokollen die aktuell in der Systemtechnik verwendet werden.
ABS oder ein Motorregler haben sehr strikte harte Timings die eingehalten und der Regelkreis verarbeitet werden muss. Aber dort ist auch in den Protokollen gewährleistet, dass die Daten priorisiert im Netzwerk übertragen werden können. (Profinet, PowerLink, Ethercat, CAN Bus)
Performance:
Genau dieser Ansatz bei OpenEms macht es "energetisch" eigentlich total schlecht. Weil jeder Zyklus gepollt und durchgerechnet werden muss und keine "Events" an andere Komponenten geschickt werden können. Somit muss jeder Controller eigentlich wenn niedrige Latenz gewünscht ist, 99% der Zeit sinnlose Berechnungen machen.
Bei dem Forschungsprojekt hatten wir ziemlich hohe CPU Lasten auf den Servern, obwohl eigentlich nicht wirklich schlimme Berechnungen darauf gemacht worden sind. Auch Webanfragen wurden mal in 3 oder 4 Zyklen später verarbeitet. Auch ganz schlimm, wenn die Anfragen von mehreren Clients kamen, war es sau schwer ohne eine Feedbackschleife die Clients Synchron zu halten.
Evtl habe ich aber irgendwelche Anforderungen noch nicht ganz verstanden und das könnte eure Implementierung durchaus begründen. Bisher sind meine Erfahrungen eher negativ, was man vermutlich doch auch heraushört.
Weil wir bei der Embedded Welt immer Probleme mit Ressourcen (Zeit/Latenz, Genauigkeit, Speicherplatz, Stromverbrauch,usw) haben und dafür aber hohe Anforderungen (Auflösung, 20us Abschaltung, viele quasi parallele Prozesse) sind wir eigentlich weg von diesen Ansätzen, und versuchen dann die Applikationsprozesse hauptsächlich über Events zu implementieren.
Aber da würde mich durchaus der Meinungsaustausch interessieren.
Ich will mir einen zweiten WR von einem anderen Hersteller einbauen und will die Energiebilanzierung und Systemsteuerung (Batterie, WR, Wallbox, Wärmepumpe) in open source herstellerunabhängig realisieren da die Anlage immer wieder um neue PV-Strings erweitert werden soll. Dazu wäre ja eine open source Lösung perfekt. Mich wundert es dass es zu diesem Thema noch nichts brauchbares gibt und hier nicht mehr weiter diskutiert wird.
Ich will mir einen zweiten WR von einem anderen Hersteller einbauen und will die Energiebilanzierung und Systemsteuerung (Batterie, WR, Wallbox, Wärmepumpe) in open source herstellerunabhängig realisieren da die Anlage immer wieder um neue PV-Strings erweitert werden soll. Dazu wäre ja eine open source Lösung perfekt. Mich wundert es dass es zu diesem Thema noch nichts brauchbares gibt und hier nicht mehr weiter diskutiert wird.
OpenEMS ist zwar offen, aber nicht wirklich für "Endkunden" gedacht.
ggf. wäre dann dieses System etwas: https://github.com/davidusb-geek/emhass
@ibe_hf Ich habe mir mal bei OpenEMS mal ein Bookmark gesetzt - aber bei Java bin ich schon raus (auch wenn ich da einiges von kenne) aber bei Automatisierung sollte, finde ich zwei Sachen erfüllt sein:
Kein Cloud
möglichst klein (muss auf rasberry laufen)
Auch wenn mich Homeassistant zur verzweiflung treibt - ist das die Basis auf die ich aufsetzen möchte.
Ob eine Verbauchs forcast Schätzung sinnvoll ist - ich denke mal nein.
Mal ganz Banal wie soll die es denn Ermitteln ob ich Waschen möchte 🙂
Gut bei Wärmepumpe kann ich Schätzen wie der Verbrauch sein wird - aber hilft das weiter ? Meine Wärmepume läuft im Winter Quasi durch ... (MHI-AC-Control / ESPHome)
Der Winter PV Etrag ist nett, aber reicht eh nicht dafür .....
Aber ich könnte auf ein teuren dynamischen Strom Tarif reagieren indem ich zurück auf die Gastherme schalte. (OpenTherm / ESPhome )
Und ich bin alt mir erschliesst sich nicht die KI Notwendigkeit ...
Bei einem Akku sollte bekannt sein der Strompreis und der Ladestand und dann kucken ob der Interne strompreis gesenkt werden kann durch entladen.
Der interne Strompreis = Dynamischen Strompreis * Bezug kwh + PV Strompreis * Erzeugung Eigenverbrauch
Akku Strompreis = Interner Strompreis + Invest Abschreibung (15cent z.B)
Was es Braucht:
Auslöser - will waschen - starte wenn strom am günstigten ist
Für ein BEV noch Option wann muss es fertig/voll sein mit max Ladestrom und dann halt das Laden Steueren - möglichst Preiswert bis morgen um 7 Uhr 🙂
Und Auslöser: Auto ist angekommen an Wallbox 🙂
Bein Solarforcast müsste man ein internen Strompreis definieren - der forcast Ertrag sollte ja bekannt sein - dann braucht es aber auch ne Prioliste der Geräte die Strom ziehen können.
Verkürzt Waschen oder Auto laden ?
Bei der Wärmepume , denke ich, dürfte es reichen den Verbrauch der letzten Stunde als Forecast für nächste Stunde anzusetzen - genauer braucht es nicht sein.
Da einzig KI was ich mir vorstellen könnte ist weniger KI , sondern eher ein Lastverlauf von meiner Waschmaschiene - wann heizt die - mal kurz gefragt - das wäre aber ne banale statistik gefüllt über ein Verbrauchsmesser - meintwegen alle 5 Minuten ...
Aber ich bin auch Alt 🙂 und habe ne abneigung gegen Cloud Dienste - möglichts vermeiden...