Zendure Solarflow 800 Pro - lokale Steuerung über HTTP inclusive Warmwasserbereitung

[Spessartwald]

angeregt von mi-hol hier eine Zusammenfassung meines Tasmota Projektes zur lokalen Regelung eines Zendure SolarFlow 800 Pro Balkonkraftwerkes mit integriertem Speicher. Der Zendure SF800 Pro kombiniert ein klassisches Balkon-PV mit bis zu 4 Paneln und einen AC Speicher in einem Gerät.

Dieses Projekt habe ich aus folgenden Gründen so umgesetzt:

1. Balkon PV mit 2 Panels mit Hoymiles Wechselrichter zu Zeiten unbezahlbarer Speicher bereits fest auf dem Dach montiert. Sollte nicht geändert werden
2. Erweiterung um einen Speicher. Speicher soll in den Aussenbereich. Aufgrund der baulichen Gegebenheiten keine weiteren Panels aufs Dach, sondern an eine andere Fassade oder in den Garten. DC Leitungen mit 4mm² Leitung und einer Länge von >12m sind teuer und haben bei Vollast bereits erhebliche Verluste von bis zu 20%. Bleibt AC Kopplung zwischen der vorhandenen Dach PV und dem Speicher. Der SF800Pro erhält 2 eigene Panels in seiner Nähe.
3. Kein Eingriff ins Hausnetz, kein Elektriker, kein Shelly usw. . Trotzdem sicherstellen, daß nicht mehr als 800W ins Netz gehen. Bei ausreichend Sonne incl. korrekter Regelung kann trotzdem ein Verbraucher bis zu 1.6KW versorgt werden
4. PV Überschuss wird über einen DMX Dimmer in einen Heizstab eingespeist und belastet nicht das Netz.
5. ESP32/Tasmota ist unschlagbar günstig.

Da der Regelkreis für eine Nulleinspeisung im SF800Pro (anders als z.B. im Marstek) über die Cloud realisiert wird, erfordert eine lokale Regelung mehr als nur der Bereitstellung der SML Werte. Wer die cloud/app nicht nutzen mag, kann das Gerät sowohl über HTTP als auch MQTT lokal ansteuern. Eine HA Einbindung und zusätzliche Hardware (Shelly, Raspberry..) kommt für mich nicht in Betracht. Tasmota und ein ESP32 sollten das erledigen.

• Projektüberlick hier:

Die Zendure API Doku hier:
https://github.com/Zendure/zenSDK

Interessante Details bzw Diskussion zu Regelkreisimplementierung für eine Nulleinspeisung hier:
Zendure/zenSDK#72 (comment)

Das unprofessionelle script ist angehängt und läuft unter Tasmota 15.1. Kompiliert in VSC mit den gleichen Quellen aus dem ottello 9 Github repo die auch für den Energiezähler verwendet werden. Hinzugefügt für die JSON/API implementierung: #define USE_WEBSEND_RESPONSE.

260517_PV_Steuerung_Script.txt

Das script zeigt was für einen Nichtinformatiker mit einfacher Denklogik über scripting machbar ist. Mit Berry hätte ich das nicht in dieser Zeit hinbekommen, mit Tiny C auch nicht. Allerdings bietet Tiny C den Vorteil, das Claude nach kurzem Palaver zuverlässigen Code schreiben wird....

Wichtig ist was hinten rauskommt. Bei mir sind das konkret 22kWh Netzbezug im April 26 und Einspeisung in gleicher Höhe aufgrund verschiedener Verluste. Warmwasser war den ganzen Monat kostenlos dabei. Gasheizung aus.

• screenshot anbei was die Regelung so treibt (5s auflösung) bei heftigen PV Eingangsschwankungen Sonne/Wolke schneller Wechsel, taktende Kochplatten und PC zur Mittagszeit. Der Akku ist zu dieser Zeit bereits voll. D.h. es geht nur um Verteilung der Energie der beiden ´Einspeiser´ haupstächlich in die Kochplatten, und wenn die gerade aus sind in die WW Heizung.
• Schön zu sehen wie der SF800 Pro die 800W zuschiesst, wenn eine Kochplatte angeht, und der totzeitbedingte negative Spike nachdem eine Platte abgeschaltet hat. Zu Beginn der Aufzeichnung sind 2 Kochplatten an, deren Leistungsbedarf von 2,8kW durch den Homiles am Dach und den SF800Pro (zusammen 1.4KW) nicht abgedeckt werden kann. Im weiteren Verlauf ab 11:12 takten beide Platten unterschiedlich. Ab 11:15 aus, dann geht Überschuss in die WW Heizung, bis um 11:30 wieder 2 Herdplatten eingeschalten werden.
• Wenn der Akku noch nicht voll ist und bei PV Überschuss wird der Akku sowohl über die internen Panels als auch über Netzbezug (Überschuss des Hoymiles Balkon PVs) geladen. Die Ladeleistung des SF800Pro ist mit 2 Akkus 1.3kW, die entweder aus den eigenen Panels oder aus dem Netz kommen können. In meiner Konfiguration (2 Panels am SF800 Pro, 2 Panels am Hoymiles) wird diese Leistung morgens schnell erreicht und der Akku ist innerhalb 2h auf seinen Zielwert von 90% aufgeladen. Im weiteren Tagesverlauf gehen bei wolkenlosem Himmel ab April bis zu 3KWh Überschuss ins Warmwasser, was zu einer Temperaturerhöhung von 22° im 120L Boiler führt.
• im 24h Diagramm sind die Werte gemittelt. Der Integral-Anteil regelt den Energiebezug nachts bei langsamen Schwankunen auf +/-1W aus.

Auszug aus der Zendure App, die unverändert weiterläuft:

• von 8:00-12:00 wurden an diesem Tag geladen. Orange Kurve: die eigenen Panels des SF800Pro (Ost). Weisse Kurve: zusätzliche AC Ladung durch den Hoymiles vom Dach (Süd/Ost). Ladeleistung ca 1.1KW. Nachdem der Akku voll ist geht die Leistung des SF800Pro Panels bis 15:00 sowie der Hoymiles Überschuss in die Heizung. Gegen 13:00 kurze Entladung (800W, nicht deutlich sichtbar) fürs Kochen in der Küche. Ab18:00 dann Entladung des Akkus

Was wünschenswert wäre:

• mDNS bei ungewollten Änderungen der IP Adresse, die mein beschränkter O2 Router z.B. nach einen FW update oder Stromausfall vornimmt.
• Das ganze lauffähig auf nur einen ESP32. Das 5s Stromzählerscript von hier (https://github.com/ottelo9/tasmota-sml-script/2_SML_Script_Chart_PV2 // (alte Version vom Okt 26 ohne lokale Datei zur Auwahl von Smartmetern) zusammen mit der PV Steuerung überfordert wohl einen ESP32 DOWD 3.1 mit 4MB Flash.
• Eventuell auch komplett umgesetzt in Tiny C als komplett lokaler Regler mit Aufzeichnungsmöglichkeit für das ständig erweiterte Zendure Produktportfolio.
• Ich war ein Jahr zu früh, sonst wäre es das Produkt geworden:
• https://www.zendure.de/products/zendure-solarflow-2400-pro
• So wie das ausschaut haben die mich und andere Kunden sowie den EU CRAct berücksichtigt und eine lokale kabelgebundenen Regelung eingebaut, bei der allerdings keine Warmwasseraufbereitung drin ist.

[mi-hol]

Updated 17May2026 19:15

Sehr interessante Lösung!
Magst Du vielleicht noch im verlinkten "Projektüberblick" die Konfiguration an den Anfang stellen und die Wp der Panels ergänzen?
damit meine ich "Die Ladeleistung des SF800Pro ist mit 2 Akkus 1.3kW, die entweder aus den eigenen Panels oder aus dem Netz kommen können. In meiner Konfiguration (2 Panels am SF800 Pro, 2 Panels am Hoymiles)" die im Nebensatz etwas untergeht.

Neu für mich war der Einsatz eines DMX Dimmers zum Betrieb eines Heizstabs mit variabler Leistung. Habe ich das richtig verstanden? Falls ja würde ich empfehlen das im Projektüberblick als Punkt "Konzept" zu ergänzen

[Spessartwald]

Hallo mi-hol, danke für den Hinweis auf das gelösche Projekt im Zen-SDK. Da es hier um eine Tasmota Applikation geht, die sowohl einen Zendure Speicher und einen Warmwasserspeicher regeln soll, ist das im Zen SDK nicht passend. Dieses Projekt basiert auf der SML Schnittstelle in Tasmota & den Ottelo9 scripts, ohne die das alles nicht entstanden wäre. In anderen Teilen der Welt ist das u.U. nicht anwendbar,z.B. wenn Bezug und Einspeisung technisch oder durch den Zähler getrennt erfasst und abgerechnet werden.

In diesem Thread geht es um die Verwendung überschüssiger Energie, z.B. als Warmwasser. Die DMX Schnittstelle in Tasmota ermöglicht die Einbindung von schnell und feinstufig regelbaren Verbrauchern. Mit günstiger und mehrkanaliger DMX Hardware können Verbraucher auch weit entfernt vom ESP zuverlässig geregelt/geschalten werden, auch wenn kein oder nur ein geringes WLAN Signal verfügbar ist. z.B. im Garten die Tauchpumpe, Gewächshausbelüftung/Leuchten, Druckluftkompressor..). Das ist also nicht beschränkt auf Heizstäbe, aber ein möglicher Ersatz bzw. eine Erweiterung für diesen 2 Punkt Regler im Energiescipt:

(Op1) Schalte anderen ESP bei Netzeinspeisung. Schaue in die >W Sektion.
if (swesp==1) {
if ((power2<-300) and (swespflg==0)) {
;->websend [192.168.0.50] power ON
;print power ON %power2%W
swespflg=1
}
if ((power2>100) and (swespflg==1)) {
;->websend [192.168.0.50] power OFF
;print power OFF %power2%W
swespflg=0

[mi-hol]

Updated 17May2026 19:20

Fragen zum Script:

1. den folgenden Teil verstehe ich noch nicht. Könntest Du da vielleicht die Absicht beschreiben?

  if (bypass==2)
     {
        =>WebQuery http://192.168.1.204/properties/write POST {"sn":"[SF800_Seriennummer]","properties":{"acmode":2,"outputLimit":0}}
        ;Heizung Ausgangsleistung entsprechend Heizkurve mit Faktor anpassen, im Arduino korrigieren
        heizsum=heizsum+(newLimit*0.05)
        heizsum=mp(heizsum <-200 -200 >200 200)
        heizg=-1*(heizsum+(newLimit*1.2))
        ->serialsend1 %0heizg%
        print Heizung an %0heizg% heizsum %0heizsum%
        acstat="heizen"
      }

speziell weil weiter unten das setzten von "bypass" auskommentiert ist:

; WEB INTERFACE
>W
...
;Bypass: {m}%0bypass% 

vielleicht würde ein Ausschnitt aus der Konsolen Ausgabe "print Heizung" helfen :)

2. bedeutet "im Arduino korrigieren", dass da auch noch Logik ausgeführt wird?
3. was ist der Grund für ntp Abfrage in der "main loop" (>S)?

; -- EVERY SECOND --
>S
;check if NTP works, otherwise arrays can be corrupted
if (year<2020)
{
print NTP not ready
break

[Spessartwald]

Der DMX Dimmer kommt aus der PA Technik, ist für Lichtanlagen gedacht und arbeitet mit Phasenanschnitt. Sowas erzeugt in dieser Leistungsklasse Oberwellen. Deswegen sind Dimmer mit CE Kennzeichnung und entprechenden Filtern teuer. Der hier verwendete Dimmer hat eine CE Kennzeichnung und ist mit ca 70€ bezahlbar. Nehm ich auch zur Dimmung von mehreren parallelgeschalteten 500W Halogenlampen, die nach wie vor das beste Licht mit einem Farbwiedergabeindex Ra=1 bieten.

1. "Bypass" ist eine Variable des SF800 Pro, die alle 30s über "getproperties" abgefragt wird und aus dem zurückgegeben JSON String, der viele weitere Variablen enthält, extrahiert wird. gemu2015 hat für sowas eine unglaublich einfache Lösung implementiert.

Solange Bypass ´0´ ist, wird der Akku auf- oder entladen, nicht geheizt. Ich hatte den Wert am Anfang in der Weboberfläche, jetzt aber durch einen Klartext, der den ´Betriebszustand´ anzeigt, ersetzt.
Wenn der Akku voll ist, speist der SF800 Pro seinen Überschuss ins Netz und bypass hat den Wert 2. Genau diesen Überschuss wollen wir verheizen. Selbstverständlich zusammen mit dem Überschuss des ungeregelten Hoymiles vom Dach, so daß die ganze Geschichte sehr netzverträglich wird.

2. Wenn bypass ´2´ wird, erhält der Arduino den Stellwert aus dem Regler (also Z.b. 500W um Einspeisung runterzufahren und zurück auf ´0´ zu kommen) über die serielle Schnittstelle. Grund für den Arduino ist die verfügbare DMX Bibliothek und die einfache Linearisierung des Heizstabs (und des Dimmers) der z.B. bei Sollwert "400W" respektive einem bestimmtem DMX Wert tatsächlich z.B. 500W ins Wasser abgibt. Ich habe den Arduino Sketch angehängt und eine Excel Mustertabelle, wie das bei meinen Heizstab aussieht.
   Ausserdem ist der Stellwert für die Heizung (also den gesendeten String in Watt) angepasst, da der Heizregelkreis ein anderes Verhalten hat als der SF800 Pro. Die Proportional- und Integralparameter sind so hochgedreht, daß das alles relativ schnell einschwingt und im speziell im Heizbetrieb bis zu ca 150W Überschus auch ins Netz gehen, um einen teuren Bezug für die Heizung zu vermeiden. Bei höheren Kp Werten wird das instabil und fängt an zu oszillieren.

3. den ntp habe ich einfach aus dem Ottello Energiezählerscript übernommen, da Zeit und Datum in der Weboberfläche ohne das wohl nicht funktionieren. Habe ich allerdings nicht ausprobiert

Dieses Projekt ist keinesfalls ´industrie´tauglich, da z.B. keine Fehler abgefangen werden. Tut seit März aber das was es soll.

Heizstabkennlinie.xlsx

[mi-hol]

3. den ntp habe ich einfach aus dem Ottello Energiezählerscript übernommen

Denke da liegt die Ursache des Performanceproblems. Der ntp Aufruf erzeugt eine in der Dauer nicht vorhersehbare Wartezeit für die main loop. Er gehört deshalb nur in die boot section ">B" (wie im Original Skript)

[Spessartwald]

Oha. Als Ausgangsbasis für die Solarsteuerung habe ich das Energiezählerscript 2_SML_Script_Chart_PV.tas vom 15.07.25 genommen.
Auf dem Energiezähler selbst läuft 2_SML_Script_Chart_PV_2.tas vom 15.07.25. Ich habe auch nochmal in der Version vom Jan 2026 nachgesehen. Im Kommentar steht: "Tasmota muss mit dem Internet verbunden sein um die aktuelle Uhrzeit via NTP zu erhalten. Ansonsten muss das Skript angepasst werden."
In allen sripts ist in der >B Sektion kein "ntp", Nur diese if Abfrage in >S. Ich hätte erwartet, daß hier nur geprüft wird, ob die Verbindung zum ntp läuft. Erzeugt das eine Wartezeit durch eine Hintergrundabfrage des Jahres im Internet?

S
; Warte auf NTP
if (year<2020) {
print NTP not ready
break
}

[ottelo9]

3. den ntp habe ich einfach aus dem Ottello Energiezählerscript übernommen

Denke da liegt die Ursache des Performanceproblems. Der ntp Aufruf erzeugt eine in der Dauer nicht vorhersehbare Wartezeit für die main loop. Er gehört deshalb nur in die boot section ">B" (wie im Original Skript)

Hi @Spessartwald Super Projekt! Danke fürs Teilen ;)

Ich wollte mich nur kurz melden: Das warten auf NTP ist nur die Abfrage der speziellen Variable "year". Das verursacht keine Verzögerung und ist in der >S Sektion. Das ist für meine Diagramme wichtig. Tasmota muss nicht unbedingt mit dem Internet verbunden sein, es muss nur mit dem lokalen NTP Server des Routers verbunden sein um eine Uhrzeit zu bekommen (nach einem Reboot).

[mi-hol]

Das warten auf NTP ist nur die Abfrage der speziellen Variable "year"

Sorry, das ist natürlich korrekt, war unter Zeitdruck zu schnell mit der Schlussfolgerung, weil ich die "Warten auf ntp" Nachricht aus der Boot section kannte. Mein Fehler :(

[Spessartwald]

Hinweis zum ´DMX Converter´:
Dieser 2€ Arduino Nano Clone mit angebautem RS485 Treiber empfängt den Sollwert der Heizleistung in Watt über die serielle Schnittstelle und wird neben dem ESP-32 platziert. Die RS485 DMX Leitung sollte bis 50m Entfernung zum DMX Dimmer keine Probleme machen. D.h. daß der ESP mit der Solarsteuerung z.B. unterm Dach sein kann, und der WW Boiler im Keller .

Die DMX Wert Linearisierung ist fest als look-up-table im Progmem des Arduino hinterlegt. Erstmaliges Compilieren des sketches erfolgt mit 256 Werten von 0..255 in einem array. Die Linearisierung ist erforderlich, da der DMX (Licht-) dimmer nichtlinear arbeitet (Helligkeitsempfinden des Auges ist nichtlinear), und der Heizstab aufgrund der Erwärmung ebenfalls nichtlinear ist.

Das Procedere zur Linearisierung ist relativ einfach. PC mit Terminal mit dem Arduino verbinden und nach dem Einschalten die Heizstableistung eingeben. Bei mir 1.5KW, also "H,1500". Nach einem Boot ist dieser Wert fest im EEPROM.
Danach über das Terminal z.B. "P,100" senden und am Energiezähler den tatsächlichen Bezug ablesen. Selbstverständlich zu einem Zeitpunkt an dem andere Verbraucher im Haus Ruhe geben. Tabelle in excel erstellen, z.B. 100W Soll ergibt 120W Ist. Das habe ich in festen Schritten gemacht, Werte dazwischen interpoliert. Ergebnis ist eine Tabelle, die einen DMX Wert, z.B. 127 für 750Watt (gesendet von der Solarsteuerung für Nulleinspeisung´ ) auf einen DMX wert mapped, der tatsächlich 750W Heizleistung ergibt.
Das neue nichlineare (1dimensional) DMX array in den sketch ins array kopieren und neu compilieren.
Tasmota_DMX_Interface_13.txt

Diese Heizungssteuerung arbeitet flott. Der Sollwert sollte in einer Sekunde erreicht werden.

[ottelo9]

Ich habe ebenfalls mit meinen neu erstellen Images Probleme. Das DMX Beispielprogramm (auch selbst kompiliert) funktioniert leider nicht, ich sehe kein DMX Button. Ich habe @gemu2015 eben mal angeschrieben.

Nur das Beispiel marstek_emu.tc funktioniert. sml_chart nicht (mehr habe ich erstmal nicht getestet).

[ottelo9]

@gemu2015 hat den Fehler behoben. Bei mir lief es nämlich nicht auf einem ESP32-C3. Jetzt geht's. Das Script muss selbst mit der TinyC IDE kompiliert werden, das Binary wurde noch nicht aktualisiert.

dmx_dimmer_panel.tc

[Spessartwald]

Habe soeben ein Binary runterladen können. Das DMX Menu ist da. Werde das im Lauf der nächsten Tage probieren. Mit dem Editor komme ich noch nicht zurecht. Ich hätte erwartet, daß die .tcb aus der Slotliste verschwinden, wenn Delete ALL gewählt wird.
Aber das gehört nicht hierher.

Da DMX dann wohl verfügbar ist, macht es evtl. Sinn das ganze oben beschriebene Projekt auf TinyC zu portieren, wenn die Zählerscripts das auch sind. Dadurch kann ein ESP weggelassen werden, und aus der "Energieverbrauchsanzeige" wird eine komplette PV Steuerung incl. Regelung der Energieverteilung zum Akku und weiteren Verbrauchern.

Das war ja mein Ziel für die Zendure SolarFlows - eine lokale Alternative zur Herstellerapp &-cloud, incl. weiteren Funktionen - nur mit Tasmota, ohne Homeassistant.

[mi-hol]

@gemu2015 hat den Fehler behoben.

@ottelo9 Weisst Du vielleicht wie der Fehler behoben wurde?
War es vielleicht der commit gemu2015/Sonoff-Tasmota@3d4a2df ?

Nur das Beispiel marstek_emu.tc funktioniert. sml_chart nicht (mehr habe ich erstmal nicht getestet).

Die vorhandenen Zählerskripte (sml_*.tc) fehlen nämlich auch in der bei obigem commit veränderten index.txt

[mi-hol]

Da DMX dann wohl verfügbar ist, macht es evtl. Sinn das ganze oben beschriebene Projekt auf TinyC zu portieren,

@Spessartwald hatte gehofft, dass Du das auch so siehst :)
Leider scheint es, dass die Entwicklung des Codes sehr schnell geht, aber die Dokumentation & Kommunikation damit nicht Schritt hält.
Anders ausgedrückt, wird die Portierung wahrscheinlich noch ein paar frustrierende Momente erzeugen. Also nicht kleinkriegen lassen!

[ottelo9]

Ich habe mal etwas recherchiert z.B. hier und Phasenanschnitt kenn ich noch aus der Ausbildung/Studium. Ein DMX-Dimmer macht doch auch nichts anderes wie ein Phasenanschnitt (TRIAC) oder liege ich da falsch?

Quelle, siehe Link.

Phasenanschnitt ist eine weit verbreitete Art zur Leistungsregelung von ohmschen Verbrauchern und bei kleineren Leistungen relativ problemlos. E-Heizstäbe haben in der Regel eine Leistung von 3 kW aufwärts, bei der durch den Phasenanschnitt allerdings eine nennenswerte Phasenverschiebung verursacht wird. Die genormten Anschlussregeln für Niederspannungsnetze in Deutschland (VDE-AR-N 4100) und Österreich (TOR D1 2004) sowie die darauf aufbauenden Technischen Anschlussbedingungen der EVUs (TAB 2007 und TAEV 2016) erlauben die Phasenanschnittsteuerung für Geräte zur Warmwassererzeugung nur bis 200 Watt Leistung.

Wir setzen in der Firma zum Steuern/Regeln von kleinen Heizpatronen deshalb Solid State Relais mit Nulldurchgang ein. Von Siemens gibt es dazu auch passende PWM-Steller, die auf die SSR draufgeklickt werden.

Ich schau mal nach, welches Modell es war.

[Spessartwald]

Das ist soweit korrekt und zum Thema ´SSR´ gibt´s etliche Foren. Suche nach Wellenpaketsteuerung. Z.B:
https://www.photovoltaikforum.com/thread/159350-heizungssteuerung-mit-z-b-wellenpaket-bei-smartmeter/?pageNo=4

Das Problem bei diesen Dingern sind die smarten Zähler, die abhängig von der Integrationsdauer (Saldo Bezug/Einspeisung z.B. über 100ms über 3 Phasen) und je nach SSR Ansteuerung "0" anzeigen oder auch nicht.
Wird z.B. konstant 100W auf L1 eingespeist, und auf L2 ein 200W Heizstab mit einer Periodendauer von 1s zu 50% eingeschalten (aslo 500ms an, 500ms aus) ergibt sich leider keine Nulleinspeisung, sondern es wird bezogen/bezahlt und gleichzeitig verschenkt.

Bei einer Integrationsdauer von z.B. 100ms des Zählers bleiben darüberhinaus nur 10 Halbwellen für eine Dimmung wenn im Nulldurchgang geschalten wird (geht nicht bei allen SSR, hängt von der Triggerschaltung ab). Was auch nicht besser ist als Phasenanschnitt, da z.B. Gleichanteile entstehen. Wenn nur Vollwellen geschalten werden, was bei den meisten SSR der Fall sein dürfte, verbleiben bei so einem Zähler deren 5. Das ist unzureichend für eine feine Regelung. Die Lösung mit einem steuerbaren Industrienetzteil ist aus dieser Sicht die bessere. Ob das wirtschaftlich für ein Balkon-PV umsetzbar ist, ist eine andere Frage.

Die Smartmeter verhalten sich je nach Hersteller unterschiedlich. Am besten funktioniert ein Ferraris Zähler...