Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

Jockel_Bln

@maxclaudi sagte:

Wenn Du inverseMaxPower dauerhaft ändern möchtest, solltest Du deshalb auch maxOutputLimit in der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.

Danke für deine ausführliche Antwort, aber kann es sein, dass wir aneinander vorbei reden?
Ich habe ja maxOutputLimit in der Konfiguration geändert, trotzdem steht im Datenpunkt control.inverseMaxPower weiterhin 800 und lässt sich auch nicht größer einstellen.

@maxclaudi sagte:

inverseMaxPower sehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.

Das habe ich ja auch so verstanden und wollte sie halt zum Test über 800 setzen.
In der App ging es nach einer Bestätigung durch mich. Im Automatikmodus des HEMS regelt er dann auch über die 800 hinaus hoch.

maxclaudi

@jockel_bln
ach ja :-)

Stoppe das Script.
setze: const maxOutputLimit = 2400;
Script speichern
Komplettes Verzeichnis "0_userdata.0.zendure.xxxxx" löschen.
Script neu starten.

Es sollte auch reichen, wenn bei gestoppten Script - vor Neustart - nur der Datenpunkt gelöscht wird: 0_userdata.0.zendure.xxxxx.control.inverseMaxPower

Jockel_Bln

Das war es

T-147

Guten Morgen allerseits,

seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer! Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.

Über das Wochenende haben sich aber ein paar Fragen ergeben, auf die ich bis jetzt keine Antwort gefunden habe:

Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?
Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?
Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?
Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?

Soweit erstmal von mir :-)
Freue mich, wenn ich zukünftig irgendwie was sinnvolles zum Thema hier beitragen kann

maxclaudi

@T-147 sagte:

Guten Morgen allerseits,

seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer!

Dankeschön, wobei das DPL-Blockly-Skript nur eine Basis-Vorlage sein soll ;-)

Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.

Genau dafür ist es gedacht – als Vorlage für den Einstieg.

Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?

Da über minSoc festgelegt wird, wann die untere Entladegrenze erreicht ist, veranlasst die Firmware automatisch ein Nachladen der Batterie(n), bis mindestens minSoc wieder erreicht ist.

Siehe auch Zendure FAQ, Zitat:

...Zudem erkennt das System automatisch, wenn der Batteriestand kritisch niedrig ist (z. B. bei geringer PV-Erzeugung) und schaltet in diesem Fall selbstständig auf Netzstrom um, um Schäden an der Batterie zu vermeiden.

Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.

Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.

Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.

Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.

Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?

Die 15 Sekunden sind kein fester Optimalwert, sondern eher ein praxisnaher Erfahrungswert, der sich an den typischen Reaktionszeiten solcher (auch prof.) Systeme orientiert und sich in meinen Tests als praktikabel erwiesen hat. Bei meinen Regelungen gibt es unterschiedliche Zeiten.
Wenn Du das Basis-Script verwendest, kannst Du gerne andere Zeiten testen.

Beim Erhöhen der Ausgangsleistung (Entladen) kommt das System meiner Erfahrung nach auch mit etwa 10 Sekunden gut zurecht. Die neue Leistung sollte dann aber auch für eine gewisse Zeit gehalten werden.

Das Reduzieren der Ausgangsleistung reagiert etwas schneller. Je nach System können hier auch etwa 6 Sekunden ausreichend sein.

Beim AC-Laden würde ich dagegen keine ständig schwankenden Leistungswerte vorgeben. Meiner Meinung nach ist es sinnvoller, mit einer möglichst konstanten Ladeleistung über einen längeren Zeitraum zu arbeiten.

Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?

Mich interessieren in erster Linie die Zählerwerte, denn das ist letztlich die Energie, die ich bezahlen muss.

Wenn Du dafür einen Shelly Plug oder eine andere Zwischensteckdose einsetzen möchtest, solltest Du darauf achten, dass auch negative Leistungen bzw. Rückspeisung korrekt erfasst werden. Tasmota-basierte Steckdosen unterstützen das beispielsweise.

Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?

Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.

Deshalb bin ich beim 1600AC+ auch froh über die Off-Grid-Steckdose, an der sich ein Mikrowechselrichter betreiben lässt.

Der SF800 Pro 2 besitzt diese Möglichkeit ebenfalls.
Du könntest testweise einen 800-W-Hoymiles-Mikrowechselrichter an der Off-Grid-Steckdose betreiben.
Zwar wird die Batterie dann ebenfalls über AC geladen, der zusätzliche Umweg über das öffentliche Netz entfällt jedoch.
Wird gerade keine Leistung benötigt, lädt das System die Batterien automatisch über den an der Off-Grid-Steckdose angeschlossenen Wechselrichter.

Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste.

T-147

Vielen Dank für die ausführlichen Antworten.

@maxclaudi sagte:

Genau dafür ist es gedacht – als Vorlage für den Einstieg.

Sehr komfortabler und umfangreicher Einstieg

@maxclaudi sagte:

Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.

Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.

Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.

Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.

OK, also ist das erstmal normal und ich sollte mich um einen entsprechenden Entladeschutz kümmern, das ist gut zu wissen.

@maxclaudi sagte:

Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.

Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste.

Spätestens sobald ich auslesen und messen kann, wieviel kWh ich per AC in den SF800Pro schiebe und wieviel ich wieder ins Haus einspeise, kommen die 4 vorhandenen Panels direkt an den SF800 und es wird nur noch zum Kalibrieren per AC aufgeladen. Mein Hoymiles Wechselrichter kommt bei 4 Panels (SO/SW) sowieso regelmäßig an seine Belastungsgrenze mit den 2 MPPT, durch die 4 MPPT kann der SF800 da noch schön von aufladen.
Ich würde halt gern wissen, wieviel Energie ich per PV gewinne, bzw. einspeise, aber da muss ich ja auch die Energie per AC-Ladung wieder abrechnen. Ich hab mittlerweile nen Shelly dazwischen, der auch beide Richtungen kann (oder können soll), aber bisher blick ich bei den Messwerten von dem nicht durch. Der hat einen Wert für "ReturnedEnergy", was für mich dann die Einspeisung wäre. Und einen Wert "Energy", der aber der Gesamtwert in & out zu sein scheint. Passt für mich aber rechnerisch auch noch nicht ganz zusammen, aber das könnte auch einfach an mir liegen

Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

maxclaudi

Erweitertes Blockly auf Basis von:

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads

Das Blockly ist für Einsteiger als Grundlage gedacht. Es kann und sollte an das persönliche Setup sowie an die vorhandenen Verbraucher angepasst werden.

Sämtliche Debug-Ausgaben dienen ausschließlich den Testläufen und können später entfernt werden.

Die Beschreibung der Basis-Vorlage ist identisch mit folgenden zusätzlichen Ergänzungen:

Batterie-Entladeschutz auf Basis der minimalen Zellspannungen der Batterien.
Einfache Lasterkennung (Critical-Modus) für größere Verbraucher. Dabei wird die DPL-Regelung vorübergehend deaktiviert und die Leistungsregelung für eine definierte Zeit mit einem festen Wert übernommen.
unterschiedliche Zeiten für inputLimit und outputLimit (intervalSec_inputLimit_auto_in_out_Limit; intervalSec_outputLimit_auto_in_out_Limit)

Das Blockly ist im Inneren wieder ausführlich kommentiert, sodass ich auf eine lange Erklärung verzichte.

Variable: intervalSec_criticalOutputLimit

Empfohlene Werte:

20s: eher aggressiv, häufiges Umschalten, nicht empfehlenswert.
30s: guter Kompromiss.
45s: im Alltag gut und angenehmer.
60s: ebenfalls gut geeignet.

Unter 15 Sekunden würde ich nicht gehen. Andernfalls besteht die Gefahr, dass bei taktenden Verbrauchern (insbesondere Induktionskochfeldern) ständig zwischen DPL und Critical-Modus gewechselt wird.

30 Sekunden halte ich für einen guten Ausgangs- und Testwert. Im Praxistest wird sich zeigen, welcher Wert für die eigenen Verbraucher am besten geeignet ist.

Meine persönliche Empfehlung: 45 bis 60 Sekunden.

Typische Verbraucher:

Wasserkocher: ca. 2–3 Minuten
Kaffeemaschine: ca. 20–40 Sekunden
Mikrowelle: 30 Sekunden bis mehrere Minuten

Ein Induktionskochfeld taktet häufig:

3–8 Sekunden EIN
3–8 Sekunden AUS

(je nach Leistungsstufe)

Hier wirken 30 bis 45 Sekunden wie eine gute Entprellung.

Beispiel: Elektronischer Durchlauferhitzer:
ein elektronisch geregelter Durchlauferhitzer zieht seine Leistung normalerweise kontinuierlich. Während des Duschens können das mehrere Minuten mit nahezu konstanter Leistungsaufnahme sein.

Bei einem Wert von 45 Sekunden läuft die Regelung beispielsweise folgendermaßen ab:

Hohe Last wird erkannt.
DPL-Regelung wird deaktiviert.
fest definiertes Output-Limit (z. B. 600 W) wird gesetzt.
Nach 45 Sekunden erfolgt erneute Prüfung.
Ist die hohe Last weiterhin vorhanden, wird der Zustand weitere 45 Sekunden beibehalten.
Erst nachdem der Verbraucher abgeschaltet wurde, wird spätestens nach 45 Sekunden wieder auf die normale DPL-Regelung umgeschaltet.

Ziel ist Nulleinspeisung.
Jedoch versucht das Blockly nicht das Ziel, jede Sekunde wieder eine perfekte Nulleinspeisung herzustellen.
Vielmehr soll verhindert werden, dass bei plötzlich auftretenden hohen Lasten ständig zwischen Laden und Entladen geregelt oder die DPL-Regelung permanent nachgeführt wird. Dadurch sollte das Gesamtsystem deutlich ruhiger und praxisgerechter arbeiten.

Hinweis zum Urheber
Bitte den Urheberhinweis im Skript beachten.
Wenn auf Basis dieses Skripts oder von Teilen daraus eigene Veröffentlichungen entstehen, genügt ein kurzer Hinweis mit Verlinkung auf diesen Thread und/oder die Nennung meines Namens maxclaudi.

Im nächsten Beitrag folgt der Blockly-Code zum Download.

Viel Spaß damit!

Bilder vom Blockly:

maxclaudi

Blockly zum download und importieren vom vorherigen Post

Das Blockly musste als Datei hinzugefügt werden, weil es zu groß ist.

Datei: maxclaudi_dpl.zip enthält nur maxclaudi_dpl.xml

Datei herunterladen und Virenscan.
maxclaudi_dpl.zip entpacken
in iobroker neues, leeres Blockly erstellen
maxclaudi_dpl.xml
importieren:

Das nächste Bild ist nur ein Beispiel.
Statt zenSDK_DPL_Blockly.xml - > maxclaudi_dpl.xml importieren.

Bitte den Urheber im Skript beachten.

Falls es Dir hilft oder Du Dich bedanken möchtest: Ein positives Voting als Dankeschön ist völlig ausreichend :-)

update 17.07.2026; 18:30h
verbesserte Version

criticalOutputLimit ist Begrenzung: wie viel Watt max. output im criticalMode sein darf,
(auch max_outputLimit ist erlaubt).
criticalGridPower definiert ab wie viel Watt ein Verbraucher als kritischer Verbraucher zählt.

Kommentare im Blockly bitte beachten.

download:
maxclaudi_dpl.zip
Hoffe es hilft Euch ein wenig; viel Spaß damit! :-)

maxclaudi

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Daniel 8

@maxclaudi sagte:

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Vielen Dank. Wenn ich mal Zeit finde, werde ich es mir mal ansehen. Meine Steuerung läuft aktuell ganz gut für mich.
Bin grad in mehreren anderen Projekten beschäftigt.

T-147

@maxclaudi sagte:

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Mögen Dir beim Händewaschen niemals die Ärmel runter rutschen!

maxclaudi

Habe soeben noch einmal das Blockly hochgeladen.
War ein Datenpunkt nicht richtig.
Entweder selbst korrigieren oder noch einmal die korrigierte Version downloaden.

Korrektur:

oder die ganzen Blöcke zur Fehlerkorrektur entfernen.

@T-147:
Mögen Dir beim Händewaschen niemals die Ärmel runter rutschen!

:-)))

Jockel_Bln

@maxclaudi sagte:

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Da hast du ja ordentlich was zusammen geschraubt
Meine Regierung hat gerade Urlaub, da darf ich momentan nicht so viel spielen.
Aber jetzt schon vorab vielen Dank für deine Arbeit.

maxclaudi

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Post

update 17.07.2026; 18:30h
verbesserte Version für kritische Verbraucher

criticalOutputLimit ist Begrenzung: wie viel Watt max. output im criticalMode sein darf
(auch max_outputLimit ist erlaubt).
criticalGridPower definiert ab wie viel Watt ein Verbraucher als kritischer Verbraucher zählt.

Kommentare im Blockly bitte beachten.

Download -> HIER

maxclaudi

@T-147 sagte:
...zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen....

Wer zusätzliche Sicherheit möchte:

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Post

update 18.07.2026; 15:30h
Version wie zuvor inkl. kritische Verbraucher + Neu: intervalSec_change_acModeAllowed

intervalSec_change_acModeAllowed:
acMode-Wechsel nur alle x Sekunden erlaubt. Schont Relais und verhindert häufiges Umschalten zwischen Laden und Entladen.
0 oder 10-60 sec.
Auch > 60 möglich.
Darf jede(r) für sich entscheiden.
Je höher der Wert, desto später erfolgt der Wechsel zwischen Laden und Entladen.

Da das Blockly im Inneren wieder sehr ausführlich kommentiert ist, verzichte ich hier auf eine lange Erklärung.

Bitte die Hinweise direkt im Skript lesen.

Import-Anleitung:
Wie man ein Blockly importiert, ist in diesem Post hier beschrieben.

Das Skript ist standardmäßig für einen Zendure 1600AC+ vorkonfiguriert.

Bitte prüft vor dem ersten Start unbedingt die folgenden Variablen und passt sie an euer eigenes System an:

max_outputLimit: 1600
max_inputLimit: 1600
criticalGridPower: 600
criticalOutputLimit: 1600

Urheberrechtshinweis
Bitte respektiert die Arbeit, die in diesem Projekt steckt, und beachtet den Urheberhinweis direkt im Skript.
Wenn ihr auf Basis dieses Skripts (oder Teilen davon) eigene Modifikationen veröffentlicht, fügt bitte eine kurze Verlinkung zu diesem Thread und / oder die Nennung meines Namens maxclaudi hinzu.
Vielen Dank!

Datei: maxclaudi_dpl_acMode_kV.zip enthält nur maxclaudi_dpl_acMode_kV.xml

Datei herunterladen und Virenscan.
maxclaudi_dpl_acMode_kV.zip entpacken
in iobroker neues, leeres Blockly erstellen
maxclaudi_dpl_acMode_kV.xml
importieren.

Download:
maxclaudi_dpl_acMode_kV.zip

Viel Spaß damit!

maxclaudi

@T-147 sagte:
Ich würde halt gern wissen, wieviel Energie ich per PV gewinne, bzw. einspeise, aber da muss ich ja auch die Energie per AC-Ladung wieder abrechnen. Ich hab mittlerweile nen Shelly dazwischen, der auch beide Richtungen kann (oder können soll), aber bisher blick ich bei den Messwerten von dem nicht durch. Der hat einen Wert für "ReturnedEnergy", was für mich dann die Einspeisung wäre.

richtig.

Und einen Wert "Energy", der aber der Gesamtwert in & out zu sein scheint. Passt für mich aber rechnerisch auch noch nicht ganz zusammen...

Das sollte nur der Wert für Bezug sein.

@T-147 sagte:

Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe,...

in etwa?

maxclaudi

Erweitertes Energie-Logging für Zendure-Geräte

Ich arbeite aktuell an einem Script, das zusätzliche Datenpunkte für Energieauswertungen (kWh) erzeugt:

Zusätzlich können zwei CSV-Dateien erzeugt werden.

1. Tagesenergie-Datei

Beispiel:
zendure_energy_2026.csv

Diese Datei enthält Tageswerte über ein Kalenderjahr:
Datum;pvInput_kWh;gridChargeInput_kWh;gridhomeOutput_kWh;gridOffSocketPower_kWh

Vor Scriptstart kann einmalig festgelegt werden, ob pvInput_kWh integriert werden soll.
Diese Option ist für Zendure-Geräte ohne DC-PV-Module-Eingänge gedacht, da dieser Wert dort immer 0 wäre.

Bedeutung der Werte:

pvInput_kWh
Vom Zendure-System gemeldete PV-Energie der angeschlossenen DC-PV-Modul-Eingänge.
gridChargeInput_kWh
Energie, die das Zendure-Gerät per 230V AC aus dem Hausnetz aufgenommen hat (AC-Laden).
gridhomeOutput_kWh
Energie, die das Zendure-Gerät in das 230V AC Hausnetz abgegeben hat.
gridOffSocketPower_kWh
Energiefluss über die gridOff-Steckdose:
positive Werte: Energiefluss von der Steckdose in das Zendure-Gerät (z.B. Microinverter)
negative Werte: Energiefluss vom Zendure-Gerät zur Steckdose (z.B. Verbraucher)

Die Datei enthält integrierte Tagesenergien in kWh und eignet sich für Statistiken, Diagramme und Langzeitauswertungen.

Die Jahresdatei wird automatisch anhand des aktuellen Kalenderjahres erzeugt.
Beim Jahreswechsel wird automatisch eine neue Jahresdatei begonnen.

2. Live-Leistungsdatei

Beispiel:
zendure_liveEnergy.csv

Die Aufzeichnung erfolgt in einem einstellbaren Intervall (z.B. jede Minute).

Enthalten sind aktuelle Leistungswerte:
Zeit;pvInput_W;gridChargeInput_W;gridhomeOutput_W;gridOffSocketPower_W

Die Werte werden nicht integriert oder aufsummiert.
Jede Zeile stellt eine Momentaufnahme der aktuellen Leistung in Watt dar.

Bedeutung:

pvInput_W
Aktuelle PV-Eingangsleistung der PV-Module an den DC-PV-Eingängen.
gridChargeInput_W
Aktuelle 230V AC-Lade-Leistung aus dem Hausnetz zum Zendure-Gerät.
gridhomeOutput_W
Aktuelle AC-Leistung vom Zendure-Gerät ins 230V AC Hausnetz.
gridOffSocketPower_W
Aktuelle Leistungsrichtung der gridOff-Steckdose:
positive Werte: Leistung von der Steckdose in das Zendure-Gerät
negative Werte: Leistung vom Zendure-Gerät zur Steckdose

Die Datei eignet sich für Leistungsdiagramme (W) und Dashboards.

Archivierung Live-Datei:
Beim Tageswechsel bzw. beim nächsten Schreibvorgang nach einem Tageswechsel wird:
zendure_liveEnergy.csv

automatisch archiviert als z.B.:
zendure_liveEnergy_2026-07-20.csv

Danach wird wieder die aktuelle Datei:
zendure_liveEnergy.csv
weitergeführt.

Es werden maximal 30 Tagesarchive behalten. Ältere Dateien werden automatisch gelöscht.

Zusätzlich kann im Script eingestellt werden, ob CSV-Dateien erzeugt werden sollen oder nur die ioBroker-Datenpunkte.

Die Berechnung basiert ausschließlich auf den von Zendure gelieferten Leistungswerten.
Es werden keine geschätzten Wirkungsgrade oder pauschalen Umrechnungen (z.B. Faktor 0,96 wie teilweise bei anderen Scripts verwendet) eingesetzt.

Die gridOffSocketPower-Werte beschreiben ausschließlich den Energiefluss über die gridOff-Steckdose und stellen keine separate Netzeinspeisungsmessung dar.

Die Energiezähler werden über die von Zendure gelieferten Zeitstempel und Leistungswerte fortgeführt.
Bei Neustarts oder Unterbrechungen werden keine fehlenden Werte geschätzt oder nachberechnet.

Das Script arbeitet unabhängig von der Gerätesteuerung und greift ausschließlich lesend auf vorhandene Zendure-Datenpunkte zu.
Es verändert keine Geräteeinstellungen und kann daher parallel zu bestehenden Steuerungsscripten betrieben werden.

Mehr fällt mir dazu im Moment nicht ein; genug getippt :-)

Besteht Interesse an dieser Erweiterung bzw. an dem Script?

Über eine Rückmeldung, wer welches meiner Blockly-Scripte verwendet und ob diese problemlos laufen, würde ich mich ebenfalls freuen ;-)

Daniel 8

@maxclaudi sagte:

Allen einen wunderschönen, sonnigen guten Morgen,

@Rico-Sander sagte:
Vieles was hier diskutiert wird im Zusammenhang mit der Firmware- und HEMS-Aktualisierung trifft für mich nicht zu.

habe auch kein Update durchgeführt. Weil ich kein HEMS nutze, ist es für mich nicht wichtig.
Von den letzten Updates war ich mehr enttäuscht.
Echte Verbesserungen gab es - für mich - nicht.
Für mich waren es mehr Reglementierungen.

@Rico-Sander sagte:
Laden über AC-Anschluss, Entladen über AC-Anschluss - sonst nix.
Bypass-Funktion und Grid-Dose benötige ich nicht.

Selbst wenn Du mehr benötigen würdest, wüsste ich nicht was aktuell unter API 2 dagegen spricht.
Die größten Veränderungen/Neuerungen durch das aktuelle Update sind bisher die Einführung von HEMS2 und Umstellung auf TLS.
Zendure schreibt zwar: X bekannte Probleme behoben, jedoch welche das sein sollen, wird nicht erwähnt.

Bei meinem Gerät sollen es 2 Probleme sein.
Kann aber kein Problem feststellen und HEMS nutze ich nicht.

@Rico-Sander sagte:
Daher: Kann ich gefahrlos bei Verwendung des HTTP-Scriptes die Updates fahren oder gibt es Probleme mit dem SSL- und Port-Problem?
Vermutlich nicht, da ich ja kein MQTT nutze - richtig?

SSL mit Port:8883 ist nur für (nicht offizilles , Cloud-) MQTT
Das Script nutzt reines HTTP mit dem Webserver des Zendure-Geräts.
Zendure-Gerät und App nutzen zusätzlich "nicht offizielle" MQTT-Verbindung zur Cloud.

Für das Script bedeutet das: Wenn Zendure durch die Firmware zenSDK nicht auch reglementiert oder grundlegend was verändert hat, dann funktioniert es wie zuvor.
Es gab mit dem Update ein paar Änderungen und ein zusätzlicher Key.
Bisher wurden mir keine Einschränkungen gemeldet.

@Daniel-8 sagte:
Bei mir ist alles gut.

Hey, freut mich.

@Daniel-8 sagte:
...hat Zendure bei Hems 2 und den neuen Firmwares was geändert.
Ich habe noch kein Update gemacht. Bin etwas vorsichtig, da im Zendure Forum sehr viele Probleme haben.

warte auch ab. Evtl. benötige ich keins.

@Daniel-8 sagte:
Was ist eigentlich der socCompSwitch?

Das ist nicht bekannt und noch nicht dokumentiert.
Habe eine Vermutung und kann es - ohne Update -nicht testen.

socCompSwitch, bedeutet wahrscheinlich: State of Charge Compilation Switch.

Denke es wird sich um einen neuen Schalter handeln, der eine Kalibrierung manuell auslösen wird.

Damit man die automatische (wöchentliche oder monatliche) SoC-Kalibrierung zu nicht gewollten Zeiten

beeinflussen,

verhindern

oder vorziehen kann?

Das ist nur meine Vermutung -reine Spekulation - !

Habe den Schalter mal hinzugefügt, falls jemand auf eigene Gefahr und eigenes Risiko selbst testen möchte, was der Schalter bewirkt.

Unter API 2 habe ich den Schalter schon gesetzt und getestet.
Befehl wird abgeschickt und Empfang bestätigt.
Auswirkungen hatte es bei mir überhaupt keine.
War zu erwarten, weil socCompSwitch in der API2-Firmware nicht implementiert ist.
Konnte den Schalter mehrmals - unter API 2 - gefahrlos bei meinem 1600AC+ setzen - ohne jede Veränderung.
Funktionieren oder was bewirken wird der Schalter (sehr wahrscheinlich nur) erst nach Firmware-Update auf zenSDK API Version: 3.

Noch einmal: Alles zu socCompSwitch sind nur Vermutungen aufgrund von Tests und Beobachtungen.

edit:
Falls jemand set socComp nach Update mit zenSDK API Version: 3 testen sollte, wäre ich über Rückmeldungen sehr dankbar.

Habe mich heute doch mal getraut mein Solarflow 800 Pro auf die Firmware 2.0.1 upzudaten.

Habe dann mal den setsocComp auf 1 und 2 geschrieben. Konnte aber keinerlei Veränderung feststellen

maxclaudi

Hallo zusammen,

@Daniel-8
Sorry, dass ich mich erst jetzt wieder melde.
Ich bin gerade intensiv mit dem Reverse Engineering beschäftigt und habe auch viel Zeit im source-code der Zendure-App verbracht – alles sehr zeitaufwendig.

Wenn du aktuell auf der Firmware 2.0.1 bist, könntest du in der App mal verschiedene Einstellungen bei der Kalibrierung vornehmen und die Daten mitloggen oder beobachten?
Mich würde interessieren, wann genau sich socCompSwitch und batCalTime ändern und welche Werte in diesem Moment gesetzt werden.

Anscheinend:
version:3 vs version:2
LCNstate wurde entfernt
socCompSwitch wurde hinzugefügt.

Kann nicht selbst testen, weil ich bewusst noch kein Update durchführe(n kann).

Zu meinem Beitrag bezüglich des unknown ca-Fehlers beim SolarFlow 1600 AC+:

maxclaudi sagte:

@nograx
Dankeschön

edit 12.07.2026 11.00h:
Ich habe das ebenfalls getestet. Leider wurde dieses – noch einfachere – Zertifikat von meinem 1600AC+ ebenfalls nicht akzeptiert.

Info:
Mit openssl s_client gegen mq.zen-iot.com:8883 erhält man folgende Informationen:
CONNECTED(00000004)
depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA
verify return:1
depth=0 C=CN, ST=hangzhou, O=EMQ, CN=Server
verify return:1
.....
---
Certificate chain
 0 s:C=CN, ST=hangzhou, O=EMQ, CN=Server
   i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May  8 08:07:05 2020 GMT; NotAfter: May  6 08:07:05 2030 GMT
 ......  

 1 s:C=CN, ST=hangzhou, O=EMQ, CN=RootCA
   i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May  8 08:06:52 2020 GMT; NotAfter: May  6 08:06:52 2030 GMT
   
Server certificate
subject=C=CN, ST=hangzhou, O=EMQ, CN=Server
issuer=C=CN, ST=hangzhou, O=EMQ, CN=RootCA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2205 bytes and written 402 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)
Nach meiner Interpretation bedeutet das:

Zendure verwendet kein einzelnes selbstsigniertes Serverzertifikat, sondern eine Zertifikatskette aus einer selbstsignierten Root-CA (RootCA) und einem von dieser Root-CA signierten Serverzertifikat (Server).

Die Root-CA ist selbstsigniert und wird vom OpenSSL-Client deshalb erwartungsgemäß nicht als vertrauenswürdig eingestuft (Verify return code: 19).

Das Serverzertifikat verwendet RSA-2048 und ist bis 2030 gültig. Interessant ist das Ausstellungsdatum von bereits 2020.

Bei meinem SolarFlow 1600 AC+ wird ein einfaches selbstsigniertes Serverzertifikat bisher mit unknown ca abgelehnt, obwohl RSA-2048, TLS 1.2, passende Cipher und SAN verwendet werden.

Nach den bisherigen Erkenntnissen scheint sich die TLS-Implementierung der Hyper-Geräte von der der neueren AC-Serie zu unterscheiden. Ob dies tatsächlich an einer strengeren Zertifikatsprüfung liegt oder eine andere Ursache hat, ist mir derzeit noch unklar.

Als nächsten Schritt werde ich versuchen, statt eines einzelnen selbstsignierten Serverzertifikats ebenfalls eine Zertifikatskette (Root-CA - > Serverzertifikat) nachzubilden.
Ob das vom 1600 AC+ akzeptiert wird, halte ich allerdings für eher fraglich.

Meine Vermutung hat sich inzwischen bestätigt und ich habe eine erfolgversprechende Lösung für die Zertifikatskette gefunden.

Da ich momentan nicht vor Ort bin, steht der finale Praxistest direkt mit dem 1600 AC+ noch aus.
Sobald ich wieder Zugriff habe, wird sich zeigen, ob der Cloud-Server damit komplett durch einen lokalen Broker ersetzt werden kann.
Ziel ist ein vollständig lokales Setup mit eigenem MQTT-Broker, zusätzlichen Keys und schnellem, direktem MQTT.

Läuft der Test erfolgreich, hätte man bis zum Ablauf des Original-Zertifikats am 6. Mai 2030 um 10:07:05 Uhr (MESZ) erst einmal Ruhe – also für gut 3,5 Jahre ein schnelles, stabiles, lokales MQTT-System.

Ich bin parallel auch gerade dabei, eine Windows-Konsolen-Anwendung zu schreiben.

Bitte habt etwas Verständnis und Geduld, wenn ich nicht immer sofort antworte.

Danke und viele Grüße!

edit 27.07.2026
Heureka :-)

Daniel 8

@maxclaudi ich führe ja keine Kalibrierung über die app durch. Ich mache automatisch alle 25 Tage eine über iobroker.

Habe grad durch das Update Probleme das er mir über Nacht den Akku leer zieht.

Bin aber grad noch am austesten. Der ging nicht mehr in standby wenn es dunkel war und socmin erreicht. Er hat durchgehend mit ca. 9 bis 14 Watt entladen.

Habe ihn jetzt per mqtt ein und ausschalten quasi aus der Ferne zu einem Neustart gezwungen. Danach war er sofort im Standby. Mal sehen was morgen verbraucht wurde und ob er morgen abend abschaltet.

Community Forum

NEWS

Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

Support us

460

33.0k

83.6k

1.3m