Monatsrückblick Oktober 2026 ist online!

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:

Nachdem ich jetzt ein paar Tage den Fehler Zendure IP überprüfen beobachtet habe, kann ich folgendes feststelln.

Der Fehler tritt immer auf, wenn das Gerät am Abend mit Sonnenuntergang bzw. PV Eingang 0 Watt hat und wegen dem Wetter so wenig ertrag kam, das er auch gleich auf SOC min ist. Somit werden über sehr lange Zeit keine Steuerbefehle mehr gesendet und ich vermute, das das Gerät dann nach ca.13 Stunden in einen Tiefschlaf geht.

Das ist absolut nachvollziehbar.
Das Abschalten des WLAN-Moduls oder das Versetzen der MCU in einen tiefen Schlafmodus ist eine gängige Schutzfunktion, da die Netzwerkkommunikation einen nicht unerheblichen Teil des Eigenstrombedarfs des Geräts ausmacht.
Wenn über Stunden keine Aktivität (weder PV-Ertrag noch Steuerbefehle) registriert wird, greift irgendwann das Energiemanagement, um eine Tiefentladung der Zellen zu verhindern.

Interessant wäre nun zu wissen:
• Auf wie viel % steht dein minSoc aktuell?

Der steht auf 50%

• Welchen Wert hat/haben die Batterie(n) dabei bei minVol (niedrigste Zellspannung)?

Das habe ich nicht geschaut. Wenn es dir wichtig ist, kann ich das gerne noch machen.

Zusätzlich wäre es gut zu beobachten, wie sich die originale App in diesem Zustand verhält:

• Meldet die App das Gerät zu diesem Zeitpunkt noch als online?

Nein die App meldet ihn als Offline und versucht per Bluetooth zu verbinden was aber auch nicht funktioniert.

• Lassen sich über die App noch Werte verändern?

Ob man Werte verändern kann habe ich nicht getestet. Kann ich aber gerne nachholen.

Falls ja, wäre wichtig festzustellen, ob das Gerät durch die App-Aktivität kurzzeitig aus dem Tiefschlaf erwacht und diese Befehle dann auch tatsächlich ausführt.
Das würde uns zeigen, ob das Gerät im Schlafmodus noch auf bestimmte Wake-up-Signale (z. B. via Bluetooth oder die Cloud-Schnittstelle) reagiert.

[maxclaudi]

@Daniel-8
Deine Rückmeldung bestärkt meine Vermutung.
Dein Akku steht ja draußen im Kalten?

Wenn ja, tippe ich stark darauf, dass die integrierte Akkuheizung aktiv war.

Die Heizung zieht extrem viel Strom.
Wenn das Wetter tagsüber so schlecht war, dass der Akku ohnehin kaum geladen wurde, und nachts die Heizung anspringt, ist der Energiebedarf gigantisch.
Um zu verhindern, dass die Heizung den Akku im Winter komplett leersaugt (selbst wenn du den Schutz auf 50 % minSoc gestellt hast), greift vermutlich der Sicherheitsmechanismus der Firmware:
Bei Erreichen des Limits wird dem gesamten System - inklusive WLAN - komplett der Saft abgedreht, um die Zellen zu schützen.
Ein SolarFlow 800 Pro geht normalerweise nicht einfach so grundlos in einen so tiefen Schlaf, dass selbst WLAN abgeschaltet wird – es sei denn, ein interner Großverbraucher wie die Heizung hat das System in den Not-Standby gezwungen.
Da die App das Gerät als offline anzeigt, brauchst du auch keine Wertänderungen testen.
Falls du doch mal die Gelegenheit hast, schau morgens (wenn das Gerät erwacht) mal auf die Werte und ob Heizung aktiv ist.
Die Temperaturen und vor allem die Zellspannungen (minVol) wären dennoch extrem interessant.
So kann man sehen, ob die tatsächlichen Werte mit den 50 % SoC übereinstimmen oder ob die SoC-Berechnung aufgrund einer fehlenden Kalibrierung einfach nicht mehr stimmt.

Du solltest deinen Akku am besten einpacken (isolieren) oder anderweitig vor den tieferen Temperaturen schützen, um diesen massiven nächtlichen Energieverlust zu verhindern.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8
Deine Rückmeldung bestärkt meine Vermutung.
Dein Akku steht ja draußen im Kalten?

Ja der steht draußen.

Wenn ja, tippe ich stark darauf, dass die integrierte Akkuheizung aktiv war.

Aber war es bis jetzt nicht so, das die Heizung erst angeht, wenn er unter 0° hat und laden will?

Ich hatte noch nie gesehen, das die Akkuheizung nachts an war. Zudem diese ja sowieso nur mit AC funktioniert. Man kann die Heizung nicht über Solarenergie betreiben.

Die Heizung zieht extrem viel Strom.
Wenn das Wetter tagsüber so schlecht war, dass der Akku ohnehin kaum geladen wurde, und nachts die Heizung anspringt, ist der Energiebedarf gigantisch.
Um zu verhindern, dass die Heizung den Akku im Winter komplett leersaugt (selbst wenn du den Schutz auf 50 % minSoc gestellt hast), greift vermutlich der Sicherheitsmechanismus der Firmware:
Bei Erreichen des Limits wird dem gesamten System - inklusive WLAN - komplett der Saft abgedreht, um die Zellen zu schützen.
Ein SolarFlow 800 Pro geht normalerweise nicht einfach so grundlos in einen so tiefen Schlaf, dass selbst WLAN abgeschaltet wird – es sei denn, ein interner Großverbraucher wie die Heizung hat das System in den Not-Standby gezwungen.
Da die App das Gerät als offline anzeigt, brauchst du auch keine Wertänderungen testen.
Falls du doch mal die Gelegenheit hast, schau morgens (wenn das Gerät erwacht) mal auf die Werte und ob Heizung aktiv ist.

Auf welche werte meinst du?

Die Temperaturen und vor allem die Zellspannungen (minVol) wären dennoch extrem interessant.
So kann man sehen, ob die tatsächlichen Werte mit den 50 % SoC übereinstimmen oder ob die SoC-Berechnung aufgrund einer fehlenden Kalibrierung einfach nicht mehr stimmt.

Kann ich mal schauen. Die Kalibrierung ist erst 5 Tage her.

Du solltest deinen Akku am besten einpacken (isolieren) oder anderweitig vor den tieferen Temperaturen schützen, um diesen massiven nächtlichen Energieverlust zu verhindern.

Ich habe nur ca. 2 Prozent über Nacht Verlust

[Berny-K]

Hallo guten Morgen,
ich hatte mit meunemSF800Pro die Tage das gleiche Problem, dass der offline ging und ich erinnere mich, dass ich das letzten Winter auch schon mal hatte, die gleichen Symptome wie hier beschrieben. Ich habe dann den Netzstecker gezogen, die Module abgeklemmt und neu gestartet. Danach wieder alles abgeklemmt und dann hat wieder alles funktioniert. Mein SF800Pro steht allerdings im warmen, da läuft sicher keine Heizung.

[Daniel 8]

@Berny-K sagte:

Hallo guten Morgen,
ich hatte mit meunemSF800Pro die Tage das gleiche Problem, dass der offline ging und ich erinnere mich, dass ich das letzten Winter auch schon mal hatte, die gleichen Symptome wie hier beschrieben. Ich habe dann den Netzstecker gezogen, die Module abgeklemmt und neu gestartet. Danach wieder alles abgeklemmt und dann hat wieder alles funktioniert. Mein SF800Pro steht allerdings im warmen, da läuft sicher keine Heizung.

Für mich ist das auch kein Problem. Es war eigentlich nur eine feststellung und auch Mitteilung damit andere auch informiert sind und sich nicht über das verhalten wundern

[maxclaudi]

@Daniel-8 sagte:
Auf welche werte meinst du?

packData.xxxx.

• maxTemp
• maxVol
• minVol

properties:

• BatVolt
• electricLevel
• faultLevel
• heatState
• hyperTmp
• is_error
• socStatus
• dataReady

[maxclaudi]

@Berny-K
Nun, das ist – verzeih mir die Ausdrucksweise – Hardcore für die Hardware.
Das funktioniert und bekämpft die Symptome, aber es behebt nicht die Ursache ;-)

[maxclaudi]

@Daniel-8

zum Vergleich:
aktuell ist das 2400ACpro-Testsystem auf der Terrasse mit
• hyperTmp 9°C
• maxTemp 8°C
Wie es dann in der Nacht aussah kann man sich vorstellen.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8

zum Vergleich:
aktuell ist das 2400ACpro-Testsystem auf der Terrasse mit
• hyperTmp 9°C

Bei mir aktuell 20°C

• maxTemp 8°C

Im Moment auch 7 und 6.

Wie es dann in der Nacht aussah kann man sich vorstellen.

Nachts vermutlich bisschen weniger. Hatten heute Morgen 2°C Außentemperatur.

[maxclaudi]

@Daniel-8 sagte:
Für mich ist das auch kein Problem. Es war eigentlich nur eine feststellung und auch Mitteilung damit andere auch informiert sind und sich nicht über das verhalten wundern

Finde das für Alle eine wertvolle Information.

Wenn sowieso Standby ist und es absolut nichts zu tun gibt, dann ist dieses Verhalten der Firmware aus Sicht des Energiemanagements doch nahezu ideal, oder nicht?

WLAN und Bluetooth im Dauer-Standby ziehen über die vielen Stunden der Dunkelheit nur unnötig Strom aus den Zellen.
Die MCU komplett schlafen zu legen und morgens rein hardwareseitig über den ersten PV-Strom wieder zu wecken, ist die effizienteste Methode, um den Akku im Winter zu schonen. Man benötigt ja keine Live-Infos auf dem Dashboard, wenn es ohnehin nichts zu steuern gibt. Sobald das Gerät morgens wieder von allein erwacht, ist alles perfekt gelöst.

Hätte man es als Software-Architekt besser lösen können?
Persönlich denke ich: Nein, im Kern nicht. Das harte Abschalten ist die sicherste Methode. Wenn die Verbindung gekappt ist, kann kein (fehlerhaftes) externes Skript oder eine hängende Cloud-Verbindung das System nachts ungewollt wachhalten und den Akku leersaugen.

Das Einzige, was ich als Entwickler zusätzlich implementiert hätte, wäre eine saubere Status-Meldung vor dem Einschlafen: Dass das Gerät einen letzten MQTT- oder HTTP-Befehl absetzt ("Inaktivität - gehe in Deep-Sleep"), bevor es die Funkmodule abschaltet. Dann würde die App oder ein Skript nicht "Verbindung verloren / Fehler" melden, sondern den sauberen Status "Schläft tief (Warten auf Sonne)" ausgeben.

edit/PS:
ich hätte mir allerdings schon zusätzlich Gedanken gemacht, ob es nicht sinnvoll gewesen wäre, eine echte Sicherheitsabfrage einzubauen.
Ideal wäre eine Logik wie: „Standby vorgesehen in X Minuten/Sekunden“. Wenn innerhalb dieses definierten Zeitfensters kein aktiver Wachhaltebefehl (wie z. B. ein neuer Lade- oder Steuerbefehl) vom Skript oder der App reinkommt, fährt das System erst dann kontrolliert in den Deep-Sleep.

So wie es jetzt gelöst ist, ist es eben ein sehr harter, kompromissloser Schnitt der Firmware, ohne dem lokalen System noch eine Chance zur Reaktion zu geben.

[Berny-K]

@maxclaudi
Da gib ich dir absolut recht aber ich wusste mir einfach nicht anders zu helfen. Werde das mal beobachten, wenn es wieder passiert, ob er von selbst wieder online geht sobald genügend PV-Leistung anliegt.

[maxclaudi]

@Berny-K
Alles gut, man erschrickt ja erst mal, wenn das System plötzlich totzuspringen scheint.
Beobachte das beim nächsten Mal einfach ganz entspannt.
Sobald die Panels morgens wieder um die ca. 40 Watt liefern, sollte der Eigenverbrauch gedeckt sein und das Gerät taucht von alleine wieder im WLAN auf. Der harte Reboot sollte nicht nötig sein.

edit/PS:
Wundere dich aber nicht über die Zahlen in der App: Das System zieht den internen Eigenverbrauch ab und meldet dann meist nur ca. 10 Watt Einspeisung.

edit/PPS:
@Berny-K (und @Daniel-8)
Noch eine Vermutung von mir:
Ich denke nicht, dass so ein radikales Steckerziehen überhaupt nötig ist, wenn man das System mal zwischendurch manuell wecken möchte.
Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert?

[Daniel 8]

@maxclaudi sagte:

Wenn sowieso Standby ist und es absolut nichts zu tun gibt, dann ist dieses Verhalten der Firmware aus Sicht des Energiemanagements doch nahezu ideal, oder nicht?

Ja ideal ist es mehr oder weniger gut Die Zeit mit ca. 13 Stunden ist schon lange. Er ist grad mal so ne Stunde im Tiefschlaf.

[Daniel 8]

@maxclaudi sagte:

Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert?

Nein weil ich sehr schlecht hin komme wo der Speicher steht.

[maxclaudi]

@Daniel-8 sagte:
Nein weil ich sehr schlecht hin komme wo der Speicher steht.

Für so ein Szenario fällt mir spontan ein kleiner Fingerbot mit Akku ein, den man einfach über das Handy oder ioBroker triggert! :-)))

Der drückt dann per Funk den Knopf für dich, und du musst nicht jedes Mal in die schwer zugängliche Ecke krabbeln.
Das wäre eine Smart-Home-Lösung für das "Deep-Sleep-Problem" im Winter :-)

War nur scherzhaft ;-)

Wobei - mich erinnert das Ganze an die Anfangszeit mit dem HUB2000 und dem ACE1500.
Da gab es auch Fälle, in denen nur vor Ort ein physisches Aus- und wieder Einschalten half.
Weil ich öfter nicht vor Ort bin, ist so etwas für mich der absolute Worst Case. Ich war damals tatsächlich kurz drauf und dran, einen Fingerbot zu verwenden.

Aber der Hub ließ sich - im Gegensatz zu den neuen Geräten - noch zerstörungsfrei öffnen.
Ich habe damals einfach einen kleinen ESP8266 mit Optokoppler parallel zur physischen IoT-Taste gelötet, um eine zuverlässige Fernsteuerung zu ermöglichen.

[Berny-K]

@maxclaudi
Bei mir hat das mit der IoT Taste leider auch nicht funktioniert.Ich konnte ihn auch nach mehreren Versuchen damit nicht wieder aufwecken.

[Daniel 8]

@maxclaudi sagte:

Für so ein Szenario fällt mir spontan ein kleiner Fingerbot mit Akku ein, den man einfach über das Handy oder ioBroker triggert! :-)))

Sowas hätte ich fast schon mal gekauft aber nicht für den zendure sondern für den Growatt.

Also ich habe den Tausch zu Zendure bis jetzt nicht bereut.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Auf welche werte meinst du?

packData.xxxx.

• maxTemp

beide 8°C

• maxVol

beide 3,27V

• minVol

3,27V und 3,28V

properties:

• BatVolt

49,39V

• electricLevel

49%

• faultLevel

0

• heatStat

0 unverändert seit 23.06.2026

• hyperTmp

8°C

• is_error

0

• socStatus

0

• dataReady

1

Anbei mal die Werte

[maxclaudi]

@Daniel-8
Die Zahlen sind aufschlussreich und bestätigen ein altbekanntes Phänomen bei LiFePO4-Zellen:

Deine Zellspannungen liegen stabil bei 3,27V bis 3,28V, die Gesamtspannung bei 49,39V.
Bei einem 15S-Akku ist das physikalisch ein absolut gesunder, noch gut gefüllter Zustand - chemisch entspricht das eher 60% bis 70% realer Kapazität.

Dass die Firmware 49% ausgibt und das Gerät wegen deines Limits (50%) kurz darauf schlafen schickt, bedeutet:
Die softwareseitige SoC-Berechnung der Firmware läuft zu ungenau, selbst wenn deine Kalibrierung erst 5 Tage her ist.
Vermutlich wurde nicht richtig bzw. vollständig kalibriert.

Wenn das die Werte sind nach dem Aufwachen, dann schaltet das Gerät nicht ab, weil der Akku real leer ist oder die Heizung ihn leergesaugt hat, sondern weil die Firmware sich "verrechnet" hat und fälschlicherweise denkt, der Mindest-SoC sei erreicht.
Physikalisch ist die Batterie noch top.

[maxclaudi]

@Daniel-8

Du hättest zwei Optionen, um das Problem zu lösen:

• Option 1 (Neukalibrierung): Die Kalibrierung noch einmal durchführen. Akku auf 100 % laden und ruhen lassen.
  Danach noch mal sanft nachladen, bis die 100 % garantiert erreicht sind.
  Anschließend bis auf 5 % entladen und nochmals vollständig auf 100 % aufladen.
  Dann sollte die SoC-Berechnung der Firmware eher stimmen.

• Option 2 (Die Skript-Lösung):
  Die kennst Du doch inzwischen ;-)
  Den minSoc in der Firmware auf 10 bis 15 % absenken und die Abschaltung vollständig einem geprüften, sicheren Skript anvertrauen.
  Das Skript überwacht die realen Zellspannungen und schaltet den Entladevorgang sicher ab, sobald die minVol einer einzigen Zelle aller Batterien einen definierten Spannungswert erreicht.

Ich bevorzuge den zweiten Weg, unabhängig von der ungenauen Prozentberechnung der Firmware.