NEWS
Zendure SolarFlow2400 AC (EVCC, Tibber und PV-Forecast)
-
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;) -
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;) -
Lol, aber stimmt. Habe ich in der alten Version geschaut;)
Hat soweit ganz gut funktioniert heute, etwas hibbelig um den Break even/ Ladepunkt herum, vlt weil er dann ja auch schon auf 2 aufteilt und dann auch kleine Lichtschwankungen (diesig) schnell unter die Bezugsgrenze fallen.
-
@schimi
Kann ich mit dem Script auch nachladen aus der Steckdose triggern?Sonne ist gerade nicht viel und wie ich gerade gesehen habe hat der extrem hohe idle Verbrauch die Dinger fast leer gesaugt :(

Würde sie ja ausschalten aber es funktioniert nicht (6s Button laut Anleitung, aber peiept nur lang und bleibt an).
Bin kurz davor die Dinger zurückzuschicken wg der Idle Last ... 200W am Tag?????
Ist das bei Euch auch so? Vlt ist es auch nur so schlimm weil die Dinger regelmäßig gepollt werden aber ein embedded webserver sollte nicht so viel verbrauchen :( -
@schimi
Kann ich mit dem Script auch nachladen aus der Steckdose triggern?Sonne ist gerade nicht viel und wie ich gerade gesehen habe hat der extrem hohe idle Verbrauch die Dinger fast leer gesaugt :(

Würde sie ja ausschalten aber es funktioniert nicht (6s Button laut Anleitung, aber peiept nur lang und bleibt an).
Bin kurz davor die Dinger zurückzuschicken wg der Idle Last ... 200W am Tag?????
Ist das bei Euch auch so? Vlt ist es auch nur so schlimm weil die Dinger regelmäßig gepollt werden aber ein embedded webserver sollte nicht so viel verbrauchen :(@Rand ja kannst du.... über den entsprechenden EVCC Datenpunkt
Bin gerade am Handy und kann nicht nachschauen aber da muss dann eine 1 oder 2 rein (eins ist sperre und eins ist forciertes laden)
ansonsten lädt sich der 2400 AC von selbst nach bevor er tiefenentladen ist.
Habe das bei mir schon ausprobiert und deswegen nicht zusätzlich eingebautedit
habe meinen Idle Verbrauch nie gemessen, finde am 200 viel... würde sagen dass es bei mir nicht soviel ist (reines Gefühl) -
Hab EVCC auf true gesetzt (und das Skript äuft auch durch den Ramp Up Prozess) aber wie es aussieht sind die Dinger schon wieder offline.
Da resettet sich bei mir die Netzwerkconfig und sie reden nur noch mit dem Cloudserver und nicht meinem MQTT Broker bis die ich die NW konfig neu mache (einmal mit identischen Settings rekonfigurieren)
Hab ich erwähnt das ich leicht genervt bin von den Dingern;)?Schauen wir mal ob sie bei mir auch selbstständig nachladen... das wäre ja ok.
-
Nachgeladen hatten sie nicht (oder zu mindestens nicht bis sie bei 2% waren)...
Der Eigenstromverbrauch ist auch nicht so hoch wie gedacht, zu mindestens nicht dauerhaft - hab mir mal die Tage davor angeschaut, da war es 1% (bei 5.76 kWh =5760W =>57,6W) in ~20h, also ~70W/d bzw ~3W/h
Auch das ist nicht wenig, aber sicherlich besser als die 200W die am 24. gezogen wurden.

-
Hi, schon mal daran gedacht, dass die Selbstentladung bzw.
der Eigenstromverbrauch bei den kalten Temperaturen durch die Akkuheizung kommen könnte? -
Sind die 2400AC, und ja vlt verbrauchen die anders...
@lesiflo - hmm eigentlich hätte ich nicht damit gerechnet das sie heizen müssen, weder im Büro noch im Keller ist es so wirklich kalt - stellt sich die Frage was die Minimum Temperatur ist die sie halten wollen wenn sie nicht laden ? Nehme an das weiss man nicht, aber ich kann ja mal fragen, hab dazu ja einen Case offen (nicht das ich wirklich Antworten erwarte)
-
Ok, wenn sie nicht draußen stehen kann es wohl kaum die Heizung sein. Meine Laden immer von alleine wenn der SOC auf 0 fällt. Sie stehen aber auch in der Garage.
-
Ne - ich wollte das mal anschalten aber da wollte er dann Cloud Login Credentials haben und da meine Shellies alle nicht in der Cloud sind hatte sich das gleich wieder erledigt.
Und aktull lässt sich ja eh nichts mehr einstellen da sie nur noch vom Skript kontrolliert werden.Mit den 3W/h (70W/Tag) kann ich auch leben (auch wenn nicht wirklich gut, wäre besser wenn man die Dinger abschalten könnte), aber der eine Tag mit den 200W war halt blöd, das würde die ganze Rechnung kaputt machen (die eh schon nicht sonderlich gut ausfällt dank der doppelten Spannungskonvertierung, aber das wusste ich ja vorher). 70W sind ~8€/Jahr, erhöht die Amortisationsgschwelle auf 10J um 5%
@lesiflo Auf 0 gefallen sind sie bei mir nicht, vieleicht hätten sie dann geladen, danke für die Info:)
-
Hi, falls Interesse besteht habe ich hier mal versucht den evcc Optimizer für Zendure zu nutzen.
@lesiflo Ich bin tatsächlich an sowas in der Art (mit noch mehr variablen) dran...
es scheint gut zu funktionieren, ich "befürchte" aber langsam das es "zu viel aufwand" für die knapp 8,x kWh ist.
wenn mein anbieter nicht im Q1 schafft Modul 3 anzubieten, spiele ich eh mit dem Gedanken Tibber zu verlassen (bin letztes Jahr nen halben cent unter einem fix-Preis gelandet, wenn man bedenkt mit welchem aufwand.....) und dann würde mir die dumme "PV Strom speichern und bei bedarf ausgeben" Logik vollkommen reichen.aber hier mal was ich bisher habe... Vielleicht wäre es Sinvoll das in einem Seperaten Theard auszulagern? (was meint ihr?)?
PS: wenn jemand eine Version wieder für mehrere Geräte braucht, kurz beschied geben dann erweitre ich es....
Es handelt sich um eine All-in-One Lösung, die eine Nulleinspeisung mit einer wirtschaftlichen Optimierung verbindet.
🚀 Was macht das Skript?
Das Skript übernimmt die komplette Kontrolle über den acMode (Input/Output) und die Leistungslimits des Zendure Hubs.
Dynamische Nulleinspeisung (PI-Regler):
Es regelt den Netzbezug auf 0 Watt (oder einen eingestellten Zielwert). Ein PI-Regler sorgt dafür, dass Lastspitzen schnell ausgeglichen werden, ohne dass das System nervös schwingt (konfigurierbare Hysterese & Totzone).Tibber-Integration (Preis-Optimierung):
-
Günstige Phasen: Wenn der Strompreis sehr niedrig ist, wird der Akku aus dem Netz geladen ("Force Charge").
-
Profit Guard: Wenn der Strompreis niedrig ist (aber nicht niedrig genug zum Laden), wird das Entladen gesperrt, um den wertvollen Speicherstrom nicht "billig" zu verschwenden. Entladen wird nur, wenn der Netzstrom teurer ist als der gespeicherte Strom inkl. Verlusten.
EVCC-Integration (Wallbox-Koordination):
Das Skript reagiert auf einen eigenen Datenpunkt EVCC_Modus, der von EVCC gesteuert werden kann:-
1 (Normal): Akku regelt normal den Hausverbrauch.
-
2 (Min+PV): Entladesperre. Das Auto lädt mit PV-Überschuss, der Hausakku soll sich dabei nicht ins Auto entleeren.
-
3 (Fast Charge): Ladezwang. Das Auto lädt schnell, der Hausakku lädt ebenfalls mit voller Leistung aus dem Netz (Bypass).
Intelligente Bedarfs-Prognose ("KI"):
Das Skript lernt! Es analysiert die Verbrauchsdaten der letzten 21 Tage (via SQL-Adapter) und erstellt ein Verbrauchsprofil für jeden Wochentag.Heizungs-Aufschlag: Es prüft die Wettervorhersage (daswetter). Ist es morgen kälter als im Durchschnitt, wird automatisch mehr Energie im Akku reserviert (für die Wärmepumpe).
PV-Prognose: Es prüft (pvforecast), wie viel Sonne heute noch kommt. Wenn mittags genug Sonne erwartet wird, wird der Akku morgens nicht unnötig voll geladen.
⚙️ Funktionsweise & Logik (Prioritäten)
Das Skript entscheidet nach einer strikten Kaskade, was zu tun ist:
PRIO 1: FORCE CHARGE (Ladezwang)
-
Auslöser: Tibber-Preis extrem tief ODER EVCC Modus "Schnellladen".
-
Aktion: Bypass des Reglers -> Laden mit maximaler Leistung (z.B. 2400W).
PRIO 2: DISCHARGE LOCK (Entladesperre)
-
Auslöser: EVCC Modus "Min+PV" ODER Strompreis zu niedrig (Profit Guard).
-
Aktion: Entladen wird auf 0W begrenzt. Laden bei PV-Überschuss ist weiterhin erlaubt (geregelt durch PI).
PRIO 3: NORMALBETRIEB
- Aktion: Der PI-Regler versucht, den Netzbezug auf 0W zu halten.
📋 Voraussetzungen & Benötigte Adapter
Damit das Skript läuft, müssen folgende Adapter installiert und konfiguriert sein:
-
Javascript/Blockly: Zum Ausführen des Skripts.
-
MQTT-Client: Zur Verbindung mit dem Zendure Hub.
-
SQL: Zwingend erforderlich für die Historien-Daten (Verbrauch lernen).
-
TibberLink: Für die aktuellen Strompreise.
-
DasWetter: Für Temperatur-Forecasts (Heizbedarf).
-
PV Forecast: Für Ertragsprognosen.
-
Shelly (oder anderer Smartmeter): Für den aktuellen Hausverbrauch (Total.InstantPower).
Benötigte Datenpunkte & Logging
Im oberen Bereich des Skripts (const IDs = { ... }) müssen die Pfade angepasst werden.
Wichtig: Folgende Datenpunkte müssen per SQL-Adapter geloggt werden (Aufbewahrung min. 21 Tage), damit die KI funktioniert:
-
Netzbezug Gesamt (kWh)
-
Netzeinspeisung Gesamt (kWh)
-
PV Erzeugung Heute (kWh)
-
Wallbox Verbrauch (kWh) - optional
-
Heizung/WW Verbrauch (kWh) - optional, verbessert die Prognose bei Wärmepumpen
💻 Installation
Neues JS-Skript im ioBroker anlegen.
Code einfügen.
Im Bereich // --- 1. KONFIGURATION --- die Parameter anpassen (Akku-Größe, Limits, Tibber-Preisgrenze).
Im Bereich // --- 2. DATENPUNKTE (IDs) --- eure eigenen Objekt-IDs eintragen.
Skript starten.
Beim ersten Start benötigt das Skript einige Sekunden, um die Historie aus der SQL-Datenbank zu laden und das Verbrauchsprofil zu berechnen.
Hinweis: Nutzung auf eigene Gefahr. Prüft bitte, ob die MQTT-Topics bei euch übereinstimmen.
-