Zendure SolarFlow2400 AC (EVCC, Tibber und PV-Forecast)

Mabbi

Habe fertig...alles nun schön in Funktionen gepackt (bis auf die Presets der Konstanten/Globals):

Ein bisschen stolz bin ich auf das hier:

im Zusammenspiel mit dem hier (Beispiel):

Volle Flexibilität bei den Datenpunkten (werden aus Bausteinen je nach Akku_Nr zusammengebaut und um die Object-Subfolder, Zielobjekte und evtl '.SET' (je nachdem ob man liest oder schreibt) erstellt.

So ist da hinzufügen eines weiteren Akkus einfach nur die Seriennummer und die MQTT.X Nummer in die Variable einzutragen und schon funzt es(hoffentlich).

Ist noch ein bisschen rough, muss noch 'sonst falls' bei der Akku-Ansteuerung bekommen, die Variaben für den 3. Akku fehlen noch und die Object_ID Funktion werde ich noch mit einem Rückgabewert versehen, aber das Prinzip wird glaube ich schon ersichtlich.

Heute leider keine Zeit mehr zum Testen... :(

Schimi

cool!!

Ich könnte (wenn bedarf besteht) das JavaScript auch auf "mehrere Geräte" umbauen...
Das müsste aber einer testen oder mir min. ein Gerät spenden ;-)

edit
Ich glaube interessant wäre es auch wenn du das als Code zum importieren anbietest

Mabbi

Kleine aber sinnvolle Fortschritte:

@Schimi:
Ich habe mich von Deinem Integral getrennt :(

Was aktuell im Blockly funktioniert:
Beide Zendure AC2400 takten und steuern im Wechsel
Hat mir viel Kopfzerbrechen gemacht die beiden Regelungen sinnvoll vom Aufschauckeln abzuhalten

bis hin zu einer lädt und der andere speist ein...

Das ist beides gelöst und ich habe nun ein sinnvolles Leistungs-Synchronisation (Loadbalancing) zwischen den beiden:

Sieht doch schon besser aus :)

Es gibt nun einen Nachtmodus (Sonnenuntergang bis Sonnenaufgang) der beide Zendure strikt im Output-Modus festhält, ich nutze ja kein Tibber o.ä.
SOC Balancing zwischen den beiden Akkus
Erstaunlicherweise Laden und Entladen die beiden nicht wirklich parallel (beide Akkus liefen da noch synchron in der Ansteuerung ohne Wechseltaktung):

Vielleicht ist SOC gar nicht so wichtig bei diesem Akkutyp, der blaue und der lila Graph sind die SOC-Werte.
Vielleicht laden und entladen die auch unterschiedlich, weil der eine aktuell im Technikraum und der andere bei mir im Büro steht... ergo unterschiedliche Temperaturn in der Nacht (wir reden hier von gerade mal 20° zu 16° Grad Unterschied) ?

Aktuell steure ich die Akkus beim einem SOC Unterschied von mehr als 5% gezielter an um das auszugleichen.
Bin aber nicht sicher, ob ich den Part behalten werde.

Eine indirekte Unterstützung für meine Wallbox ist integriert.
Es gibt ein prozentuales Prio-System, bei gleicher Priorität zwischen Haus-Akku und EV 'sieht' die WB einen Teil der Akku-Ladeleistung als zus. virtuellen PV-Überschuss. Damit wird die WB früher motiviert das EV zu laden.
Über einem bestimmten SOC halten die Akkus die Wallbox virtuell (ja. hier kann es zu kurzem geringen Netzbezug kommen weil die Akkus nicht schnell genug schalten auf Entladen) am Leben. Funktioniert noch nicht ganz optimal, aktuell steuert meine go-E nur alle 90 Sekunden per Adapter. Und für genau den Adapter erzeuge ich eine teilweise gefakete PV-Einspeisungs-Leistungswerte.
Funktioniert aber schon ganz gut, hier war der Haus-Akku etwas höher in der Prio und hat der WB immer mehr Leistung geklaut, als der Akku fast voll war, bekam die WB wieder mehr Leistung freigeschaltet:

Lila oben ist die WB, grün unten die Ladeleistung beider Akkus kombiniert, man kann sogar die kurzen Einspeisungpeaks sehen, als die WB von 1- auf 3-phaisg geschaltet hat und ca. 20 Minuten später wieder zurück wegen insgesamt sinkendem Solarertag.

Und auch wenn die roten Netzbezugs-Peaks (ich nutze da MAX-Werte) im oberen Diagramm wild aussehen, das Haus hat heute insgesamt laut Smartmeter gerade mal 560 Wh verbraucht. Und das obwohl ich von 29,3 KWh Produktion nur 3,39KWh eingespeist habe, alles andere ist in Wärme, Haus-Akku für die Nacht und EV geflossen.

Langsam bekommt es Hand und Fuß.
Ich muss noch etwas an den scripten feilen und testen, dann würde ich die hier auch zu Verfügung stellen, solange @Schimi damit grün ist.

Und nun der Wehrmutstropfen am Schluss:
Wenn ich die ZendureAC2400 einzeln schneller als 14 Sekunden in der Ansteuerung takte, dann sieht man zwar die mqtt Änderung in den NUMBER/xxx-Limit Werten wie diese vom SET übernommen werden im ca. 1 Sekundentakt, die Werte im Sensor/ gridinput/homeoutput power frieren aber ein und mein Smartmeter bestätigt das auch.

Ich komme einfach nicht dahinter, warum beide Zendure AC2400 sich bei mir so verhalten... :(

Schimi

@mabbi

natürlich bin ich damit "grün" :-) kann man vielleicht dann im ersten Post auf deinen "fertigen" (wenn er dann da ist) verwiesen. Dann können andere direkt hinspringen...

Wegen deinem "taktungsproblem" sind wir ja recht ratlos...
mir ist noch eingefallen; hast du mal geschaut ob in der App noch zufällig irgend eine Steuerung an ist? Die eventuell über die Cloud reinfunkt?
Ich fasse nochmal mein Setup zusammen:

AC2400 im HWR, ca. 3m Luftlinie (hinter eine Tür) vom Unifi Accespoint (U6 Lite) entfernt.
ich habe nicht den DNS "umgebogen" oder sonst wie die Cloud deaktiviert (wobei es damit genau so gut lief)
ich lass parallel noch das Script von @maxclaudi laufen, nutze es aber nicht für irgendeine Steuerung
App:
"Zu HEMS hinzufügen" ist "Aus"
"Off-Grid-Steckdosensteuerung" > "Smarter-Modus" > "Aus"
"Akkueinstellung" min auf 5 und max auf 100%
"MQTT", Aktiviert und entsprechend eingerichtet
Aktuelle Firmware 1.0.8

MQTT (iobroker-Adapter):

Ping auf den Zendure:

Mabbi

Mein Status:

2x @maxclaudi script ist an(eins je Akku), Smartmodeinfo: 1 , mqttconnectinfo: 1
Meine 2x mqtt settings sind mit Deinen identisch
Beide Akkus sthen keine 2 Meter von einem Accesspoint entfernt
Pings sind ok:
Die 2 Akkus sind in der App alls offline vermerkt, HEMS bei beiden aus, Mqtt EInstellungen passen, bin aus der App abgemeldet.
Die 2 Akkus sind vom WAN ausgesperrt, der EcoTracker habe ich in der App abgemeldet und ihm dann WAN Zugang gesperrt. Sperre umfasst sowohl IP wie auch MAC-Adresse bei allen 3 Geräten.

Hier: 0_userdata.0.zendure.XXXXXXXXXXXXXXX.solarFlow2400AC.version steht bei mir stumpf eine 2 drin
Das ist wohl kaum die Firmware.
@schimi : Wo sehe ich die Firmmware ?

Schimi

@mabbi ich sehe die in der App...

ich erlaube meinem den zugangs ins netz und durch das eingebaute Mqtt, kann man gleichzeitig die cloud Verbindung nutzen

Mabbi

@schimi

Ah ok, da bin ich auf der neusten Version, letztes Update kam vor ca. 2 Wochen.
Hat Dein AC2400 irgendwo einen Hinweis auf die Hardwarerevision ?
Meine sind vom Juni und von Oktober, nicht das sich da was geändert hat, weil die evtl. neuer sind als Deiner ?

Btw...für alle Interessierten, Zendure verkauft den AC2400 plus 1x AB3000X (2.88 KWh) aktuell für 3 stellig.
Ich war kurz geneigt den 3. zu kaufen, was ich eigentlich erst in 2026 machen wollte.

Schimi

@mabbi nicht das ich wüsste...Falls ich dazu komme, schaue ich mal am we ob ich was am Gerät, direkt finde...

hmmmmm

Mabbi

Die Dämpfung, die ich eingebaut habe (fast ein Integral :) ) führt im Wechselbetrieb der beiden AC2400 zu einem pumpen, und das nur bei der Enspeisung. Wenn ich die AC2400 synchron laufen lasse, dann ist es weg ... ?

Das wechselseitig ansteuern der AC2400 ist komplexer als ich dachte, vor allem in dem dynamischen Bereich, wenn es gerade um die PV-Ertragsschwelle wo das Haus versorgt ist zwischen Laden und Entladen schwankt.
Dafür war eigentlich die Dämpfung drin.... am WE nochmal an die Tastatur :)

Nicht das ich schon 3 Loadbalancing/Dämpfungs-Funktionen in den letzten Wochen durch hätte...

Nach dem check der Daten von heute habe ich die Nachts-Nicht-Laden Logik erweitert:

Wenn der durchschnittliche PV-Ertrag der letzten 5 Minuten unter 250 W fällt wird Akku-Laden nun auch verhindert.
Diese Abfrage versetzt beide Akkus strikt in den output-Modus(Entladen) solange mindestens eines der beiden Argumente erfüllt ist.

Schimi

@mabbi mal ne schnelle Überlegung am Handy...

was ist, wenn du den wert nimmst und durch 2 teilst und jeweils an die beiden 2400AC schickst....

theoretisch sollten die sich gleich ent bzw. beladen

Mabbi

@schimi

genau das mache ich auch.
Aber wenn die Akkus nicht synchron sondern im Wechsel angesteuert werden, fängt der 'Regelkreis' manchmal an zu pumpen (nur bei Einspeisung), und das obwohl ich sowohl die Gesamtleistung plus/minus der Akkus heranziehe und auch die Einzelleistung pro Akku vergleiche und Loadbalancing zwischen den beiden mache, und das optional mit IST-Werten oder einem Delta über den Regelzeitraum der Akkus.

Die Problematik ist wohl, dass bei niedrigem PV-Ertrag, wo die Akkus theoretisch zwischen Laden und Entladen schalten würden, je nachdem welcher Verbraucher sich gerade zu oder abschaltet, die ganze Regellung in eine Schwingung versetzt wird, aus der Sie nicht mehr rauskommt.
Rein technisch habe ich die Regelung in .net mit simulierten Daten laufen lassen (ist halt viel einfacher zu debuggen), da bekomme ich ein relativ sauberes Verhalten, Schwingungen werden im Load-Balancing wieder eingefangen.
Aber ich habe hier gerade einen klassischen 'Theorie und Realität' Fall.
Im Augenblick habe ich die Trägheit der Steuerung im Verdacht, ich regel ja nur alle 15 Sekunden und genau an der PV-Ertrags Grenze können in dem Zeitraum auch in den Delta/Zeit Werten schon wilde Sachen passieren.
Ich will das aber nicht mit einer übermässig grossen Totzone erschlagen.

Wenn ich mit exakt der gleichen Steuerung auf die abwechselnde Ansterung der Akkus verzichte

ist alle scool und ich kann ohne Totzone sauber regeln.

Ich werde mal alle relevanten Regel-Daten in Datenpunkte schreiben, die Historie aktivieren und mir das dann per Diagramm anschauen... im zeilenweisen Textdebugging komme ich hier aktuell nicht mehr wirklich weiter.

Schimi

@mabbi was wäre wenn du entweder das regeln erst bei z.B. +-50 watt unterschied zum vorherigen wert erlaubst...

oder im bereich bis -+200 Watt nur kleine sprünge erlaubst (z.B. 20 Watt)... würe die Regelung in dem Bereich langsam machen....

hmm, sonst habe ich keine idee gerade..

lesiflo

Hallo @Mabbi
ich habe hier mal mitgelesen und einen ähnlichen Aufbau, allerdings mit 2 Hyper und habe das mit Java-Script gelöst.
Die Akkus werden bei mir über die angeschlossenen PV-Panels und externer PV geladen. Ich steuere beide Hyper zusammen. Hier mal ein Auszug wie ich die Leistung ermittle. Bin aber in der Cloud.

const hyper1 = {
    name:           'Hyper1',
    inputLimitDP:   'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.setInputLimit',
    outputLimitDP:  'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.setOutputLimit',
    inputDP:        'zendure-solarflow.0.xxxxxx.yyyyyyyy.gridInputPower',
    outputDP:       'zendure-solarflow.0.xxxxxx.yyyyyyyy.outputHomePower',
    acModeDP:       'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.acMode',
    pvLeistungDP:   'zendure-solarflow.0.xxxxxx.yyyyyyyy.solarInputPower',
    chargePowerDP:  'zendure-solarflow.0.xxxxxx.yyyyyyyy.outputPackPower',
    socDP:          'zendure-solarflow.0.xxxxxx.yyyyyyyy.electricLevel',
    setsocDP:       'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.dischargeLimit',
    ladenGesamtDP:  'zendure-solarflow.0.xxxxxx.yyyyyyyy.calculations.outputPackEnergyTodaykWh',
};

const hyper2 = {
    name:           'Hyper2',
    inputLimitDP:   'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.setInputLimit',
    outputLimitDP:  'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.setOutputLimit',
    inputDP:        'zendure-solarflow.0.xxxxxx.zzzzzzzz.gridInputPower',
    outputDP:       'zendure-solarflow.0.xxxxxx.zzzzzzzz.outputHomePower',
    acModeDP:       'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.acMode',
    pvLeistungDP:   'zendure-solarflow.0.xxxxxx.zzzzzzzz.solarInputPower',
    chargePowerDP:  'zendure-solarflow.0.xxxxxx.zzzzzzzz.outputPackPower',
    socDP:          'zendure-solarflow.0.xxxxxx.zzzzzzzz.electricLevel',
    setsocDP:       'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.dischargeLimit',
    ladenGesamtDP:  'zendure-solarflow.0.xxxxxx.zzzzzzzz.calculations.outputPackEnergyTodaykWh',
};

const evuLeistungDP         = 'mqtt.0.openWB.evu.W';
const aktuelleEinspeisung   = Number(getStateVal(evuLeistungDP, 0));

const hyper1Leistung = Number(getStateVal(hyper1.inputDP, 0)) - Number(getStateVal(hyper1.outputDP, 0));
const hyper2Leistung = Number(getStateVal(hyper2.inputDP, 0)) - Number(getStateVal(hyper2.outputDP, 0));

const leistungAusAkkus = aktuelleEinspeisung - hyper1Leistung - hyper2Leistung; // wie im Original

// PV-Überschuss-Erkennung: negative leistungAusAkkus = Überschuss? (behalte dein Vorzeichenmodell)
if (leistungAusAkkus < -ladenStartSchwelle && speicherMinSOC < zielSOC) {
     ladenErlaubt = true;                
     visLog('☀️ PV-Überschuss → Laden erlaubt', 'ok');
}

Kann gerne mal das gesamte Script posten, ist aber sehr an meine Bedingungen angepasst.

Unterums

Hallo,
ich suche jemanden der mir (auch gerne gegen Bezahlung) hilft,

einen Flow einzurichten in IO-Broker. Habe die Zendure Batterie mittels MQTT zum Luafen gebracht und würde nun gerne folgende Werte schreiben können:
1.) Laden über AC Ein / Aus
2.) Entladen über AC Ein / Aus
3.) Die Leistung für 1 oder 2

Ist hier jemand der Lust darauf hat ?

Schimi

@unterums wenn ich aus das richtig verstehe, macht mein Javascript genau das... Du musst nur Tibber und evcc auf "false" setzen und deinen Stromzähler angeben (z.B. shelly oder Tibber Pulse.. es gehen auch alle anderen die ein + für bezug und - für einspeisung liefern)

Uberga

@schimi Danke, aber wo "baue" ich das Java Script ein ?
Sorry, aber ich bin da absolut unbewandert :-)

Mabbi

@uberga

Hi,
das script von @Schimi kommt im Iobroker hier hin, einfach anclicken:

Dann clickst du hier auf das PLUS:

Wählst das hier aus:

Vergibst einen Namen (Verzeichnis würde ich erstmal nicht ändern):

Und fügst den kopierten Text aus dem ersten Post in den Editor ein, dann SPEICHERN

Sollte dann so aussehen (Name kann abweichen)

Mit dem Play/Pause startet das script bzw stoppt.

ABER.... ich würde Dir nicht empfehlen als Anfänger gleich mit Javascripten zu arbeiten.
Ehrlich, schreib ein paar kleine Blocklys, verstehe wie Datenpunkte angelegt, angesprochen und manipuliert werden und dann kannst du auch Deinen Akku selber steuern mit einem kleinen script und Erfahrung.
Die Akkus sind keine Spielzeuge. Du solltest wirklich verstehen wie du die scripte überwachst und dann reagierst.

Schau mal, ich arbeite seit Wochen an einem Akku-Script... es gibt idz. X-Versionen und ganz glücklich bin ich aktuell immer noch nicht mit dem Ergebnis (wobei das nun eher Schönbauerei ist als reale technische Verbesserung idZ.)

Schimi

es kann definitiv nicht schaden sich mal mit blockly auseinander zu setzen...

Mein Skript braucht zwar nur konfiguriert werden und sollte funktionieren... aber ein grundverständnis schadet nie :-)

PS: es gab wieder ein Update (siehe ersten post)

lesiflo

Hi, noch ein Tip von mir:
Du solltest, falls du den Wert hast, deinen Rest-Tagesverbrauch in kW/h welcher durch PV gedeckt wird, noch von deinem Tages Rest-PV abziehen. Dann bekommst du einen noch besseren Restwert zum Laden deiner Akkus. Ich verwendet zusätzlich noch den Genauigkeitsfaktor aus PV-Prognose und tatsächlicher PV Energie, den ich dann mit in die Berechnung der restliche PV Leistung mit einfließen lasse. Wenn dann PV nicht reicht wird über Tibber geladen (aber nur falls das wirtschaftlich Sinn macht)

So z.B.: pvRest_Real = (pvRest - verbrauchRest) * Faktor

Gerade was die teilweise sehr ungenaue PV-Prognose angeht solltest du den Genauigkeitsfaktor mit einbauen. Hier mal ein Beispiel von heute wie ungenau die Vorhersage ist. War aber auch nur sehr wenig Sonne.

Ich nutze übrigens für die PV-Vorhersage solarprognose.de. Der errechnet die Genauigkeit gleich mit. Gibt auch einen Adapter dafür.

Schimi

Danke für den Tipp... mit der Genauigkeit habe ich auch so "meine probleme"...

das mit dem Resttagesverbrauch ist aber schwer vorauszusehen...

aber ich mach mir da nochmal gedanken... das mit dem Genauigkeitsfaktor ist definitiv ein guter Tipp

Community Forum

NEWS

Zendure SolarFlow2400 AC (EVCC, Tibber und PV-Forecast)

Support us

811

32.4k

81.6k

1.3m