Monatsrückblick Oktober 2026 ist online!

[maxclaudi]

@Murphy-0 sagte:

@maxclaudi
super Sache, Cloudfree ohne Neustart vom Hyper ist eine echte Verbesserung.
Sollte man den Hyper mit neuester Firmware Cloudfree betreiben wäre die ultimative Lösung mit so einer Software zurück auf unverschlüsseltem Datentransfer zum mqtt Server stellen zu können. 😁

@Murphy-0 Technisch ist der Weg in der Firmware tatsächlich vorhanden. Die Variablen für eine unverschlüsselte Verbindung existieren im Code:

Edit
Schade, der Edit musste leider sein.
Urheberrecht (Copyright) am Code und der Firmware liegt vollständig beim Hersteller. Um rechtliche Probleme für mich und das Forum zu vermeiden, kann ich keinen kleinen Code-Auszug posten.

Broker ohne TLS über 1883 unter bestimmten Bedingungen möglich, ohne in die Firmware einzugreifen.

Das Problem dabei:
Das Ganze sauber zu analysieren, ist extrem viel Arbeit. Ich schaue mir an, ob es einen offiziell vorgesehenen und einfachen Weg gibt, diese Parameter per Bluetooth oder über ein MQTT-Kommando zu steuern.
Sollte es diese integrierte Möglichkeit nicht geben, werde ich das nicht weiter verfolgen.
Ein Eingriff in die Firmware (wie das Patchen von Speicherbereichen oder Flashen modifizierter Partitionen) kommt für mich nicht in Frage.
Die Firmware wird von mir niemals verändert!

Mein Fokus liegt nur rein auf dem Analysieren der vorhandenen und funktionierenden HTTP(s)-, MQTT- und Bluetooth-Konfigurationen, die vom Hersteller bereits eingebaut sind und genutzt werden können.

---

Update 30.09.2026 01:26h:
Inzwischen habe ich diesen Weg weiter verfolgt. Aktuell ist noch unklar und muss weiter analysiert werden, ob das reine Setzen eines einzelnen Flags ausreicht, damit die Firmware in den unverschlüsselten Modus (Port 1883 statt 8883 mit TLS) wechselt und dieser Zustand auch dauerhaft erhalten bleibt.
Für heute brauche ich nach stundenlanger Arbeit aber erst mal dringend eine Pause.

[T-147]

Guten Morgen allerseits,

mein SF800 Pro2 läuft jetzt seit gut 2 Monaten mit dem Blockly und wurde aufmerksam von mir beobachtet. Ein paar Dinge sind mir persönlich aufgefallen, zu denen ich Euch mal befragen wollte.
Außerdem habe ich dann mit erstaunen festgestellt, wie viel sich in der Zeit wieder in dem Blockly verändert hat. Beim umstellen der Vorlage auf meine Gerätschaften kam mir dann noch eine Idee, dazu aber gleich mehr.

Im Juli und August war es bei meinem SF800 Pro2 mit 2 Akkus kein Problem, das Ding so ziemlich täglich auf 100% zu laden. Heißt also, es gab keine automatische Kalibrierung.
Jetzt im September wurde das mit den 100% aber schon schwieriger und ich hab in meinen Aufzeichnungen gesehen, dass immer mal wieder nachts um 1:00 Uhr (Standard-Kalibrierungszeit der App) das Laden mit voller Last begonnen und kurz darauf wieder beendet wurde. Also keine vollständige Kalibrierung, weil das Blockly sofort wieder die Steuerung übernimmt, wenn der Akku etwas aufgeladen ist und wieder auf Entladen wechselt. Das ganze kann ich tagsüber beliebig reproduzieren, wenn ich manuell auf Laden stelle (zB über die App). Da kommt mir die Frage: Wie realisiert Ihr das mit dem Kalibrieren, ohne dass die Steuerung dazwischen funkt?
Das aktuelle Blockly hat zwar Parameter für DPL an/aus, aber das wird hier offensichtlich nicht für eine Kalibrierung eingesetzt. Oder hab ich tatsächlich was übersehen?

Eine weitere Sache: Beim Aufladen morgens schwenkt das System immer wieder zwischen Laden/Entladen hin und her. Ich würde dem System gerne verständlich machen, dass der Akku morgens erst bis zB 15% aufladen soll, bevor er überhaupt wieder entladen darf. Er soll aber trotzdem nachts bis zB 10% entladen dürfen (ist das verständlich ausgedrückt?) Ich hab das Gefühl, das aktuelle Blockly könnte das realisieren, aber da blick ich noch nicht ganz durch.

Und die dritte Sache: in dem Blockly sind ja wahnsinnig viele Objekt-IDs, die ich jetzt erstmal alle einzeln anpassen musste. Könnte man das evtl durch eine Variable ersetzen? Dann müsste man die Variable nur in den Settings zu Beginn des Blockly einmal anpassen und alle Objekt-IDs würden damit automatisch angepasst. Bin das Script jetzt 3x durch und hab jedes Mal irgendwo was vergessen anzupassen

So in dieser Art vielleicht:

Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen. Veränder ich den Wert dann in der App oder im ioBroker manuell springt die Regelung sofort wieder an.

Besten Dank und weiterhin frohes Schaffen
Marian

[maxclaudi]

Bin momentan zu beschäftigt. Deshalb nur kurz zu deinem 'Edit':

@T-147 sagte:
Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen.

Eine Leistung von 150 Watt über 20 Minuten entspricht einem Verbrauch von 0,05 kWh (Kilowattstunden). Bei einem durchschnittlichen Strompreis von rund 37 Cent pro kWh sind das ca. 1,85 Cent.
So schlimm ist das m. M. n. nicht. Die Hardware wird es Dir danken.

[T-147]

@maxclaudi
Kein Ding, ist ja auch kein Weltuntergang. Läuft ja sonst alles echt super.

Geht mir auch überhaupt nicht um die paar Watt, die ins Netz gehen. Vor dem SF800 und deinem Script ging aufs Jahr gesehen 50% von meinem PV-Ertrag ins Netz, jetzt sind es weniger als 10%!
Mir gehts vielmehr um das reine Verständnis der Funktionsweise des SF800 und des Scripts/Blockly, also was genau wann wofür zuständig ist.

Ich switche am Wochenende mal auf das aktuellere Blockly und schaue einfach mal, inwieweit sich das Verhalten ändert, ist ja doch einiges dazugekommen.

Und gerne nochmal: Vielen Dank für deine Arbeit und den Einsatz!

[petman]

@T-147 sagte:

Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen. Veränder ich den Wert dann in der App oder im ioBroker manuell springt die Regelung sofort wieder an.

Besten Dank und weiterhin frohes Schaffen

Hallo ich habe die gleichen Probleme bei meinem SF800pro2 am Morgen. Scheint ein Problem der Firmware zu sein.
Letzte Woche hatten wir einen Stromausfall einer Phase im Netz. Als der Strom wieder ok war, hat der SF800pro2 mit maximaler Leistung aus dem Netz geladen obwohl nur max 50W eingestellt ist.

peter

[T-147]

@petman

Ich fahre aktuell noch auf Firmware 2.0.0. Wie sieht's bei dir aus?

[maxclaudi]

• Datenschutz, entfernt

[maxclaudi]

@T-147 sagte:

@petman

Ich fahre aktuell noch auf Firmware 2.0.0. Wie sieht's bei dir aus?

Falls V2.0.2 angeboten wird: kann man m. M. n. bedenkenlos verwenden.

Bei > V2.0.2
z.B. V2.0.4 kann ich nicht bewerten.

[maxclaudi]

• Datenschutz - entfernt.

[maxclaudi]

maxclaudi sagte:
Das ist der Moment, um es live zu testen. ...

Funktionierte nicht.
<Datenschutz> benötigt 'zuvor' ein zusätzliches Flag <Datenschutz>
Gefunden - ausgeführt.

H E U R E K A !

Ergebnis stabil seit 03.10.2026 14:01 Uhr.

---

edit/update 07.10.26; 19:50h:
1600AC+ Port 1887 (kein TLS) läuft schnell, stabil - ohne reconnect - seit dem 03.10.2026 um 14:01 Uhr.

.... Bilder sagen mehr als Worte

[MP_Trixi]

Mal eine vielleicht doofe Frage zwischendurch. Ich wollte eigentlich, wenn die Haupt-PV-Anlage zu viel Strom liefert und deren große Batterie schon voll ist, die Batterien meiner SolarFlow800 Pro2 mit Überschuss laden. Dann stelle ich ...control.auto_in_out_Limit auf z.B. -1000W (das ist das Maximum das in der App eingestellt werden kann, wenn weniger vorhanden ist auch weniger). In der App sieht man dass er die "Einstellungen für den Netzanschluss" von "Netzausgangsmodus" auf "Netzeingangsmodus" mit der entsprechenden W-Zahl übernimmt. Er lädt aber nicht (zusätzlich) vom Netz sondern nur was von der PV kommt (aktuell 665W bei 57% SoC). Kann das Gerät überhaupt parallel von der PV und vom Netz laden? Oder geht, so wie es aussieht, nur entweder oder?

[maxclaudi]

@MP_Trixi sagte:
Mal eine vielleicht doofe Frage zwischendurch.

M. M. n. gibt es keine doofen Fragen.
Wenn überhaupt, dann gibt es höchstens themenfremde Fragen.
Das ist Deine Frage nicht.

Ich sehe es gerne und hoffe sehr, dass alle, die Fragen haben, auch fragen und alle, die sie beantworten können, auch antworten.
Nur so lebt ein Projekt.

Ich wollte eigentlich, wenn die Haupt-PV-Anlage zu viel Strom liefert und deren große Batterie schon voll ist, die Batterien meiner SolarFlow800 Pro2 mit Überschuss laden.

Funktioniert.

Dann stelle ich ...control.auto_in_out_Limit auf z.B. -1000W (das ist das Maximum das in der App eingestellt werden kann, wenn weniger vorhanden ist auch weniger). In der App sieht man dass er die "Einstellungen für den Netzanschluss" von "Netzausgangsmodus" auf "Netzeingangsmodus" mit der entsprechenden W-Zahl übernimmt.

Richtig, so soll es sein.

Er lädt aber nicht (zusätzlich) vom Netz sondern nur was von der PV kommt (aktuell 665W bei 57% SoC).

Jetzt wird es interessant, denn hier stimmt etwas nicht.
Normalerweise priorisiert die Firmware die PV-Leistung.
Das bedeutet: Wenn 1000 W Ladeleistung eingestellt sind und z. B. 665 W von der PV kommen, sollten die restlichen 335 W bzw. 330 W zusätzlich aus dem Netz geladen werden.

Voraussetzungen – bitte über die Datenpunkte verifizieren:

• acMode: 1

• chargeMaxLimit: 1000 • (bzw. größer als die aktuelle PV-Leistung. Wichtig: Diesen Wert würde ich nach Möglichkeit nicht ständig ändern, da er in den Flash-Speicher / NVS geschrieben wird).

• inputLimit: 1000 (bzw. größer als die aktuelle PV-Leistung)

• aiState: 0

• electricLevel: < socSet und electricLevel < socSet - ca. 10 %

• hyperTmp: nicht zu hoch (ca. < 52 °C)

• pass: 0

• socStatus: 0

• Temperaturen der Batterien (maxTemp): nicht zu hoch (ca. < 32 °C, optimal über 15–20 °C)

• HEMS deaktiviert (bei Steuerung per Skript)

• Keine Automatikprogramme der APP aktiviert?

Wenn über das Netz geladen wird, sollte der Datenpunkt gridInputPower != 0 sein.

Idealerweise, aber nicht zwingend als Bedingung:
• heatState: 0
• faultLevel: 0

Kann das Gerät überhaupt parallel von der PV und vom Netz laden?

Ja
edit:
Meines Wissens ist es gar nicht anders möglich: Wenn an einem Zendure-Gerät – wie deinem SolarFlow 800 Pro 2 – an den physischen MC4-Eingängen PV-Module angeschlossen sind und Leistung produziert wird, wird diese vorhandene PV-Leistung immer priorisiert.
Überschüssige PV-Leistung wird – je nach Einstellung – eingespeist oder eben nicht verwertet. Reicht die PV-Leistung hingegen nicht aus, wird die Differenz zur eingestellten Ladeleistung automatisch aus dem Hausnetz bezogen.

Anders sieht das aus, wenn über einen Mikrowechselrichter an der gridOff-Steckdose eingespeist wird.
Dieser Strom zählt im System nicht als direkte PV-Leistung.

Oder geht, so wie es aussieht, nur entweder oder?

Nein.

Die Firmware-Version wäre für mich interessant, falls es trotzdem nicht funktioniert.

[MP_Trixi]

@maxclaudi

gut, dass Du das so siehst - ab und an wird man ja heute gesteinigt wenn man für andere offensichtliche Dinge frägt.
Danke für Deinen Input, denke damit habe ich es gefunden. chargeMaxLimit stand auf 0. Wenn ich das auf 1000 setze lädt er sogar 1000W von AC Plus PV-Eingang (aktuell sind das dann in Summe rund 1500W). Wenn ich das richtig interpretiere lasse ich chargeMaxLimit auf 1000 und steuere den tatsächlichen Wert (so wie der Überschuss verfügbar ist) über ...control.auto_in_out_Limit (FW habe ich noch V1.0.2 - da bin ich mir immer noch unschlüssig ob ich auf V2.0.2 gehen soll).

[maxclaudi]

@MP_Trixi sagte:

@maxclaudi

gut, dass Du das so siehst - ab und an wird man ja heute gesteinigt wenn man für andere offensichtliche Dinge frägt.

Mach dir nichts daraus! ;-)
Ich werde hier manchmal sogar für belegbare Aussagen angezweifelt.
Da kommen dann oft nur unbegründete, unbelegbare Behauptungen, Aufforderungen zu Beweisen (die die Gegenseite selbst nicht liefern kann) oder suggestive Fragen.

Danke für Deinen Input, denke damit habe ich es gefunden. chargeMaxLimit stand auf 0. Wenn ich das auf 1000 setze lädt er sogar 1000W von AC Plus PV-Eingang (aktuell sind das dann in Summe rund 1500W). Wenn ich das richtig interpretiere lasse ich chargeMaxLimit auf 1000 und steuere den tatsächlichen Wert (so wie der Überschuss verfügbar ist) über ...control.auto_in_out_Limit .

Richtig. Bei einer aktiven Regelung würde ich dir zudem unbedingt empfehlen, smartMode: 1 zu setzen.

Bei mir steht der Wert dauerhaft auf 1, damit die Batterien nicht ständig in den Standby gehen.
Zwar verbleiben sie dann ab und zu für einige Zeit im aktiven Zustand, aber das schadet dem System deutlich weniger, als wenn permanent neue Werte in den Flash-Speicher (NVS) geschrieben werden.

Ansonsten – wenn sie voll sind und es für mehrere Stunden nichts zu regeln gibt (z. B. im Modus pass: 2 / Bypass) – kannst du (wenn du möchtest) per Skript oder manuell smartMode: 0 setzen.
Das spart ein paar Wh, ist aber wirklich nur sinnvoll, wenn es sich um mehrere Stunden handelt.
Bitte nicht zu oft wechseln, denn sobald smartMode geändert wird, wird die Konfiguration sofort wieder in den NVS geschrieben.

(FW habe ich noch V1.0.2 - da bin ich mir immer noch unschlüssig ob ich auf V2.0.2 gehen soll).

Wenn aktuell alles zu deiner Zufriedenheit läuft, kannst du vorerst bei dieser Firmware bleiben.

Allerdings bringt die V2.0.2 einige Verbesserungen mit sich.
Die Firmware ist eigentlich gut – ich muss allerdings dazusagen, dass ich selbst keinen SolarFlow Pro 2 nutze und dein genaues Setup nicht kenne.

Meiner Meinung nach ist das Update auf V2.0.2 bedenkenlos.
Ich würde es vor allem dann empfehlen, wenn die aktuell installierte Version bereits bei V1.6.x oder höher liegt bei neuen Zendure-Geräten bis 2400AC plus/pro

Zur V1.0.2 fehlen mir die Vergleichswerte für eine Analyse – so weit möchte ich auch nicht mehr zurückgehen.
Alles ist mir jetzt schon zu viel Arbeit.
Versionen, die neuer als V2.0.2 sind, kann ich derzeit nicht beurteilen.

Zu bedenken gibt es nur, dass man später nicht auf V2.0.2 updaten kann, wenn schon eine neuere, höhere Version angeboten wird.
Aber wie gesagt, wenn dein System voll zu deiner Zufriedenheit läuft ...

Es bleibt deine Entscheidung ;-)

Weiter möchte ich mich zu Firmware-Versionen nicht äußern.

[MP_Trixi]

@maxclaudi
gut, habe Input/Output Limit Mode SmartMode RAM und Smart Mode Watcher auf true. SmartMode steht damit (aktuell) bei 1. FW Update läuft ;)

[maxclaudi]

@MP_Trixi und Alle:

Steuerungs-Script:
update 06.10.26 02:00h neu set batCalTime, fix acMode/auto_in_out_Limit

Beschreibung:
neu set batCalTime

[T-147]

Guten Morgen zusammen,

gestern Morgen mal das FW-Update auf 2.0.2 gemacht und das aktuelle Blockly aktiviert. SoC stand zu dem Zeitpunkt auf 10%. Das Blockly hat umgehend die Entladesperre aktiviert und erstmal bis ca 16% aufgeladen, bevor wieder entladen werden durfte.
Damit wäre eines meiner Probleme erledigt

Steuerung lief damit gestern auch super, bis die Batterie heute Nacht bei 24% aufgehört hat zu entladen, weil die Entladesperre gegriffen hat (laut Log). Ich verstehe nur noch nicht, warum so hoch? BatteryLockMinCellVoltage steht auf 3.2V.

Heute Morgen hab ich direkt das neue ZenSDK-Script eingebunden und aktiviert, am Blockly hab ich nichts mehr verändert.
Der SF800 Pro2 hat umgehend auf Entladen geschaltet und der minVol ist aktuell bei 3,14V und die Batterie entlädt fleißig weiter.
Kurz darauf ein kurzer Peak im Stromverbrauch, seitdem entlädt der SF800 Pro2 fleißig mit vollen 800W und ballert 600W davon ins Netz, ohne wieder zurückzuregeln.
Hab das Entladen jetzt manuell auf 200W runtergesetzt, das hat auch funktioniert. Kurz darauf hat die Entladesperre wieder gegriffen bei ca 15% und minVol 3,19V (hatte das eben wieder auf Ausgangswerte gestellt, war also korrekt so).
Zwischendurch hat der Javascript-Adapter noch folgende Warnungen ausgeworfen:

372:210 ist ein <next> im Blockly, das "AC1600plus" kann eignetlich nur ein Rest aus dem Original-Script sein, den ich übersehen und nicht geändert hab, finde aber ehrlich gesagt nichts mehr dazu.
Mit dem Rest kann ich erstmal nichts anfangen an Infos. Hab beide Scripte mal neu gestartet, danach kam keine Warnmeldung mehr im Log und die Entladesperre hat gegriffen.

Mir ist jetzt nur aufgefallen, dass die minVol bei mir im ioBroker mit einem Komma geschrieben wird und im Blockly mit einem Punkt als Trennzeichen. Das muss so sein oder kommt der damit evtl durcheinander?

Bin da grad ein wenig verwirrt, aber ich hoffe da kommt bald Licht ins Dunkel...

Achso, aktuell liegt minVol bei 3,2V und der SoC bei 15%, während das System ein wenig durch die Morgensonne geladen wird. Gestern lag der minVol bei 15% SoC bei 3,24V.
Woher kommen diese Unterschiede bei fast identischen Bedingungen gestern und heute?

Beste Grüße

[maxclaudi]

Nach (für mich vorläufigem) Abschluss bin ich dankbar, aber zugleich auch etwas enttäuscht.
Die Firmware V2.0.2 ist – um es untertrieben zu formulieren – gut.
Das Gute ist, dass in der V2.0.4 anscheinend einiges berücksichtigt wurde.
Schade ist hingegen, dass nun (V2.0.4) ein ungefährlicher, werkseitig vorhandener Zugang verwehrt zu sein scheint, der zumindest für Diagnosen, Logs, Debugging und Tests mit viel mehr Features gut gewesen wäre.
Es ist allerdings verständlich, da diese Schnittstellen für den Normalbetrieb nicht gedacht sind und wahrscheinlich nur dem Service oder der Diagnose dienen.

[maxclaudi]

@T-147
welches Blockly verwendest Du?
das hier Post #412?

Bitte wenn möglich, das nächte mal nicht als Bild. Besser:

javascript.0 2026-10-07 08:41:05.642 info script.js.Energieversorgung.Zendure.SF800_Pro_2_-_Nulleinspeisung_2026_09: Es gibt nichts zu tun, theoretisches positives newLimit: 250; oldLimit: 250
javascript.0 2026-10-07 08:40:45.263 info script.js.Energieversorgung.Zendure.SF800_Pro_2_-_Nulleinspeisung_2026_09: Es gibt nichts zu tun, theoretisches negatives newLimit: 0; oldLimit: 250
javascript.0 2026-10-07 08:40:45.262 warn at processImmediate (node:internal/timers:541:9)
javascript.0 2026-10-07 08:40:45.261 warn at runNextTicks (node:internal/process/task_queues:65:5)
javascript.0 2026-10-07 08:40:45.260 warn at Object.<anonymous> (script.js.Energieversorgung.Zendure.SF800_Pro_2_-_Nulleinspeisung_2026_09:372:210)
javascript.0 2026-10-07 08:40:45.252 warn getState "0_userdata.0.zendure.1600ACplus.properties.socSet" not found (3)
javascript.0 2026-10-07 08:40:35.335 info script.js.Energieversorgung.Zendure.SF800_Pro_2_-_Nulleinspeisung_2026_09: auto_In_out_Limit ist positiv oder 0: 250
javascript.0 2026-10-07 08:40:35.334 info script.js.Energieversorgung.Zendure.SF800_Pro_2_-_Nulleinspeisung_2026_09: newLimit positiv: 250 ist > oldLimit: 0 Es wird mehr entladen als zuvor.

properties.socSet Datenpunkt ist falsch und muss bei Dir auf Deinen properties sco.Set Datenpunkt gesetzt werden.
Entweder hier:

und/oder hier etwas weiter darunter:

[T-147]

@maxclaudi sagte:

@T-147
welches Blockly verwendest Du?
das hier Post #412?

Ja, genau das. Habs nur auf meinen SF800 Pro2 angepasst. Und natürlich meinen Zähler...

Bitte wenn möglich, das nächte mal nicht als Bild. Besser:

Sorry, ich vergess das immer wieder

properties.socSet ist einmal falsch. wahrscheinlich hier:

oder

VOLLTREFFER!
Ich danke Dir. Habs
bestimmt 20x überlesen...

Kann den "Fehler" mit der zu hohen Einspeisung von heute Morgen bisher leider nicht reproduzieren. Ist keiner Zuhause, der nen großen Verbraucher einschalten könnte. Ich berichte, sobald sich was in die Richtung tut.