ElabNET Technik Forum

Hallo zusammen,

der Thread-Titel hat euch möglicherweise neugierig gemacht und hergelockt, aber ich muss leider mit einem kleinen Disclaimer beginnen:
Es gibt noch nichts und Ich weiß auch nicht, wo dieser Thread hinführen wird. Es sieht derzeit nach einer TWS-Logik aus, aber es ist noch unklar ober das ein sinnvoller Weg ist und wie gut das funktionieren wird.

Ich habe mir in einer Mischung aus Neugierde, Energiewandel-Aktionismus und Katastrophenvorsorge (Notfall-Stromreserve) einen kleinen AC gekoppelten Batteriespeicher mit Schuko-Stecker gekauft (Zendure SolarFlow 2400 Pro). Das Gerät kann nach der Erstinbetriebnahme dauerhaft ohne Hersteller-Cloud betrieben werden. Und ich möchte natürlich schon aus Prinzip raus aus der propietären Cloud und selber die Kontrolle haben. Der andere Grund ist, dass ich am Stromzähler einen Lingg&Janke D0-Lesekopf habe, die mir die Messdaten auf den KNX-Bus sendet. Soetwas wird natürlich von der Cloud/App nicht unterstützt. (Tatsächlich könnte auch einen Ecotracker benutzen, der soll sogar lokal mit dem Zendure reden können. Aber ich stelle mich mal der Herausforderung mit den bestehenden Geräten zu arbeiten ).

Wenn man die Batterie offline betreibt, muss man sich jedoch selber eine Steuerung überlegen/bauen. Die Kommunikation, d.h. das Senden von Betriebsdaten und die Steuerung der Lade-/Entladevorgänge erfolgt über eine lokale MQTT-Schnittstelle. Das Gerät sendet Ladezustand, tatsächliche Leistung (in/out) sowie einige weitere Betriebsparameter.

MQTT-Datenpunkte (siehe auch hier: viewtopic.php?f=81&t=6038): Die Steuerung erfolgt durch Vorgabe von Lade- oder Entlademodus, sowie der gewünschten Lade- bzw. Entladeleistung. Um die Einhaltung der eingestellten min. /max. SOC kümmert sich das Gerät selber. Eigentlich recht überschaubar.

Welche Möglichkeiten habe ich nun die Batterie zu steuern? Für die zuküngtige Entwicklung des TWS ist "Energiemanagement" definitiv ein Ding, aber nach meinem Stand steht da noch nichts unmittelbar bevor. Ich habe mich daher im Internet umgesehen und folgende kostenlosen bzw. opensource-Ansätze gefunden. - Bitte korrigiert mich, wenn ich etwas falsch verstanden habe oder falsch wiedergebe!

• Für HomeAssistant und ioBroker hat die Communitiy schon Integrationen/Steuerungen entwickelt, aber ich mag diese Smarthome-Systeme nicht und außerdem habe ich ja den Timberwolf.
• EVCC als Stand-Alone Energiemanagement-System sieht wirklich nett aus, fokussiert aber die Steuerung eines zentralen Großverbrauchers (i.E. Wallbox oder Wärmepumpe), alles andere ist (derzeit) nur Beiwerk und eher rudimentär.
• Das Energy Optimization System (EOS) aus der Community mit und um "den Akku-Doktor" ist erst noch in der Entstehung. Nach meinem Verständnis steht da derzeit eine simulationsbasierte Optimierung von Steuerungsvorgaben im Fokus, nicht die tatsächliche Steuerung und Schnittstellen als solche. Die Lösung ist wohl derzeit auch noch nicht einfach zugänglich.
• https://openems.io/ scheint mir eher ein FrameWork/Abstraktionebene zu sein und professionelle Entwickler/Integratoren zu adressieren

Habe ich etwas übersehen? Kauf-Software, Abos oder propietäre Lösungen möchte an dieser Stelle für mich ausschließen. Daher kam ich zu dem Schluss, dass ich wohl eine Lösung mit der Logik des TWS versuchen müsste / könnte / sollte.

Nun bin ich zwar als Hobbyist mit (höheren) Programmiersprachen einigermaßen fit, aber mit der eher Zustands-orientierten Logik des TWS werde ich nicht so recht warm. Das bedeutet zwei Dinge:

• ich muss meine Anforderungen an eine mögliche Batterie-Steuerung stark herunterschrauben (z.B. keine prognosebasierte Steuerung, nichts selbstlernendes)
• und ich werde trotzdem noch Hilfe von euch und / oder einer KI brauchen (siehe erste Versuche hier: viewtopic.php?t=5822&start=210#p63887)

Grundsätzlich soll die Batterie tagsüber Stromüberschüsse einspeichern (statt diese ins Stromnetz zu speisen) und nachts die Grundlast decken (statt den Strom aus dem Netz zu beziehen). Meine PV-Anlage ist mit 16 kWp recht groß und die Batterie mit 5,7 kWh eher klein. Mir ist klar, dass ich bei diesem Verhältnissen lediglich die Spitzen etwas kappen kann und mit 800W Entladeleistung betreibe ich auch weder den Herd noch die Wärmepumpe, schon gar nicht im Winter. Aber darum geht es mir auch gar nicht. Wenn ich mit der Batterie die Mittagsspitze kappen und in ~ 75% des Jahres die nächtliche Grundlast decken kann, wäre ich schon sehr zufrieden. Gemäß meinen Daten sollten 280 Zyklen/a machbar sein.

Eine weitere Herausforderung für meinen Anwendungsfall ist, dass die aktuellen Leistungsdaten am Netzanschluss aufgrund der Messung über KNX nur mit einer eher geringen zeitlichen Aktualisierungsrate vorliegen. Der Lingg&Janke Lesekopf, bzw. das Gateway kann die Leistung nicht "on Change" senden, sondern nur im festen Zeitraster. Auch wenn 10s technisch möglich sind, konnte ich mich bisher nur zu 1 Min durchringen um den BUS nicht zu überlasten. - Ob das sinnvoll funktioniert? Keine Ahnung. Aufgrund der Größenverhältnisse kann ich tagsüber locker eine moderate Überschusseinspeisung anstreben und trotzdem die Batterie laden und nachts muss ich ohnehin Strom beziehen (sobald die Heizung läuft). Fall ein engerer Takt unungänglich ist, kann ich immer noch z.B. auf den Ecotracker wechseln und die Daten via MQTT an den TWS und dann von dort gefiltert (wenn überhaupt) auf den KNX-Bus senden .

;tldr
Der nächste Schritt ist nun die Anforderungen und ein Konzept für die Steuerung des Batteriespeichers zusammenzustellen.
Bestenfalls führt das Vorhaben zu einer (einfachen) universell verwendbaren Batterie-Steuerung die mit jedem System genutzt werden kann, das irgendwie mit dem TWS redet (Modbus, MQTT, REST-API, ... . ). Ich bin überzeugt: der TWS als Multiprotokoll-Server kann im Bereich des Energiemanagements riesige Vorteile ausspielen, weil man alles mit allem vernetzen kann. Und wenn die hier entwickelte Lösung nur eine rudimentäre Übergangslösung wird, dann wäre das auch fein.

So, in anbetracht der Zeit Schluss für's erste

VG Stefan

So lange Du keinen dynamischen Stromtarif hast, kannst das ganze Recht simpel halten.

Die rechnest einfach aus wievele Stunden dunkel wirst haben, wie voll ist der Akku und dann teilst das ganze und vergleichst mit einem durchschnittlichen Grundlastverbrauch in der Nacht. Wenn die Zahlen gut zueinander passen, dann einfach an Dinkel das als fixe Entladeleistung nutzen.

Mit den 16kWp wird man schon einige Monate Autark hinbekommen. Mit 800W und 5,7 kWh ist man natürlich schon gut eingeschränkt. Kommt aber auch auf den individuellen Verbrauch an. Bei mir sind 5,7 kWh im Winter ein Drittel des Tagesbedarf an Strom, Tendenz steigend.

Wenn Du mit dynamischen Strompreisen agieren willst, dann solltest im Winter aber eine andere schnellere Quelle für die Verbrauchswerte haben. Dan kannst den Speicher zur Abdeckung der teuren Preisphasen nutzen. Aber im Winter ist es eine deutlich geringere Schwankung am Strompreis. Hier musst mal noch auf das genauere Prozedere nach §14a warten, wenn man für so einen Speicher im System reduzierte Netzentgelte geltend machen kann und sich dann ggf auch im Winter Abitrage lohnt. Auch dérzeit im Sommer klappt das nur selten, dass der Börsenpreis um mehr als die Netzentgelte am Tag schwankt.

Die beste integrierte Lösung für gerade solche eher kleinen Speicher wird wohl noch das EOS sein auf kurzer Sicht. Die Kollegen sind ja auch dabei die Balkonalanlagen mit eher kleinen Speichern möglichst effizient zu betrieben.

Im größeren Stil braucht es mehr als ne Wama und Geschirrspüler zur individuellen Steuerung, dann aber gern auch mehr als die 800W Ausgangsleistung.

Einen dynamischen Stromtarif gibt es nicht und ich würde mich da auch eher nicht drauf einlassen. Wenn der Strom günstig ist, habe ich sehr wahrscheinlich selber genug.

Den Gedanken den mittleren Verbrauch in der Nacht zu berechnen und die Entladerate danach einzustellen hatte ich auch. Aber wenn man den "echten" Grundverbrauch ansetzt ist der so niedrig, dass die Batteriekapazität wahrscheinlich nicht ausgenutzt wird.
Bei uns sind das z.B. ca. 185W. Dazu kommt dann als quasi-Grundlast Mehrverbräche durch höhere Lüftungsstufe (+ 35W) , Entfeuchtung (+ 275W) und WP-Kühlung (+ 200W), sodass der Nachverbrauch auch bei 700 W liegen kann. Am Abend spielen natürlich noch Beleuchtung, Rechner und sonstige Verbraucher eine Rolle.

Eine statische Entladeleistung scheint mir daher keine gute Idee. Es sollte möglichst viel Strom aus der Batterie genutzt werden können, ohne Gefahr zu laufen ins Netz zu speisen (unnötiger Verlust). Meine Idee wäre daher eine Entlade-Steuerung auf einen minimalen "Restbezug" von vllt. 30 W anzustreben. Dann führen zeitweise Reduzierungen im Strombezug nicht direkt zu einer Einspeisung.
Bei einem Anstieg des Stromverbrauchs sollte die Entladeleistung dann verzögert/gedämpft ebenfalls erhöht werden. Gedämpft deshalb, damit falls die Messung gerade bei z.B. nachheizender Herdplatte erfolgt, die Entladeleistung nicht auf max. gedreht wird und danach zu viel Überschuss besteht sobald die Herdplatte wieder austaktet. Reduzierungen der Entladeleistung würde ich ohne Verzögerung umsetzen.

Im ungünstigsten Fall kann es dann zwar immer noch passieren, dass z.B. die Messung immer dann erfolgt, wenn die Herdplatte gerade für 5s Sekunden nachheizt. Aber okay, das ist halt ein Nachteil des geringen Messintervalls bei uns und prinzipiell nicht effizient lösbar. Mein Ansatz wäre daher mit einer unversellen Steuerung das Beste rauszuholen was geht - und wenn das bei mir nicht zufriedenstellend ist, dann muss ich den Lesekopf halt ersetzen.

Ich messe es bei mir mit einem shelly 3em und funktioniert wie ich es will.
Ich speise aber nicht wie du ein sondern lasse den negativen Strom sprich einspeisen der einspeise pv die Heizung, Kühlschrank, Steuerung, luftentfeuchter usw einzeln berechnen und lasse es von meiner Insel pv umschalten auf Netz.
Somit wird der inselakku besser geladen und der eingespeiste Strom selber verbraucht.

Ich habe eine Liste mit Anforderungen für die Batteriesteuerung formuliert - was meint ihr?

1. Ziel ist das Laden der Batterie mit überschüssigem Strom einer PV-Anlage. Strom der im Haus nicht verbraucht wird, soll in die Batterie geladen werden. Der überschüssige Strom wird ins Netz eingespeist.
2. Wenn die PV-Anlage keinen Strom erzeugt, soll die Batterie entladen werden. [Anm.: hier bin ich mir nicht sicher, ob das ein sinnvolles Kriterium ist. ICH bekomme die Batterie über Nacht sehr sicher leer. In andern Fällen mag es sinnvoll sein auch bei geringer PV-Erzeugung aus der Batterie zu entladen. Die Wechsel sollten dann aber nicht zu häufig ausgeführt werden um die Schaltrelais im Wechselrichter nicht überzustrapazieren].
3. Die Batterie kümmert sich selber um die Beendigung des Lade- und Entladevorgangs bei den entsprechenden SOC, inkl. einer Hysterese sowie um den Tiefentladeschutz. [Anm: Für universelle Verwendbarkeit könnte es sinnvol sein, das dennoch zu integrieren.
4. Es soll eine möglichst einfache, stabile und nachvollziehbare Steuerung entwickelt werden. Möglichst ohne die Verwendung von Timern. [Anm.: die haben mich beim letzten Skript einige Nerven gekostet].
5. Es liegt die Messung der Leistung am Hausanschluss vor. Ein positiver Wert bedeutet, es besteht PV-Überschuss und wird eingespeist. Ein negativer Wert bedeutet, es wird Strom bezogen. Der Messwert wird jede Minute aktualisiert. Die Logik soll bei Aktualisierung getriggert werden. [Anm.: das Messintervall ist nicht optimal, geht aber erstmal nicht anders.]. Die Änderung der Lade- oder Entladeleistung der Batterie hat Einfluss auf die gemessene Leistung am Hausanschluss.
6. Die Steuerung muss der Batterie den Modus ("charge" oder "discharge") vorgeben sowie die Soll- Ladeleistung bzw. Soll-Entladeleistung. Werden die Werte auf 0 W gesetzt geht die Batterie automatisch in den Standby, der Modus bleibt dabei bestehen.
7. Die Batterie sendet die Ist-Ladeleistung, sowie die Ist-Entladeleistung und den SOC.
8. Es sollen Parameter für die minimale und maximale Ladeleistung und die minimale und maximale Entladeleistung vorgegebenen werden können. Die minimalen Werte sind wichtig für den Wirkungsgrad. Sehr geringe Leistungen lohnen sich nicht, da ist es besser den Strom ins Netz einzuspeisen bzw. von dort zu beziehen.
9. Da der Messwert nur jede Minute aktualisiert wird, sollte eine Überschuss-Einspeisung um einen Zielwert herum angestrebt werden, z.B. 200 W. Kleine Änderungen des Verbrauchs führen dann nicht direkt zu einem Netzbezug. Beim Entladen sollte entsprechend immer Rest-Netzbezug von z.B. 50 W angestrebt werden. Beide Werte sollen einstellbar sein.
10. Um ein zu starkes Pendeln und überschwingen der Steuerung zu vermeiden soll die Anpassung bei zunehmenden Überschuss durch eine verzögerte/gedämpfte Anhebengen der Ladeleistungen erfolgen (bei jeder Triggerung der Logik). Bei einer notwendigen Reduktion der Ladeleistung soll diese aber unverzüglich erfolgen. Bei Netzbezug soll der Ladevorgang pausiert werden, ebenso der Entlademodus bei Netzeinspeisung.
11. Beim Entladen der Batterie soll bei einem steigenden Strombedarf die Entladeleistung ebenfalls verzögert/gedämpft angepasst werden. Bei einer Verringerung des Strombedarfs soll die Reduktion er Entladeleistung unverzüglich erfolgen.
12. Wenn Messwerte fehlen muss die Batterie in den Standby-Modus gebracht werden.

VG
Stefan

sorry war falsch platziert und müsste einen beitrag vorher stehen

ab hier ki text
______________________


"Hi Stefan,

deine Beobachtung, dass die Batterieaktivität den Netzbezug direkt beeinflusst, ist goldrichtig und der zentrale Punkt.

Georg hat mir zur Analyse umfangreiche Shelly 3EM Echtdaten über mehrere Stunden (Tag- und Nachtphasen von 3 Phasen) zur Verfügung gestellt.

Die Nachtdaten zeigen, dass in ruhigen Phasen dein 1-Minuten-Update noch eine brauchbare Informationsbasis liefern könnte. Aber die Tagdaten sind extrem dynamisch: Hier sehen wir massive Leistungssprünge und Richtungswechsel von mehreren Kilowatt – alles innerhalb von wenigen Sekunden.

Meine Analyse dieser realen Daten bestätigt: Bei solch schnellen Änderungen ist eine präzise Steuerung mit einem 1-Minuten-Update nicht zuverlässig umsetzbar. Die Logik läuft den tatsächlichen Ereignissen zwangsläufig stark hinterher.

Daher meine Vorschläge:

1. Priorität: Schnellere Daten. Eine deutlich höhere Messfrequenz (z.B. direkt per MQTT vom Zähler oder einem Ecotracker/Shelly) wäre der Game Changer für eine präzise und stabile Regelung.

2. Kompromiss bei 1 Minute: Wenn die Datenfrequenz nicht erhöht werden kann, musst du deine Erwartungen an die Präzision anpassen. Extrem großzügige Puffer und Sicherheitsmargen sind dann unerlässlich, um die Kernregeln (keine Netzladung, keine Batterieeinspeisung) einzuhalten. Das geht aber zulasten der Effizienz.

Dein neuer Thread zur konzeptionellen Steuerung ist absolut der richtige Schritt, um die Anforderungen unter diesen realen Bedingungen zu schärfen!"

_____________

ki text ende

so heute mal wider mit ki unterwegs gewesen was sehr aufschlussreich war auch für mich
denn
dein vorgehen zur steuerung diverser sachen aber lies bitte

ab hier ki text
___________________

"Hi Stefan,

deine detaillierten Anforderungen sind super aufbereitet!

Ich stimme dir zu, dass eine wirklich präzise und zukunftsgerichtete Batteriesteuerung – wie du sie mit der Dämpfung, aber auch mit den Zielwerten anstrebst – eine enorme Herausforderung für die native Custom Logic darstellt, besonders mit dem 1-Minuten-Takt am Zähler.

Genau für solche komplexen Optimierungen (die über reine Wenn-Dann-Regeln hinausgehen) gibt es spannende externe Lösungen. Hast du dir mal das Energy Optimization System (EOS) vom Akkudoktor angesehen? Du findest es hier: https://github.com/Akkudoktor-EOS/EOS

Das EOS ist explizit dafür gemacht, PV, Batterien, Lasten und mehr zu optimieren – oft auch mit prognostischen Ansätzen. Ich habe mir den Code mal angesehen, und das könnte deinen Zielen sehr nahekommen.

Der Timberwolf ist ja perfekt, um externe Systeme wie dieses anzubinden (z.B. als Container via Portainer) und dann die von dort kommenden optimierten Steuerbefehle in deine Logik umzusetzen. So könntest du die Stärken beider Welten nutzen!

Vielleicht ist das ja eine interessante Spur für deinen neuen Thread. Wenn du da ran gehst, helfe ich dir gerne bei der Schnittstellen-Logik im Timberwolf!"

___________________

ende ki text

Moin,

ich muss hier mal ein Missverständnis in Bezug auf die Preise bei einem dynamischen Stromtarif aus dem Weg räumen.
Die Strompreise schwanken jeden Tag so, dass es fast immer 2 Preistäler pro Tag gibt. In der Regel einmal Nachts und einmal am Tag. Somit könnte man damit die Stromkosten schon weiter optinieren, indem man gezielt bestimmte Verbraucher startet oder den Speicher füllt.

In nutze dafür aktuell Clever-PV.de und bin recht zufrieden.

Es wird eine Prognose (Verbrauch und Erzeugung) erstellt und außerdem der Speicher geschont.
Ich denke, für etwas Gleichwertiges muss man schon recht viel Gehirnschmalz investieren.

Moin zusammen,

das EOS klingt definitiv spannend. Ich habe eine grobe Vorstellung was das macht (allerdings mehr aus einer „wie würde ich das programmieren“ Perspektive), aber die konkrete Anwendung ist mir noch sehr nebulös. Vielleicht hilft es ein Video dazu zu schauen - das habe ich bisher nämlich noch nicht.
Mir ist völlig klar, dass ich mit einer Custom Logik im TWS nur etwas sehr rudimentäres werde umsetzten können. Es ist auch nur als schnelle (naja ist schon wieder aufwändiger als erwartet^^) Zwischenlösung gedacht.

Allerdings: bisher schaue ich alle paar Stunden in der Visu nach den Energieflüssen und setzte die Lade/Entladerate von Hand. Das im Minutentakt sollte mit einer Custom-Logik hinhauen und (um eine Zahl zu nennen) bereits 80% des Optimums erreichen.

Was dynamische Stromtarife angeht… auf der einen Seite mag ich schon die dynamische Preise an der Tankstelle nicht. Auf der anderen Seite macht es in meiner Situation m.E. nicht so viel Sinn. Ich kaufe zur Zeit rd. 4000kWh/a und davon die hälfte im Nov.-Feb.. Die Sommerhälfte kann ich durch Batterien eliminieren. Sicher nicht durch die kleine, aber mal sehen…. Die großen sind leider viel zu teuer wenn man es nicht selber machen kann (ich hab ein Angebot für 10kWh all inkl. für 6000€). Die Winterhälfte an Strom kann ich kaum während weniger Tiefpreisstunden beziehen. Es geht insgesamt dabei um ein risikobehaftetes Einsparpotential von 2000 kWh * (was mag die Preisdifferenz sein?) 0,10 €/kWh = 200€ pro Jahr. Abzüglich dem was ein Smartmeter-Gateway kostet. Das lohnt in meinen Augen den „Stress“ nicht. Da kann ich auch genauso gut an der Börse spekulieren. - Aber bitte lasst uns diese Diskussion hier nicht weiter vertiefen.

Aktuell habe ich eine erste funktionsfähige Logik im Test. Später mehr!

Soo, der erste Test-Tag lief eigentlich ganz zufriedenstellend. Mit dem Wechsel zwischen Laden und Enladen scheint es zwar noch ein Problem zu geben, (das musste ich manuell machen), aber die Aussteuerung klappt eigentlich ganz gut.

Hier der Verlauf am Zähler (rot: Bezug, gelb: Einspeisung):


Und hier der Verlauf der Batterie (X-Achse ähnlich skaliert):


Man sieht die Takte von Kühlschrank, von der Wärmepumpe und ein paar Peaks vermutlich von Herd und/oder Durchlauferhitzer. Die Regelung ist derzeit so umgesetzt, dass Anhebungen von Ladeleistung und Entladeleistung in Schritten von max. 200 W bzw. 100 W pro Logik-Aufruf, d.h. pro Minute erfolgen. Die Reduktion erfolgt unlimitiert. Ich wollte unbedingt auf Timer verzichten, die waren bei meiner letzten Logik-Programmierung sehr nervenaufreibend. Mit den aktuellen Größenverhältnissen meiner Anlage und bei der aktuellen Witterung klappte das ganz effizient (es schien deutlich mehr Sonne als ich speichern kann und ich verbrauche mit Heizung mehr Enerige als die Batterie speichern kann).

Während ich noch den Code fixe, sind mir aber noch zwei andere Fragen zu dem Thema aufgenommen:
1) Kann ich mit dem TWS aus der Leistung die Energie integrieren? Gibt es da eine fertige Logik?
2) Mit wie vielen Daten kann ich die TWS-Zeitreihen "voll-spammen"? Gibt das es irgendwann ein Problem wenn ich minütliche Daten aufzeichne? Es gibt ja afaik keine Lösch- oder Ausdünnfunktion.

VG
Stefan