NEWS
Zendure SolarFlow2400 AC (EVCC, Tibber und PV-Forecast)
-
-
Ich speichere mir den Tagesverbrauch in einer influxDB ab. Daraus errechne ich mir den durchschnittlichen Restverbrauch bis Sonnenuntergang der letzten 5 Tage und ziehe diesen dann von der Rest PV-Leistung ab. Mit Hilfe von ChatGPT war das relativ einfach umzusetzen.
-
update auf 2.8
@lesiflo habe da mal was (auf deinen Hinweis hin) mit de Prognose umgestrickt...
Leider ist zur Zeit ja nicht soviel "PV", deshalb dauern die feldtests was länger...
Das mit dem Tagesverbrauche schaue ich mir noch an.... das will ich aber ne Zeitlang testen... -
Ich denke der Ertrag und somit die Gnauigkeit variieren stark.
Unterm Strich kann man die Werte von solarprognose schon gut nehmen, ich teste aber seit einiger Zeit daran, wie umstehende Objekte wie Bäume etc. Einfluss auf die real produzierte Leistung haben.
Ist deutlich kniffeliger als ich dachte, bei Bewölkung sind die Bäume in der Auswirkung eher geringer im Effekt als bei klarem Himmel.
Mit fehlen im Augenblick noch Testdaten für einen groben Überblick.
Da sich die Verschattung ja auch noch im Jahresverlauf deutlich ändert ist das sehr schwer zu interpolieren.
Einen festen Faktor je Tagestunde zu finden ist nicht der richtige Weg, eher anhand von Sonnen-Auf- und Untergang eine mögliche Ertragskurve für die eigene Anlage zu generieren, stundeweise aufzusplitten und in die Solarprognose einzurechnen.Bevor es verwirrend wird... insgesamt ein spannendes Thema.
-
ich bin gerade komplett im flow und habe jetzt eine Prognose auf basis der letzten 14 tage (taggenau)... wonach entschieden wird ob aus dem netz geladen wird oder nicht....
Um das aber nun zu testen, muss ich erstmal daten sammeln ;-)
also denke ich, nen update wird nicht vor Weihnachten kommen.... (aktuell Version 2.22)Ich habe langsam die "angst" das es zuviel ist.... als Backup habe ich ja das Script vor der PV-Prognose... damit war ich eigentlich schon sehr zufrieden
-
Der solarprognose Adapter rechnet falsch wenn der aktuelle Wert größer ist als die Prognose.

-
Der solarprognose Adapter rechnet falsch wenn der aktuelle Wert größer ist als die Prognose.

-
Kleines Update, habe ja schon etwas länger nicht mehr zum eigentlichen thread-topic was gepostet:
Man sieht das Diagramm wie die Akus Laden/Entladen und im Hintergrund die SOC der beiden Akkus,
darunter die Produktivzeiten der Kimas:

Mein script läuft, heute war Schietwetter, morgens schon der akku Ebbe (weil gestern auch Schietwetter war).
Die Akkus haben dann brav geladen, den Start der ersten Klima (Heizung) unterstützt und über den Tag bis zu 3 Klimas parallel am Leben gehalten.
Abends war dann wieder Ebbe in den Akkus.Ergo... ich brauche wohl mehr PV... lol
Habe nun eine schöne Balance mit wenig Relaisgeglacker.
Realisiert über eine:
- Totzone um das Einspeiseziel rum -> weniger Steuerregelungen
- AC-Mode Switch Delay das dynamisch ist. Prüfe off-Loop ob die Zendure beide geschaltet haben und das jeweilige Powersetting annehmen und gebe dann erst die eigentliche Steuerung wieder frei
- eine permanente Überwachung von Soll- und Istwerten beim Laden/Entladen der Akkus -> weniger Steuereingriffe
- Sollten die Akkus mehrere Zyklen von den geforderten Werten abweichen werden Sie per Brute Force in die Spur gebracht während die Dynamik pausiert und dann mit verifizierten Start-Werten anstartet. Ist noch ein alter fail-safe, wird faktich aber nicht mehr getriggert.
- etc.
Integration der Ladesäule und Klimageräte ist in die Akkusteuerung abgeschlossen, dort bin ich auch sehr zufrieden mit der Funktionalitätund Stabilität/Vorhersagbarkeit des Systems.
Todo/Vison:
Das eigentliche Ziel fürs kommende WE ist vollkommen aus einem Timed Loop bei der Steuerung auszusteigen.
DIe Überwachung wird dann auch nur dynamisch nach reinem Steuerbefehl aktiviert werden.
Ziel ist es (Ich kann ja sicher nur ca. alle 15 Sekunden zu regeln(kurze Zwischentakte mit ca. 8 Sekunden sind möglich aber nicht bulletproof in der Ausführung), bei Netzbezug im optimalen Fall schon mehr als 15 Sekunden seit der letzten Regelung zu haben und dann instant und nicht erst im Timer reagieren zu können.
Und bei steigendem LADEN-Potenzial reichen mir eigentlich 50 oder 100 Watt Schritte, ich muss da nicht jedem Elektron hinterhecheln denke ich.Wird aber tricky denke ich, das ganze System dann synchron und ohne flattern zu halten.
Prio sollte sein: Schnell regeln zu können, wenn es anfängt Geld zu Kosten (Netzbezug) und entspannt wenn man lädt.Idz. ist das schon ein relativ üppiges Blockly geworden:

Und das hier beeinhaltet nicht die Änderungen an den Ansteuerungen der Klimas und WB sowie die ganzen Delta/Zeit Wert Berechnungen im Hintergrund.
-
Kleines Update, habe ja schon etwas länger nicht mehr zum eigentlichen thread-topic was gepostet:
Man sieht das Diagramm wie die Akus Laden/Entladen und im Hintergrund die SOC der beiden Akkus,
darunter die Produktivzeiten der Kimas:

Mein script läuft, heute war Schietwetter, morgens schon der akku Ebbe (weil gestern auch Schietwetter war).
Die Akkus haben dann brav geladen, den Start der ersten Klima (Heizung) unterstützt und über den Tag bis zu 3 Klimas parallel am Leben gehalten.
Abends war dann wieder Ebbe in den Akkus.Ergo... ich brauche wohl mehr PV... lol
Habe nun eine schöne Balance mit wenig Relaisgeglacker.
Realisiert über eine:
- Totzone um das Einspeiseziel rum -> weniger Steuerregelungen
- AC-Mode Switch Delay das dynamisch ist. Prüfe off-Loop ob die Zendure beide geschaltet haben und das jeweilige Powersetting annehmen und gebe dann erst die eigentliche Steuerung wieder frei
- eine permanente Überwachung von Soll- und Istwerten beim Laden/Entladen der Akkus -> weniger Steuereingriffe
- Sollten die Akkus mehrere Zyklen von den geforderten Werten abweichen werden Sie per Brute Force in die Spur gebracht während die Dynamik pausiert und dann mit verifizierten Start-Werten anstartet. Ist noch ein alter fail-safe, wird faktich aber nicht mehr getriggert.
- etc.
Integration der Ladesäule und Klimageräte ist in die Akkusteuerung abgeschlossen, dort bin ich auch sehr zufrieden mit der Funktionalitätund Stabilität/Vorhersagbarkeit des Systems.
Todo/Vison:
Das eigentliche Ziel fürs kommende WE ist vollkommen aus einem Timed Loop bei der Steuerung auszusteigen.
DIe Überwachung wird dann auch nur dynamisch nach reinem Steuerbefehl aktiviert werden.
Ziel ist es (Ich kann ja sicher nur ca. alle 15 Sekunden zu regeln(kurze Zwischentakte mit ca. 8 Sekunden sind möglich aber nicht bulletproof in der Ausführung), bei Netzbezug im optimalen Fall schon mehr als 15 Sekunden seit der letzten Regelung zu haben und dann instant und nicht erst im Timer reagieren zu können.
Und bei steigendem LADEN-Potenzial reichen mir eigentlich 50 oder 100 Watt Schritte, ich muss da nicht jedem Elektron hinterhecheln denke ich.Wird aber tricky denke ich, das ganze System dann synchron und ohne flattern zu halten.
Prio sollte sein: Schnell regeln zu können, wenn es anfängt Geld zu Kosten (Netzbezug) und entspannt wenn man lädt.Idz. ist das schon ein relativ üppiges Blockly geworden:

Und das hier beeinhaltet nicht die Änderungen an den Ansteuerungen der Klimas und WB sowie die ganzen Delta/Zeit Wert Berechnungen im Hintergrund.
-
@schimi
So, erste Versuche mit dem Skript,- Eine kleine Verbesserung (zu faul an 10 Stellen zu ändern):
var basePath= "mqtt.0"; var baseID= "ID"; const IDs = { // --- HAUPTZÄHLER (Pflicht) ------------------------------------------------------ // Muss ein Number-Wert sein. Positiv = Netzbezug (Kauf), Negativ = Einspeisung (Verkauf). netz: "Zaehler, // --- ZENDURE MQTT (Pflicht) ----------------------------------------------------- // Diese Pfade finden Sie im MQTT-Adapter unter Ihrem Zendure-Topic. acMode: `${basePath}.Zendure.select.${baseID}.acMode`, // Liest Modus acModeSet: `${basePath}.Zendure.select.${baseID}.acMode.set`, // Schaltet Modus currentInput: `${basePath}.Zendure.number.${baseID}.inputLimit`, // Liest Ladelimit inputSet: `${basePath}.Zendure.number.${baseID}.inputLimit.set`, // Setzt Ladelimit currentOutput: `{basePath}.Zendure.number.${baseID}.outputLimit`, // Liest Entladelimit outputSet: `${basePath}.Zendure.number.${baseID}.outputLimit.set`, // Setzt Entladelimit soc: `${basePath}.Zendure.sensor.${baseID}.electricLevel`, // Akkustand in %-
Multiple Konverter sind noch nicht unterstützt?
Hab die ja um die 2400W max Lade und Entladeleistung zu umgehen, da ist dann eine Nacheinander Lösung doof, das sollte schon parallel laufen
(Wobei ich noch schauen muss wie das läuft da ich noch keinen Elektriker da hatte unterschreibt das ich es sauber auf 2 Phasen einspeise) - mag ggf eine Fehlersituation sein die auftaucht - wobei ja pro Konverter 2400 gehen sollte und das System die Gesamt Upload Rate von 4800 nicht sieht... -
Muss mal logging aktivieren damit ich nachvollziehen kann was es gerade tut - es schwankt gerade immer um den Eigenverbrauch rum, zu diesig...
-
Hat jemand eigentlich ein Möglichkeit gefunden die Dinger sauber auszuschalten wenn man sie nicht braucht (Akku auf minimum)? Die idle Entladung ist ja nicht gerade wenig (1% ohne Heizung), da wäre es sicherlich besser die Dinger einfach aus zu machen, aber stromlos funktionier irgendwie nur manchmal...
Hab da Shelly's Sv3 dran gepackt, die könnte ich schön einbinden/einschalten wenn Solar den Eigenverbrauch übersteigt...
-
- Das ist eine sehr gute Idee (habe ich angepasst)
- ne, ich hab nur einen, somit wäre das testen recht schwierig
keine anung ob es so funktioniert.
Funktionsweise: Ist Batterie A leer (0%), liefert sie 0W. Der PI-Regler merkt "Oh, reicht nicht" und erhöht die globale Anforderung, wodurch Batterie B&C mehr liefern müssen. Das System regelt sich also selbst aus.
-
Das widerspricht aber der Idee das man 2/3 Geräte hat um die maximale Einspeise/Abgabe Leistung zu erhöhen. Eigentlich müssten beide/alle 3 immer als Gruppe geregelt werden (also 50%/33%) der Gesamt Ladung/Ausgabe pro Gerät.
Eine gruppenbasierte Aufteilung sollte auch "trocken" relativ gut entwickelbar sein, hast halt ne Gruppe mit einem Gerät die dann 100%/1 der Eingabe/Ausgabe-Anforderung abdeckt.Theoretisch mag es auch Leute mit mehr als 3 Geräten geben (was ja technisch kein Problem ist solange sie an unterschiedlichen Sicherungen hängen), aber das wäre denke ich erstmal nur ein relativer kleiner Teil.
Andere Frage: warum ist denn SetSmartmode nicht bei Dir mit drin? Ich meine ja man kann auch das andere Skript nehmen, aber du pollst / setzt ja eh schon regelmäßig da wäre das doch kein Thema...
Und hast Du mal den idle Stromverbrauch betrachtet? Hatte ja im Adapterthread über Shelly's gesprochen aber habe natürlich keine Ahnung ob das gut oder schlecht für den Akku ist, wenn man versucht, ihn per Stromweg auszuschalten - und wann er denn wirklich aus geht (minSoc?) Hab Zendure gefragt aber noch keine Rückmeldung bekommen...
-
schau mal in den Spoiler... das müsste funktionieren...
ich will dieses Script so einfach wie moglich halten...
ich lasse das von maxclaudi auch seperat laufen, eine Fehlerauelle weniger und wenn er was optimiert, kann man es direkt nutzen.
Ich habe noch was "größeres" in der Pipeline (ist gerade im test).... das konnte entweder total speziell auf mich zugeschnitten oder richtig gut fur alle sein, sobald es veröffentlicht ist.
Würde dann mit dem Zendure ZENKO konkurieren....
Die aktuellen tests sind schonmal positiv
-
Ok, dann muss ich mal schauen wie man das das eigentlich Set macht...
Re neue Version - Beide Zendures schreiben in den gleichen MQTT Zweig (mqtt.0.Zendure.sensor.HOXXX) und unterscheiden sich dann nur bzgl ID
// --- HARDWARE LIMITS (ZENDURE HUB) ---------------------------------------------- MAX_CHARGE_W: 2400, // Maximale Ladeleistung (Hub 2000 = 1200W, Hub 2000 Dual = 2400W) MAX_DISCHARGE_W: 2400, // Maximale Entladeleistung ins HausnetzIst das pro Gerät oder Total?
Hardware limit klingt nach Gerät, "Entladeleistungs ins Hausnetz" nach Gesamt;)