Monatsrückblick Oktober 2026 ist online!

[maxclaudi]

zURLtool Zendure Smart Plug Pro
können auch mit zURLTool umgeschrieben und per MQTT gesteuert werden.
Persönlich mag ich die Smart Plug Pro nicht, u. a. wegen des schlechten WLAN-Empfangs und einiger Exemplare, die zu viele Fehlfunktionen haben.
Dazu kann man die Rezensionen und Kommentare auf Amazon und der Herstellerseite lesen.

zURLtool TLS
Wird damit der DNS auf eine andere DNS oder IP umgeschrieben, funktioniert die Zertifikatskette mit Keys.
Aktuell ist es so, dass dann die Zertifikatsgültigkeiten (Beginn 2020 / Ende 2030) nicht geprüft werden.
Tatsächlich ist und wäre das auch schwer realisierbar.
Zumindest meine Geräte haben sich auch mit gesetztem Datum von 1999 und 2041 verbunden.
Das Gerät im Auslieferungszustand „kann“ eine Zeit von 1970 haben.
Die Zeit wird per Cloud bzw. Broker und/oder HTTPS synchronisiert.
Das kann und wird auch erst nach erfolgter MQTT(S)-Verbindung über TLS und Registrierung der Geräte vorgenommen.
Setzt man einen Broker als Bridge ein, dann werden auch Geräte, die kein TLS unterstützen, über TLS verbunden.
Wie z. B. Hub2000, ace1500.

Garantie:

• Solange Variablen verändert werden, die im System für den Nutzer oder das System-Setup vorgesehen sind (z. B. Server-URLs, IDs, MQTT-Pfade), ist das rechtlich wie eine Konfiguration zu werten. Davon fängt kein Gerät an zu brennen!
• Rechtliche Nuance: Sollte ein Firmware-Mod jedoch Schutzmechanismen aushebeln (z. B. Ladeströme oder Temperaturlimits manipulieren), könnte im schlimmsten Fall die Betriebserlaubnis (CE-Konformität) erlöschen. Da es sich beim zURLtool aber ausschließlich um das Setzen von Serververbindungen (URLs/Broker) und IDs handelt, führt ein Ändern von dafür vorgesehenen Variablen zu keinem Brand – die Brandgefahr ist hier ein reines Schreckgespenst.
  Beim Umschreiben von Variablen verliert man keine gesetzliche Gewährleistung. Alles, was über Gesetze hinausgeht, sind freiwillige Leistungen des Herstellers; diese können, müssen aber nicht gewährt werden.

Lokale API ein- und ausschaltbar
Mit Cloud-Ersatz-Broker (lokaler Broker statt Cloud) kann localAPIenable aus- und eingeschaltet werden.
Wenn es ausgeschaltet ist, ist der ESP zusätzlich entlastet und ein Steuern über zenSDK ist nicht möglich.
Erfolgreiche Umsetzung nach Firmware-Analyse (erste öffentliche Dokumentation): Für die Aktivierung von 'localAPIenable' ist kein vorheriges Ein-/Ausschalten von HEMS in der App erforderlich; der Vorgang lässt sich alternativ via MQTT nicht nur Einschalten sondern nach Belieben ein- und ausschalten.

localAPIEnable eingeschaltet:

localAPIEnable ausgeschaltet:

localAPIEnable wieder eingeschaltet:

---

Cloudless:

• Zeitsynchronisation über MQTT möglich. Über NTP und zusätzliches Skript.
  Entweder reales oder auch berechnetes, willkürliches Datum und Zeit.
  Ist aber aufgrund von zURLTool nicht nötig, weil die Zertifikatsgültigkeit dann nicht geprüft wird.

• Inbetriebnahme eines neuen Geräts.
  Es ist jederzeit möglich, mittels zURLTool ein Gerät sofort, lokal ohne Account und ohne App in Betrieb zu nehmen und zu steuern.
  Sowohl über MQTT-Broker als auch per zenSDK. Für zenSDK muss die lokale API aktiviert sein / werden.

Reset:
Es ist möglich, ein Zendure-Gerät über MQTT oder BT auf den Auslieferungszustand zurückzusetzen.
Diese Option wird im Update von zURLtool 2.0 dch implementiert sein.
Achtung: Wenn ein Reset zum Verkauf des Geräts ausgeführt werden soll und/oder man es nicht mehr in der Cloud auf sich registriert haben möchte, muss das Gerät zusätzlich in der App entfernt werden!

Das bisherige setzen des WIFI MODE wie in Version 1.0 ist nicht mehr nötig.
Das WiFi wird gescannt und bei Auswahl des WiFi wird beim übernehmen automatisch der richtige Mode gesetzt.

Token:
Bisherige BT-Tools haben Fehler und verwend(et)en einen nicht richtigen Token.
Der erfundene Token wird nur bei einigen „älteren“ Geräten – ohne Probleme – akzeptiert.
Richtig und empfehlenswert ist er nicht.
Aus verständlichen Gründen kann und werde ich nicht weiter darauf eingehen.

userId
wird bei Account-Erstellung von der Cloud erstellt und zugewiesen. Berechnet wird sie weder von der App noch durch die Firmware.
Sie wird einmalig gesetzt und danach nur ausgelesen und verwendet. Ebenso die consumerId, die nach "bisherigen" Analysen identisch mit der userId ist.

Wird ein Gerät lokal oder mit Cloud-Verbindung in Betrieb genommen, ohne dass ein Account generiert wurde oder die ID fehlerhaft ist, dann wird eine Universal-ID als Fallback akzeptiert.
Für lokalen Betrieb ausreichend.
Bei vorhandenem Cloud- und App-Account mit Benutzername und Passwort und evtl. gleichzeitigem Betrieb mit Cloud ist es besser, die richtige, zugewiesene userId bei allen vorhandenen Geräten zu verwenden.

Die userId kann nur über HTTP(S) gezielt, direkt und sofort abgerufen werden.
zURLtool nutzt beim Schreiben eine gültige Universal-Fallback-userId.
Das ist ausreichend. Aber m. M. n. sinnvoll und besser ist es, die explizit zugewiesene userId zu verwenden, um dem Original vollständig zu entsprechen.

Dazu habe ich ein neues Tool geschrieben: zAppEmulationDeviceInfo
Dabei gibt man in der GUI von der App die Zugangsdaten ein oder in:
deviceInfoConfig.ini

; zAppEmulationDeviceInfo
; example:
; 
; [ACCOUNT]
; EMAIL = user123@gmail.com
; PASSWORD = tOpS3kRet17090811Bc74
;
[ACCOUNT]
EMAIL = user123@gmail.com
PASSWORD = tOpS3kRet17090811Bc74

zAppEmulationDeviceInfo emuliert die App und führt einen Request aus.
Die Antwort steht dann im Textfeld und speichert die wichtigsten Daten in der Datei: Device-List.txt

Es handelt sich hierbei NICHT um die Standard-Device-List. Es sind viel mehr Daten vorhanden, die für die App vorgesehen sind.

HINWEIS: zAppEmulationDeviceInfo verbindet sich über HTTP(S) mit der Cloud, wie die eigentliche App, und ruft nur einmalig die erforderlichen Daten ab.
Mehr nicht.
Es kann und soll gerne ein Virenscan erfolgen!
Wenn man dem Tool wegen der Zugangsdaten nicht vertraut, kann man auch temporär sein Account-Passwort dafür ändern.

zAppEmulationDeviceInfo benötigt eine Seriennummer und einen Activationcode.
Wer bereits zURLtool verwendet, kann die Seriennummer und den Freischaltcode von zURLtool verwenden.
Bzw. zAppEmulationDeviceInfo kann direkt ausgeführt werden, wenn zURLtool schon verwendet wird.
Man kann User-E-Mail und Passwort händisch in der GUI eingeben oder vorbelegen in der Datei: deviceInfoConfig.ini

; zAppEmulationDeviceInfo
; example:
; 
; [ACCOUNT]
; EMAIL = userAccount@gmail.com
; PASSWORD = tOpS3kRet17090811Bc74
;
[ACCOUNT]
EMAIL = userAccount@gmail.com
PASSWORD = tOpS3kRet17090811Bc74

Wenn die consumerId ausgelesen wurde und man seine Geräte auf seine originale, von der Cloud zugewiesene userID setzen möchte, dann kann die bisherige zURLtool-Version das bereits.
zURLtool wurde schon dafür vorbereitet.
In der Datei: config.ini

; config.ini zURLtool (c) maxclaudi 2026
; Für WiFi SSID und PASSWORD bitte keine Leerzeichen, Umlaute etc. verwenden
; Broker: Bitte nur reine IP oder DNS eingeben. Kein ":" und kein Port.
; Der Port ist in der Firmware fest hinterlegt. Entweder Port:1883 ohne TLS oder Port 8883 mit TLS.
; TLS-Verbindungen können nur mit gültigen Zertif. / Keys verwendet werden.
; 
; MODE = WLAN-Sicherheitsmodus
; 3 = WPA2-PSK (Standard)
; 4 = WPA/WPA2-PSK
; 5 = WPA2-Enterprise
; 6 = WPA3-PSK
; 7 = WPA2/WPA3-PSK
; Gültige Werte: 3-7; bei fehlendem/ungültigem Wert wird automatisch 3 verwendet.
; MODE = 3
;
; Zurück zur Cloud:
; BROKER = mq.zen-iot.com
;
; Beispiele: 
; [WIFI]
; SSID = meinWLAN
; PASSWORD = tOpS3kRet17090811Bc74
; MODE = 3
; 
; [MQTT]
; BROKER = 192.168.12.200
; MODE = 3
;
[WIFI]
SSID = meinWLAN
PASSWORD = tOpS3kRet17090811Bc74
MODE = 3
EXTRA = <userID>

[MQTT]
BROKER = 192.168.12.200
;BROKER = mq.zen-iot.com

Statt "<userId>" die tatsächlich abgefragte userId einfügen.
Beispiel:

EXTRA = 43521

Wenn consumerId in EXTRA angeben wird, überträgt das zURLtool genau diese Nummer als lokale userId auf das Gerät.
Dadurch wird sichergestellt, dass die lokale Broker-Konfiguration exakt mit der Identität übereinstimmt, die von in der Cloud registrierten Geräten erwartet wird; auf diese Weise werden jegliche internen Diskrepanzen bei der Autorisierung auf Chip-Ebene vollständig beseitigt.
Wird das zURLtool ohne das Feld EXTRA verwendet, kommt eine gültige, generische Fallback-userId zum Einsatz.
Dies funktioniert wie vorgesehen, da sie als universelle userId akzeptiert wird.
Sie stimmt jedoch nicht mit der spezifischen userId überein, die von der Cloud für den jeweiligen Benutzer generiert wurde.

Auch wenn die universelle Fallback-userId funktioniert, ist es meiner Meinung nach sinnvoller, die von der Cloud zugewiesene userId zu verwenden.
Die Cloud-basierte userId wird üblicherweise erst bei der Einrichtung eines Kontos erstellt.

Der Fallback-Mechanismus ist für die Verbindung zur Cloud gedacht, wenn das Gerät vollständig offline betrieben wird oder die userId ungültig ist.
Da das zURLtool nur vorhandene, bekannte oder vordefinierte Werte setzen kann – und während der Einrichtung weder über eine HTTP(S)-Verbindung verfügt noch weiß, ob ein Konto existiert –, wird standardmäßig die universelle Fallback-userId verwendet, wenn das Feld EXTRA weggelassen wird oder einen ungültigen Wert enthält.

---

Download zAppEmulationDeviceInfo in 3 Teilen:
zAppEmulationDeviceInfo.zip
zAppEmulationDeviceInfo.z01
zAppEmulationDeviceInfo.z02

[maxclaudi]

Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 1:

zAppEmulationDeviceInfo.zip

Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.zip hat, benenne sie bitte entsprechend um.

[maxclaudi]

Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 2:

zAppEmulationDeviceInfo.z01

Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.z01 hat, benenne sie bitte entsprechend um.

[maxclaudi]

Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 3:

zAppEmulationDeviceInfo.z02

Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.z02 hat, benenne sie bitte entsprechend um.

[maxclaudi]

@Daniel-8 sagte:
Habe dann mal den setsocComp auf 1 und 2 geschrieben. Konnte aber keinerlei Veränderung feststellen

Bisherige Analyse von socCompSwitch und Überraschung:

Der HEMS-Code wurde dabei ausdrücklich nicht als Verbraucher des separat gesetzten socCompSwitch gewertet!

Für dieses konkrete Firmware-BIN aktiviert socCompSwitch keine im analysierten ESP32-Code nachweisbare Funktion.

Damit gilt für die analysierte aktuelle module-MASTER/ESP32-Firmware: V2.0.59 (in der App ausgewiesen u. a. als V2.0.2):

SocCompSwitch unter properties ist in dieser Firmware bereits als schreibbare Option vorhanden und kann gesetzt werden.
0 ist der Standardwert.

Für `SocCompSwitch unter properties konnte im analysierten ESP32-BIN jedoch noch keine funktionale Auswertung und damit keine nachweisbare Wirkung gefunden werden.

Die Option ist somit in der aktuellen Firmware bereits vorbereitet, hat nach dem derzeitigen Analyseergebnis aber noch keine erkennbare Funktion.

Ob SocCompSwitch in einer zukünftigen Firmware tatsächlich eine Funktion erhält, zunächst ohne Wirkung bleibt oder später wieder entfernt bzw. geändert wird, lässt sich aus der aktuellen Firmware nicht ableiten.

---

Edit 30.09.2026
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.

[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 ;)