Adaptives und KI gestütztes Energiemanagementsystem auf Basis von OpenEMS

Wir alle haben die unterschiedlichsten Komponenten im Hause, welche zum Großteil auch über gängige Schnittstellen verfügen. Nun steht man vor der Wahl, kaufe ich alles bei einem Hersteller und erwerbe gleichzeitig (H)EMS mit, wodurch man die Flexibilität bei der Komponentenwahl verliert oder man wechselt auf ein OpenEMS Projekt, welches die Flexibilität zwar aufrechterhält, allerdings nicht immer einfach zu bedienen ist.
Bei meiner Recherche im Internet bin ich auf das Open Source Projekt OPENEMS gestoßen, dieses bietet nahezu für alle bekannten Hersteller eine Schnittstelle für die unterschiedlichsten Komponenten.
Hier eine kurze Auflistung der Komponenten, welche angesteuert werden können:
Wechselrichter (hybrid + konventionell),
Dynamische Stromtarife (Tibber...),
Batteriespeicher (Haus + V2G),
Wallboxen + Lastmanagement,
Stromzähler,
Wärmepumpen (SG-Ready + On-Off),
Wettervorhersage (Solarertrag),
Schaltrelais für weitere Verbraucher oder auch Energieerzeuger.
Also die Bandbreite der Komponenten ist extrem groß und all diese wollen intelligent gesteuert werden.
Nun hoffe ich, dass wir über die Community ein intelligentes System auf die Beine stellen können, welches auch von jedermann zu bedienen ist und sich dynamisch an Veränderungen und Gewohnheiten anpassen kann. Das aktuelle System arbeitet mit festen Regeln, welche erst ermittelt und einprogrammiert werden müssen.
Die meisten Personen wollen sich nicht so tief in die Materie einarbeiten und ich bin fest davon überzeugt dass es Möglichkeiten gibt die Gewohnheiten über den Stromverbrauch intelligent zu erfassen und entsprechende Regelparameter dynamisch abzuleiten.

Hier ein paar Beispiele:
Lade ich Abends meinen Batteriespeicher/Auto über die dynamischen Stromtarife voll oder nur zu einem Teil, weil nach den Vorhersagen das Wetter schön wird und ich im Homeoffice arbeite.
Ist es sinnvoller die Wärmepumpe über den Stromspeicher zu betreiben ober macht es Sinn an bestimmten Tagen mit der Öl-/Gasheizung zu arbeiten.
Wenn ich den Strom für einen sehr günstigen Preis bekommen, macht es evtl. Sinn die Wärmepumpe einschalten und die Energie im Haus (Estrich oder Pufferspeicher) zu speichern.
Wie voll lade ich mein Auto, denn an gewissen Tagen bekomme ich tagsüber den Strom fast kostenlos (nur über dynamische Stromanbieter) und kann somit den Rest nachladen

Also die Einsparmöglichkeiten über ein intelligentes HEMS sind enorm und ich hoffe das Interesse bei einigen geweckt zu haben und unterstützen dieses Vorhaben.
Besten Dank

1 „Gefällt mir“

Ich wundere mich schon lange, warum das Projekt OpenEMS so wenig Beachtung findet. Ich hab mir das mal runtergeladen und den Code angeguckt. Wenn ich auch noch nicht komplett durch gestiegen bin, finde ich die Architektur aber durchaus überzeugend. Vor allem auch wegen Java und der durchgängige objektorientiertheit in der gesamten Struktur. Es sind sozusagen die Hauptstrukturen implementiert, so dass man die angeschlossenen Geräte, wenn es denn noch nicht programmiert ist, leicht von Interface und abstrakten Klassen ableiten kann. Ich persönlich halte diese Vorgehensweise für deutlich weitsichtiger als einen Drahtverhau in Node Red zu bauen. In OpenEMS muss, man sich natürlich an die Infrastruktur des Konzepts halten, da steckt aber auch schon eine enorme Entwicklungsarbeit drin. Irgendwann geht es immer um konkurrierende Prozesse, denen je nach Wichtigkeit Prius zugeteilt werden müssen. Das ist eigentlich immer das gleiche. Diese ganzen Wechselrichter mit ihren Portalen bilden immer nur diese Balkendiagramme ab. Die Daten liegen auf irgendwelchen Servern, und es ist immer ein Problem mit den Protokollen und artet letztendlich im gebastelt aus. Mit OpenEMS könnte sich durch aus eine elegante Möglichkeit auftun, ein komplettes Framework von einfachen bis zu komplexeren Anforderungen zu benutzen. Nach meiner Einschätzung sind die Anforderungen an eine Energiemanagement lange nicht so unterschiedlich, wie es immer dargestellt wird. Es ist ja eher wie ein Mini Betriebssystem. Mich hat auf jeden Fall umgehauen, das ist ein Open Source Projekt dieser Größen Ordnung überhaupt in Deutschland zu diesem Thema gibt. In Süddeutschland scheinen schon einige Firmen das als Produkt zu vermarkten. Ich will mich damit auf jeden Fall weiter beschäftigen und auch mal versuchen ein Adapter für meine Heidelberg Energy Control zu schreiben. Vielleicht kann man sich darüber ja mal austauschen.

ja, drei mal darfst du raten!

Weil die meisten Plug-and-Play wollen. So wie das aktuell gestaltet ist, zielt das, mit einem ganz engen Focus, auf bestimmte "User-Gruppen".

Ich habe mir nur mal die Seite "Getting Started" aufgemacht und hatte nach der Hälfte der Seite schon keinen Bock mehr OpenEMS auszuprobieren!

Und prinzipiell bin ich für sowas schon sehr offen!

1 „Gefällt mir“

Für größere Installationen sicher sinnvoll, aber für Heimanwender ist die Überschneidung mit Home Automation Systemen einfach viel zu groß. Ein EMS gehört meiner Meinung nach ins HAS. Persönlich nutze ich Home Assistant, da ist das Energy Monitoring schon recht gut, die Steuerungsmöglichkeiten aber nur simpel. Dinge wie, Poolpumpe läuft nur mit Solarüberschuss, oder Wärmepumpe an und Gasheizung aus sobald der Akku voll ist kann man dort recht einfach konfigurieren.

Komplexere Sachen wie auf dynamische Stromtarife reagieren oder Lernen der Gewohnheiten der Hausbewohner gehen da allerdings (noch) nicht. Ersteres hatte ich schon überlegt einzubauen.

OpenEMS hat einfach bei der Menge der Integrationen keine Chance. Ich habe dort mal reingeschaut und kaum welche von meinen Geräten wird unterstützt. Weder meine Solarwechselrichter, Wärmepumpe, Gasheizung, Strommessgerät sowie Akku. All dies funktioniert in Home Assistant schon, ich musste lediglich ein paar Bugfixes einreichen.

Wenn ich mir dann noch die furchtbare Java Projektstruktur mit 100 top level foldern anschaue und im Code sehe wie Exceptions als Rückgabewerte missbraucht werden habe ich auch keine Lust mehr mir die Usability anzuschauen.

Sehe das genau wie @CHP, was auch der Grund ist warum ich für Home Assistant einen recht einfach einzurichtenden Blueprint + Python Modul geschrieben habe, welches die automatische Steuerung von Geräten (beliebige ein- und dreiphasige Geräte, also auch Wallbox, Wärmepumpe,...) in Abhängigkeit vom aktuellen PV-Überschuss ermöglicht.

Wer es ausprobieren möchte: Code und Anleitung finden sich auf GitHub: ha-advanced-blueprints/PV_Excess_Control at main · InventoCasa/ha-advanced-blueprints · GitHub

Hier noch der dazugehörige Thread im Home Assistant Community Forum: PV / Solar Excess Optimizer: Auto-control appliances (wallbox, dish washer, heatpump, ...) based on excess solar power - Blueprints Exchange - Home Assistant Community

Das Ganze ist ein aktives Projekt von mir und wird momentan alle paar Wochen um neue Features erweitert.

3 „Gefällt mir“

Nice, werde ich mir anschauen. Btw, du empfiehlst Solcast, ich benutze bisher das offizielle Forecast.Solar

Letzteres funktioniert äußerst schlecht. Wie gut funktioniert Solcast? Ich überlege selbst schon eine Kachelmannwetter integration zu bauen, denn deren Vorhersage ist zumindest für 6-16h recht gut. Bei Forecast.Solar ist selbst die aktuelle Stunde oft kompletter Quatsch.

@henry Dein Projekt habe ich schon auf meiner Merkliste. Aber meine Hoffnung geht noch in die Richtung einer machinelearning oder KI-Variante die noch mehr einbeziehen kann.

Ich habe wie der TO auch immer noch die leise Hoffnung das sich etwas in der Richtung tut. Meine Zielsetzung wäre Akku, Auto, Verbraucher von mir aus auch, ins Verhältnis zur Prognose der PV und dynamische Stromtarife zu bringen. Und da wird man regelbasiert leider nicht sonderlich weit kommen fürchte ich.

Das OpenEMS Projekt hatte ich mir auch mal am Rande angeschaut. Aber es war leider ab der Getting Startet Seite uninteressant. Und ich habe auch auf die schnelle die Infos vermisst, was denn diese Regelung jetzt anders macht als z.B. die bekannten OpenWB oder EVCC oder oder oder die es ja schon gibt und die ich um z.B. HA erweitern kann bzw. an mehr anbinden kann. Vielleicht habe ich auch nicht genau genug geschaut oder es verstanden... :smiley:

Solcast funktioniert bei mir sehr gut. Ich habe im Schnitt ca +/- 10% Abweichung ggü. der Vorhersage.

Darüber hinaus kann dir Solcast die Vorhersage der nächsten 5 Tage anzeigen.

@bennyb21 Unter SW-Entwicklern wird schon länger darüber gewitzelt, dass die Buzzwords KI, ML, AI immer als Allheilmittel dargestellt werden, und Leute die nicht so tief in der Technik drin stecken, das auch noch glauben.

Bitte nicht falsch verstehen :wink:

Aber gerade wenn wir über so etwas verhältnismäßig Simples wie Überschuss- und tarifabhängige Steuerung von Verbrauchern für den Heimanwender reden, braucht es hier nicht unbedingt einen ML-Ansatz.

Ich habe versucht die Konfiguration bei meinem Script mittels Blueprint so simpel wie möglich zu halten. Darüber hinaus besteht dank der Integration in Home Assistant der Vorteil, nahezu jedes beliebige Gerät ohne viel Aufwand mit in die Überschussregelung zu integrieren.

Wer also nicht auf eine 100%ige, sondern nur 90%ige Optimierung aus ist und dafür aber gerne innerhalb von wenigen Minuten eine lauffähige Überschussregelung seiner Verbraucher inkl. Wallbox und Wärmepumpe haben möchte, für den ist mein Blueprint/Script perfekt geeignet.

@henry Das habe ich nicht bezweifelt! Und ich finde das auch gut gelöst!

Und dann das böse Aber... :wink:

Grundsätzlich bin ich auch im Bereich der IT-Nahen Softwareentwicklung und kann schon einigermaßen unterscheiden was sinn und unsinn in der Diskussion ist. Und ja. Das meiste ist unsinn und Buzzwording.

Aber dann brauche ich Dir auch nicht erklären, dass das einbringen von zwei weiteren Komponenten in so einer Regelung ne menge verändert. Das übliche Abwickeln der Verbraucher (Auto, WP, Akku) habe ich geregelt. Ich interessiere mich da eher für den nächsten Schritt. Und da befürchte ich kommt man ohne etwas sehr komplexes bzw. lernendes dann auch nicht weiter. Ohne einfache Implementierung von entsprechender lernender Software ist der Aufwand alle Situationen regelbasiert abzubilden dann auch irgendwann sinnlos.

Auch wenn es sich banal anhört, nur noch mal eben einen dynamischen Stromtarif einzubinden. Allein dies sind einige Parameter die zu betrachten sind. Dazu gehört nicht nur min und max Preis zu bestimmen, den Zeitpunkt zu bestimmen und das ins Verhältnis zum Akku-SOC zu bringen, die Effizienz der Ladung und Entladung, also zu bestimmen ob es sich überhaupt lohnt, das ganze zu mehreren Zeitpunkten am Tag usw... Dann kommt noch die Prognose der PV-Anlage. Wetter im allgemeinen, ich möchte ja, dass das System anhand der Wetterbedingungen lernt, dass ich z.B. ab 26 Grad Außentemperatur die Kühlung der WP nutzen möchte. Das kostet x kWh. Bei anderen Temperaturen kommt das nicht in Frage. Im Winter oder der Übergangszeit muss ich den Akku nicht immer voll halten wenn ich nur x kWh benötige für die Heizung. Was macht der Nutzer unter welchen Bedingungen. Das sind halt Sachen, die mit entsprechender Software umsetzbar sind. Die Informationen sind größtenteils ja vorhanden wenn man etwas tiefer in der SmartHome Geschichte steckt. Aber da gibt es derzeit kein mir bekanntes Projekt für. Denn erst dann kann man m.E. wirklich von SmartHome sprechen. Derzeit ist das Thema für mich eigentlich immer noch im Bereich fernsteuerbares nicht mehr ganz so dummes Haus zu sehen, welches massig Daten sammelt, die man über Jahre speichert und doch nicht mehr anschaut/braucht. :smiley: Von wirklich Smart ist da für mich noch nicht viel zu sehen. Und nicht falsch verstehen: Ich spiele auch eine Menge mit dem Zeug herum. Schon seit einigen Jahren. Tatsächliche und echte Fortschritte entdecke ich jedoch nur bei der Sensorik. Wenn ich daran denke, das man damals für die Radarsensoren getan hätte... Heute für ein paar Euro absolut präzise Anwesenheitserkennung und sogar Positionierung im Raum möglich. Und ja, in der Zugänglichkeit und der einfachheit wie das heute möglich ist. Vor 7 Jahren nicht daran zu denken. Aber es gibt für mich bislang noch nicht das "echte" Smart im Home... :wink:

1 „Gefällt mir“

@bennyb21

Was ist denn "IT-nahe Softwareentwicklung"?

Du schreibst

Und da befürchte ich kommt man ohne etwas sehr komplexes bzw. lernendes dann auch nicht weiter
Auf welches Wissen stützt du denn diese Vermutung?
ich möchte ja, dass das System anhand der Wetterbedingungen lernt, dass ich z.B. ab 26 Grad Außentemperatur die Kühlung der WP nutzen möchte
Und was passiert, wenn die vom selbstlernenden System definierten Regeln basierend auf deinem Nutzungsverhalten von dem, was du tatsächlich willst, abweichen? Weißt du, wie du so etwas korrigierst? An welchen Parametern du bei deinem selbstlernenden Modell schrauben musst, damit am Ende möglicherweise vielleicht Regeln entstehen, die eher deinem Nutzungsverhalten entsprechen?

Ohne entsprechendes Wissen wird es dir nicht gelingen, einen selbstlernenden Ansatz so zu parametrisieren, dass er dein Nutzungsverhalten zufriedenstellend in regelbasierte Steuerungen umwandelt.

Genau so wenig wie es Entwicklern aktuell gelingen wird, derartige Ansätze, die das können was du dir wünscht, einfach nutzbar zu machen. Wer sich nicht auskennt, nicht versteht wie ein ML-Modell unter der Haube funktioniert oder die Parameter nicht versteht, wird bei solch einem Anwendungsfall sicher kein zufriedenstellendes Ergebnis erzielen.

@henry Ich habe nicht behauptet sowas zu bauen... Ich hätte sowas gerne... :wink:

Und eben weil es nicht mal eben ist, gibt es das bislang noch nicht. Das ist mir durchaus bewusst.

Hallöchen,

bin jetzt durch Zufall auf den Beitag gestoßen. Weihnachten und der Tratsch mit der Familie hat mich auf das Theme (open)EMS gebracht. Mein Onkel ist jetzt in der PV-Branche und dort werden auch EMS mit verkauft... Wobei er mir auch von einer OpenSource Lösung vorgeschwärmt hat bei der viele Namhafte Hersteller mitwirken. Google hat mich jetzt auf openEMS gebracht...

Ich suche gerade möglichkeiten meinen Batteriespeicher, dynamsichen Stromtarif, PV und LWWP möglichst effizient zu nutzen. Da wäre ja genau das openEMS genau das richtige. Jegliche Automatisation mit Homeassistant oder NodeRed wird nicht an richtiges EMS herankommen.

Es scheint hier auch ein Add-On für HA zu geben: Add-On Fenecon2Mqtt - Connect Fenecon Home (OpenEMS) energy storage systems to Homeassistant - Share your Projects! - Home Assistant Community

Hat sich seit dem letzten Jahr nochmals jemand mit dem Thema (open)EMS beschäftigt?

Also konkret installation und Tests...

Grüße

Benedikt

Hallo,

ich bin leitender Entwickler bei OpenEMS und habe diesen Thread gefunden.

Es ist leider eine Anforderung des Java OSGi-Frameworks (bzw. der bndtools), dass alle Bundles im gleichen Workspace-Ordner sein müssen. Eine Unterordner-Struktur ist nicht möglich. Das sieht leider tatsächlich z. B. bei Github nicht schön aus, ist aber in der Praxis m.E. kein Nachteil.

Können Sie mir ein Beispiel nennen, bei dem Exceptions als Rückgabewerte missbraucht werden? Dann erkläre ich das gerne.

Die Zielgruppe von OpenEMS ist nicht so sehr der Endanwender (wie bei Home Assistant), sondern z. B. Universitäten, Forschungsinstitute und Hersteller von Stromspeichern oder Energiemanagementsystemen. Bei OpenEMS geht es deshalb sehr stark um Skalierbarkeit, Servicierbarkeit, etc.


Die Diskussion zu KI und den anderen Buzzwords finde ich interessant. Das sehe ich nämlich durchaus genauso. :slight_smile:

Ich denke die Frage muss sein, wo man KI einsetzt. Aus meiner (OpenEMS-)Perspektive ist es wichtig klar definierte Schnittstellen zu haben. 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.

Den Quellcode und ein paar Hintergrundinfos gibt es hier: Mehr Freiheit in der Nutzung dynamischer Stromtarife – OpenEMS. Wir arbeiten noch sehr aktiv an dem Code, so dass sich da sicher in den nächsten Wochen und Monaten noch einiges tut.

Gruß,
Stefan

3 „Gefällt mir“

da scheint der begriff architektur irgendwie missbraucht zu werden.

im video "Stromspeicher Hersteller FENECON ist TOP Innovator 2023" spricht der prof von endanwender ...
das beisst sich mit dem satz "Die Zielgruppe von OpenEMS ist nicht so sehr der Endanwender".

ich weiss, softwarearchitektur ist ein problem und jeder will architekt sein.

habe mich lange zeit mit deterministischen systemen beschäftigt.
und ja, java programmierer treiben mich in den wahnsinn ...

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.

OpenEMS ist zwar offen, aber nicht wirklich für "Endkunden" gedacht.

ggf. wäre dann dieses System etwas: GitHub - davidusb-geek/emhass: emhass: Energy Management for Home Assistant, is a Python module designed to optimize your home energy interfacing with Home Assistant.

@henry

wo finde ich das Script?

@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 :slight_smile:

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 :slight_smile:

Und Auslöser: Auto ist angekommen an Wallbox :slight_smile:

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 :slight_smile: und habe ne abneigung gegen Cloud Dienste - möglichts vermeiden...

1 „Gefällt mir“