wichtiges UPDATE für controller 7.2.2 im stable

[Rico Sander]

@maxclaudi sagte:

Falls Du (oder jemand anderes) Lust hast, den Code auf axios umzubauen, zu optimieren oder ( auch z.B. @Rico-Sander ) die Dokumentation zu erweitern – fühlt euch herzlich eingeladen!

Ich komme aus der Ecke perl und php. Zu JS wurde ich erst durch ioB, richtig aber erst durch die Scripte für Zendure "gezwungen"
Ich entdecke zwar täglich in JS, dass ich vieles aus meiner frühen Zeit noch anwenden kann, aber zu mehr reicht es leider nicht.

Was die Hilfe zur Dokumentation angeht:
Mit @apollon77 hatte ich angefangen, die Doku zu ioB zu aktualisieren/verbessern, was aber wohl nur (hoffe ich) aus Zeitgründen im Sande verlaufen ist.
Die Doku zu Deinem Script ist doch schon ok.

Vorschlag:
Unter den Absatz:

Es funktioniert sofort und wahlweise komplett lokal oder parallel zu Cloud und App (bei deaktiviertem HEMS).
Außer der IP-Adresse des Zendure-Geräts sind keine weiteren Keys oder Authentifizierungen notwendig.

Folgende Ergänzung:

Hinweis: Aus technischen Gründen sollte sowohl dem Gerät (den Geräten?) als auch der App weiterhin der Zugang ins Internet möglich sein.

Diese Ergänzung in der Doku reicht m.E aus. Eine tiefere Begründung und techn. Hintergründe sind an der Stelle aus meiner Sicht nicht nötig.
Es sei denn, die Dokum sollte mehr als nur eine Vorstellung des Scriptes und eine Kurzanleitung sein.

[paul53]

@Rico-Sander [sagte]: In der App:

Unter Firmware-Update steht nur "Die Firmware Ihres Gerätes ist auf dem neuesten Stand".

[maxclaudi]

@Rico-Sander sagte:

Vorschlag:

Folgende Ergänzung:

Hinweis: Aus technischen Gründen sollte sowohl dem Gerät (den Geräten?) als auch der App weiterhin der Zugang ins Internet möglich sein.

Danke. Wurde in die Anleitung aufgenommen.
Allerdings liest es sich für mich jetzt so, als würde die Cloud dazwischen funken.
Die Steuerung ist ausschließlich lokal und funktioniert auch nur wenn HEMS ausgeschaltet ist.
Die meisten werden es wissen und sonst fragen :-)
Jetzt mal abwarten was HEMS 2 alles neu oder durcheinander bringen wird.
Update mache ich (noch) nicht.

[Rico Sander]

@maxclaudi sagte:

Allerdings liest es sich für mich jetzt so, als würde die Cloud dazwischen funken.
Die Steuerung ist ausschließlich lokal und funktioniert auch nur wenn HEMS ausgeschaltet ist.
Die meisten werden es wissen und sonst fragen :-)

Nunja, Du kannst ja meinen Vorschlag noch individualisieren. So, dass er in den Lesefluss passt und ggfl. Irritationen vermeidet. Ich meine, zumindest die lokale Funktion hattest Du ja schon beschrieben., Der Hinweis zu HEMS ist sicher richtig und sinnvoll.

Alles wird gut

[maxclaudi]

Punkt 3 beachten:

[maxclaudi]

@paul53
bisher ohne Update steht bei mir im Datenpunkt version:2

Vermutlich steht bei Dir dort nun 3?

[paul53]

@maxclaudi [sagte]: Vermutlich steht bei Dir dort nun 3?

Richtig.

@maxclaudi sagte:

socLimit: 17 wird wahrscheinlich kein Bug, sondern ein neues Bitmuster sein.
(z. B. 16 + 1 )

Stimmt: Bei SoC unter 85 % ist "socLimit" = 16.

[maxclaudi]

@paul53 sagte:
Stimmt: Bei SoC unter 85 % ist "socLimit" = 16.

Dann war Deine Ladegrenze vermutlich bei socSet = 85 %
Es fehlt jetzt noch ein Wert für „minSoc erreicht“.
Falls die Vermutung mit den neuen Bitmustern stimmt, könnte das z. B. 18 oder 19 sein. Das ist aber aktuell nur eine Vermutung.

Falls Du minSoc einmal auf 50 % stellst und die Batterien bis zur Entladegrenze laufen lässt, wäre der gemeldete socLimit-Wert interessant.

Edit / PS:
Wurde unter properties zusätzlich ein neuer Key socCompSwitch angelegt?

Falls ja, bitte die beobachteten Werte und möglichst auch die jeweilige Situation (SOC, Laden, Entladen, Bypass usw.) mitteilen. Danke.

[paul53]

@maxclaudi [sagte]: Falls Du minSoc einmal auf 50 % stellst und die Batterien bis zur Entladegrenze laufen lässt, wäre der gemeldete socLimit-Wert interessant.

Wenn die Grenze erreicht ist, schaltet die Notstromdose ab und ioBroker läuft dann nicht mehr.

[maxclaudi]

Mal ein Aufruf an die vielen stillen Mitleser hier im Thread:

Es wäre super, wenn jemand aus der Community mithelfen könnte, der die neue Firmware nutzt.
Wer ioBroker nicht an der Notstrom-Steckdose betreibt, könnte minSoc ja mal auf 50% setzen und die Batterien testweise mal bis zur Entladegrenze laufen lassen.
Bei erreichen von minSoc: Welcher Wert wird bei euch dann aktuell unter socLimit gemeldet?
Es müssten theoretisch Werte wie 18 oder 19 sein.

Und eine zweite Frage in die Runde:
Wurde bei euch unter properties zusätzlich ein neuer Key namens socCompSwitch angelegt?

Falls ja, wären die beobachteten Werte und die jeweilige Situation (Laden, Entladen, Bypass) hilfreich.
Im Moment würde mir auch schon der aktuelle Wert helfen.

Ich freue mich über jede kurze Rückmeldung und Mithilfe aus der Runde.

[paul53]

@maxclaudi [sagte]: ein neuer Key namens socCompSwitch angelegt?

Ja. Der Wert ist aktuell 0 beim Laden und Entladen (nur Notstrom).

[maxclaudi]

socLimit

00010000 = 16
00010001 = 17
00010010 = 18

Bisher wurde gemeldet:

16 = Normalbetrieb
17 = Ladegrenze erreicht (socSet erreicht)

Es sieht so aus, als wäre bei API3 einfach ein zusätzliches Bit 4 gesetzt worden:

alt 0 -> neu 16
alt 1 -> neu 17
alt 2 -> neu 18

also:
neu = alt + 16

Falls die Vermutung stimmt, müsste bei erreichter unterer Ladegrenze (minSoc erreicht) nun socLimit:18 gesetzt werden.

Kann das bitte jemand bestätigen?

[paul53]

@maxclaudi [sagte]: bei API3 einfach ein zusätzliches Bit 4 gesetzt

Es wäre schön, wenn Zendure die Bedeutung dieses Bits mitteilen würde. Wenn es in neueren API-Versionen immer gesetzt ist, könnte man es auch maskieren.

[paul53]

@maxclaudi [sagte]: Code auf axios umzubauen

Nachdem ich heute um 17:07 Uhr wieder einen Timeout-Error aus httpGet() erhalten habe, der im nächsten Intervall-Zyklus wieder erledigt war, habe ich mal auf axios umgebaut.

const axios = require('axios');
 
function startGetLoop() {
    if (getTimer) { clearInterval(getTimer); }
    getTimer = setInterval(() => {
        if (postActive) return;
        const url = `http://${IP}/properties/report`;
        axios
        .get(url, {timeout: getTimeoutMs, responseType: 'text' })
        .then(function (response) {
            if (getErrorCount > 0) log("Verbindung wieder OK", "info");
            getErrorCount = 0;
            if (!response.data) return;
            setRxNew(response.data);
            handleRxNewUpdate(response.data);
        })
        .catch(function (err) {
            if (err) {
                getErrorCount++;
                if (getErrorCount <= 3) log(`GET Fehler (${getErrorCount}): ${err}`, "info");
                if (getErrorCount === 4) log("Keine Verbindung möglich. Zendure-Geräte IP prüfen!", "error");
            //    return;
            }
        });
    }, getIntervalMs);
}

Es scheint zu funktionieren.

javascript.0
2026-06-19 22:37:23.641	info	script.js.common.Solarflow: Verbindung wieder OK
javascript.0
2026-06-19 22:37:20.606	info	script.js.common.Solarflow: GET Fehler (1): AxiosError: timeout of 2000ms exceeded

[maxclaudi]

@paul53 sagte:
Es wäre schön, wenn Zendure die Bedeutung dieses Bits mitteilen würde.

Zendure ist bzw. war in der Vergangenheit sehr sparsam mit Informationen.
Oft ist die spärliche API-Dokumentation teilweise unvollständig oder nicht richtig.

@paul53 sagte:
Wenn es in neueren API-Versionen immer gesetzt ist, könnte man es auch maskieren.

Darum frage ich ja.
Diesen Schritt würde ich erst gehen, wenn die Dokumentation – wenn auch nur spärlich – überhaupt auf API 3 aktualisiert wird oder genügend eigene Untersuchungen dies bestätigen.

@paul53 sagte:
Wenn die Grenze erreicht ist, schaltet die Notstromdose ab und ioBroker läuft dann nicht mehr.

Mich würde interessieren, unter welchen Bedingungen das beobachtet wurde.

Für mich ist aktuell noch unklar, wie sich die Grid-Off-Steckdose verhält, wenn bei Erreichen von MinSoC gleichzeitig

• ausreichend PV-Leistung vorhanden ist,
• das Gerät mit dem Netz verbunden ist,
• oder AC-Laden aktiviert ist.

Dazu habe ich bislang leider keine eindeutige Aussage/Information von Zendure gefunden.

Aus den verfügbaren Informationen geht lediglich hervor, dass die Off-Grid-Steckdose ein eigenständiger EPS-/Notstrom-Ausgang ist, der primär aus der Batterie versorgt wird.
Der SF800 Pro kann gleichzeitig netzparallel arbeiten und die Off-Grid-Steckdose versorgen.

Zendure Zitat:

Kann der SolarFlow 800 Pro 2 sowohl im netzgekoppelten als auch im netzunabhängigen Modus gleichzeitig arbeiten?
Ja, es unterstützt die gleichzeitige Nutzung der Off-Grid- und Netzeinspeisungsfunktion, wobei die Gesamtleistung 1000 W nicht überschreiten darf.
Bei alleiniger Nutzung der Off-Grid-Funktion beträgt die maximale Entladeleistung der Off-Grid-AC-Schnittstelle 1000 W.
Quelle: Zendure SolarFlow 800 Pro 2, FAQ

Was ich bisher nicht finden konnte, ist eine Aussage dazu,

• ob die Grid-Off-Steckdose bei Erreichen von MinSoC grundsätzlich abgeschaltet wird,
• ob sie bei ausreichender PV-Leistung weiter betrieben werden kann,
• oder ob ein vorhandener Netzanschluss dabei eine Rolle spielt.

Zendure liefert auch hier wieder nur spärliche Infos.

Viele Details lassen sich daher oft erst durch praktische Erfahrungen und eigene Tests herausfinden. Das war auch bei einigen Fragestellungen in der Vergangenheit so, bei denen ich selbst Messungen und Versuche durchgeführt habe, um das tatsächliche Verhalten der Geräte besser zu verstehen.

Daher die Frage an alle:

Hat das jemand bereits gezielt getestet?

Beispielsweise bei einem SF800 Pro / SF800 Pro 2 mit:

• aktivem Netzanschluss,
• Dauerlast an der Grid-Off-Steckdose,
• MinSoC z. B. 50 %.

Was passiert genau, wenn die 50 % erreicht werden und gleichzeitig noch genügend PV-Leistung vorhanden ist?

• Schaltet die Grid-Off-Steckdose sofort ab?
• Wird lediglich die Batterie geschont und die Last direkt aus PV versorgt?
• Oder verhält sich das System noch anders?