Monatsrückblick Oktober 2026 ist online!

[maxclaudi]

@T-147 sagte:

@maxclaudi

Alles gut, mach dir keinen Stress. Werd am WE eh nicht viel Zeit dafür haben. Hab im Blockly den Bereich mit den Großverbrauchern jetzt erstmal deaktiviert.

ZenSDK-Script grad neu geladen und vor dem Starten den Datenpunkt ...control.acMode gelöscht.
Ich teste weiter.

ok, Bitte habe Nachsicht mit mir, dass ich nicht die Zeit finde, das alles in Blockly zusammenzuklicken.

Ich habe das Ganze nun – auf die Schnelle – in reinem JavaScript umgesetzt. Das ist für mich wesentlich einfacher zu lesen, und eventuelle Fehler sind schneller zu finden und zu beheben.

Ich habe das JS extra für Einsteiger geschrieben und sehr einfach gehalten, damit es leicht nachvollziehbar ist.

Oben im Skript muss nur noch die Konfiguration eingetragen werden, ohne dass man (wie im Blockly) mühsam unzählige Datenpunkte manuell anpassen muss.

Bitte einfach mal testen.
Ich denke, es ist ausreichend kommentiert...

Das Skript ist bei mir nur kurzfristig auf Lauffähigkeit getestet, sollte aber einwandfrei funktionieren.

// ZENDURE einfache NULLEINSPEISUNG - ioBroker JavaScript-Adapter
// Wahlweise 1 bis 6 Batterien. Keine Schleifen, einfach zu lesen für Einsteiger
// Für alle Geräte ab 2025/2026, die zenSDK unterstützen, wie z. B.:
// SF800, SF800 PLUS, 800Pro (2), 1600AC, SF2400AC(+) usw.
// (c) maxclaudi 09.10.2026_18:00h für das ioBroker-Forum
//
// EIN WORT IN EIGENER SACHE:.
// In der Vergangenheit wurden meine Erkenntnisse oft ohne Erwähnung in andere Projekte übernommen.
// Ich teile diesen Code gerne. 
// Wer diese(n) Code/Logik in öffentliche Adapter integriert oder anderweitig - auch Auszugsweise verwenden möchte, ist herzlich 
// eingeladen – ich bitte jedoch um die Fairness, die Quelle zu nennen. 
// Das ist der "Lohn" für meine Zeit und Forschung.
// ======================================================================================

// 1. KONFIGURATION: HIER PFADE UND DATENPUNKTE und Anzahl der Batterien ANPASSEN


// Trigger-Datenpunkt (Stromzähler / Smart Meter, Netzbezug in Watt)
const DP_GRID_METER_TRIGGER = '0_userdata.0.Datenpunkte.zendureSolarFlow.user.ZaehlerTrigger_easy_shelly';

// Haupt-Verzeichnis des Zendure-Datenpunkte-Scripts (muss identisch sein)
const folderZendureApi = '0_userdata.0.zendure.' + "2400ACproZENsdk";

// Wie viele Batterien hast du? Mögliche Werte: 1, 2, 3, 4, 5 oder 6
const vorhandeneBatAnz = 2;

// Seriennummern der Batterien.
// Nur die Seriennummer eintragen (ohne ".minVol"), nicht benötigte Zeilen einfach so lassen.
const akku1sn = "Cxxxxxxxxxxxxx1"; // z.B.: const akku1sn = "JO2AEP1P0605193";
const akku2sn = "Cxxxxxxxxxxxxx2";
const akku3sn = "Cxxxxxxxxxxxxx3";
const akku4sn = "Cxxxxxxxxxxxxx4";
const akku5sn = "Cxxxxxxxxxxxxx5";
const akku6sn = "Cxxxxxxxxxxxxx6";


// 2. REGEL-PARAMETER (die Standardwerte müssten für die meisten Zendure-Geräte passen)
//---------------------------------------------------------------------------------------
let intervalSec_outputLimit = 15; // Entladen frühestens nach X Sekunden. Standard: 15 s
let intervalSec_inputLimit  = 20; // Laden frühestens nach X Sekunden. Standard: 20 s
let chargingStep            = 50; // Schritte AC-Laden (z.B. 50 W, 100 W). Standard: 50 W
let dischargeStep           = 10; // Schritte Entladen, wird aufgerundet. Standard: 10 W
let wattChangeThreshold     = 30; // Hysterese: Änderungen erst ab X Watt Abweichung. Standard: 30 W
let safetyReserve           = 20; // Sicherheitsreserve gegen Netzbezug beim Laden. Standard: 20 W

let criticalGridPower        = 600;  // Ab wie viel Watt Netzbezug gilt es als hoher Leistungsabruf. Standard: 600 W
let criticalOutputLimit      = 1600; // Maximale Entladeleistung im Critical-Mode (nicht größer als dein Gerät: 800, 1000, 2400 W)
let intervalSec_criticalMode = 45;   // So lange wird die Spitze gehalten (taktende Großverbraucher: Herd, Klima, Durchlauferhitzer)

let intervalSec_change_acModeAllowed = 45; // Relais-Schutz: Sperrzeit nach einem Moduswechsel in Sekunden, bitte nicht zu kurz

let batteryLockMinCellVoltage   = 3.17; // Entladesperre bei dieser Zellspannung: 3.16 bis 3.20 V
let batteryUnlockMinCellVoltage = 3.25; // Freigabe nach der Sperre ab dieser Zellspannung. Standard: 3.25 V
let batteryRecoveryTimeSec      = 300;  // Beruhigungszeit der Zellen in Sekunden. Standard: 300 s (5 min)



//---------------------------------------------------------------------------------------
// AB HIER NICHTS VERÄNDERN!
//---------------------------------------------------------------------------------------

// Anzahl Batterien absichern (nur 1 bis 6 erlaubt)
let batAnz = Math.round(vorhandeneBatAnz);
if (!(batAnz >= 1)) batAnz = 1;
if (batAnz > 6) batAnz = 6;

// Basis-Pfade zu den Zendure-Eigenschaften
const BASE_PATH_PROPERTIES = folderZendureApi + '.properties.';
const BASE_PATH_CONTROL    = folderZendureApi + '.control.';
const BASE_PATH_PACKDATA   = folderZendureApi + '.packData.';

// Zellspannungs-Datenpunkt einer Batterie zusammensetzen
// (ein versehentlich mit eingetragenes ".minVol" wird automatisch entfernt)
function packDp(sn) {
    return BASE_PATH_PACKDATA + String(sn).replace('.minVol', '') + '.minVol';
}

const DP_MIN_VOL_PACK1 = packDp(akku1sn);
const DP_MIN_VOL_PACK2 = packDp(akku2sn);
const DP_MIN_VOL_PACK3 = packDp(akku3sn);
const DP_MIN_VOL_PACK4 = packDp(akku4sn);
const DP_MIN_VOL_PACK5 = packDp(akku5sn);
const DP_MIN_VOL_PACK6 = packDp(akku6sn);

// Spezifische Datenpunkte (automatisch zusammengesetzt)
const DP_AUTO_IN_OUT_LIMIT = BASE_PATH_CONTROL + 'auto_in_out_Limit';
const DP_SMART_MODE        = BASE_PATH_CONTROL + 'smartMode';

const DP_INVERSE_MAX_POWER = BASE_PATH_PROPERTIES + 'inverseMaxPower';
const DP_CHARGE_MAX_LIMIT  = BASE_PATH_PROPERTIES + 'chargeMaxLimit';
const DP_GRID_INPUT_POWER  = BASE_PATH_PROPERTIES + 'gridInputPower';
const DP_OUTPUT_HOME_POWER = BASE_PATH_PROPERTIES + 'outputHomePower';
const DP_INPUT_LIMIT       = BASE_PATH_PROPERTIES + 'inputLimit';
const DP_OUTPUT_LIMIT      = BASE_PATH_PROPERTIES + 'outputLimit';
const DP_AC_MODE           = BASE_PATH_PROPERTIES + 'acMode';
const DP_PASS              = BASE_PATH_PROPERTIES + 'pass';
const DP_SOC_LIMIT         = BASE_PATH_PROPERTIES + 'socLimit';
const DP_PACK_STATE        = BASE_PATH_PROPERTIES + 'packState';
const DP_ELECTRIC_LEVEL    = BASE_PATH_PROPERTIES + 'electricLevel';
const DP_MIN_SOC           = BASE_PATH_PROPERTIES + 'minSoc';
const DP_SOC_SET           = BASE_PATH_PROPERTIES + 'socSet';

// Merker-Variablen
let dplAktiv = true;
let lastSec_outputLimit_auto_in_out_Limit = 0;
let lastSec_inputLimit_auto_in_out_Limit = 0;
let lastSec_criticalMode = 0;
let lastSec_change_acModeAllowed = 0;
let batteryRecoveryStartSec = 0;

let batteryLock = false;
let batteryRecoveryPending = 0;

// aktuelle Sekunden
function getNowSec() {
    return Math.floor(Date.now() / 1000);
}

// sicherer getState mit Fallback, verhindert Abstürze bei fehlenden Datenpunkten
function getSafeVal(dpId, fallback) {
    if (fallback === undefined) fallback = 0;
    let state = getState(dpId);
    if (state && state.val !== undefined && state.val !== null) {
        return state.val;
    }
    return fallback;
}

// konfiguration prüfen und ggf. auf Standardwerte zurücksetzen
if (chargingStep < 10 || chargingStep > 100) chargingStep = 50;
if (dischargeStep < 10 || dischargeStep > 60) dischargeStep = 10;
if (wattChangeThreshold < 6 || wattChangeThreshold > 60) wattChangeThreshold = 30;
if (safetyReserve < 0 || safetyReserve > 60) safetyReserve = 20;

// Hardware-Maxima aus den Geräte-Eigenschaften lesen (mit Absturzsicherung)
let maxHardwareOutput = getSafeVal(DP_INVERSE_MAX_POWER, 800);
let maxHardwareCharge = getSafeVal(DP_CHARGE_MAX_LIMIT, 800);

let max_outputLimit = maxHardwareOutput;
let max_inputLimit  = maxHardwareCharge;
if (criticalOutputLimit > maxHardwareOutput) criticalOutputLimit = maxHardwareOutput;

if (batteryLockMinCellVoltage < 3.0 || batteryLockMinCellVoltage > 3.4 || batteryLockMinCellVoltage >= batteryUnlockMinCellVoltage) {
    batteryLockMinCellVoltage = 3.16;
}
if (batteryUnlockMinCellVoltage < 3.2 || batteryUnlockMinCellVoltage > 3.4 || batteryUnlockMinCellVoltage <= batteryLockMinCellVoltage) {
    batteryUnlockMinCellVoltage = 3.25;
}
if (batteryRecoveryTimeSec < 60 || batteryRecoveryTimeSec > 1800) batteryRecoveryTimeSec = 300;

console.info('Nulleinspeisung gestartet. Batterien: ' + batAnz);

// RELAIS-SCHUTZ: Zeitpunkt des letzten Moduswechsels (Laden <-> Entladen) merken
on({ id: DP_AC_MODE, change: 'ne' }, function () {
    lastSec_change_acModeAllowed = getNowSec();
});

// MAIN TRIGGER: reagiert auf den Stromzähler
on({ id: DP_GRID_METER_TRIGGER, change: 'ne' }, function (obj) {
    let gridMeterValue = Math.ceil(obj.state.val || 0);
    let nowSec = getNowSec();

    // 1. ZELLSPANNUNGEN UND GERÄTE-WERTE AUSLESEN
    // Es wird die niedrigste Zellspannung aller vorhandenen Batterien verwendet.
    let minCell = getSafeVal(DP_MIN_VOL_PACK1, 3.3);
    if (batAnz >= 2) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK2, 3.3));
    if (batAnz >= 3) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK3, 3.3));
    if (batAnz >= 4) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK4, 3.3));
    if (batAnz >= 5) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK5, 3.3));
    if (batAnz >= 6) minCell = Math.min(minCell, getSafeVal(DP_MIN_VOL_PACK6, 3.3));

    let socLimitState = getSafeVal(DP_SOC_LIMIT, 0);
    let packState     = getSafeVal(DP_PACK_STATE, 0);
    let currentSoc    = getSafeVal(DP_ELECTRIC_LEVEL, 0);
    let minSocLimit   = getSafeVal(DP_MIN_SOC, 10);
    let maxSocLimit   = getSafeVal(DP_SOC_SET, 100);

    // 2. BATTERIE-ENTLADESCHUTZ
    if (socLimitState === 2 || (minCell <= batteryLockMinCellVoltage && packState !== 1)) {
        if (!batteryLock) {
            batteryLock = true;
            console.info('Zellschutz AKTIVIERT. Mindestspannung unterschritten oder SoC-Limit erreicht.');
        }
    }

    // Freigabe nach der Sperre (erst nach Beruhigungszeit)
    if (minCell >= batteryUnlockMinCellVoltage && batteryLock && batteryRecoveryPending === 0 && socLimitState !== 2) {
        batteryRecoveryPending = 1;
        batteryRecoveryStartSec = nowSec;
    }

    if (batteryRecoveryPending === 1 && socLimitState !== 2 && (nowSec - batteryRecoveryStartSec >= batteryRecoveryTimeSec)) {
        if (minCell < batteryUnlockMinCellVoltage) {
            batteryRecoveryPending = 0; // Zellen wieder eingebrochen, Abbruch
        } else {
            batteryLock = false;
            batteryRecoveryPending = 0;
            console.info('Zellschutz ERFOLGREICH DEAKTIVIERT. Batterien wieder stabil.');
        }
    }

    // true = Entladen ist gesperrt
    let protectionActive = (batteryLock || socLimitState === 2);

	// 3. aktuellen Hausverbrauch (ohne Bat) berechnen
    // positiv = Verbrauch / Netzbezug, negativ = Überschuss
    let netPowerWithoutBattery = (gridMeterValue - getSafeVal(DP_GRID_INPUT_POWER)) + getSafeVal(DP_OUTPUT_HOME_POWER);

	// 4. hoher Leistungsbedarf (criticalMode)
    // Darf NUR laufen, wenn KEIN Batterieschutz greift
    if (!protectionActive && gridMeterValue >= criticalGridPower && dplAktiv && (nowSec - lastSec_criticalMode > intervalSec_criticalMode)) {
        // criticalMode starten
        dplAktiv = false;
        let critLimit = Math.min(Math.ceil(Math.max(netPowerWithoutBattery, 0)), criticalOutputLimit);

        setState(DP_AUTO_IN_OUT_LIMIT, critLimit);
        console.info('Critical Mode AN: auto_in_out_Limit gesetzt auf: ' + critLimit + ' W');

        lastSec_criticalMode = nowSec;
        lastSec_outputLimit_auto_in_out_Limit = nowSec;

    } else if (!dplAktiv && (protectionActive || (nowSec - lastSec_criticalMode > intervalSec_criticalMode))) {
        // criticalMode läuft: verlängern oder beenden
        if (gridMeterValue >= criticalGridPower && !protectionActive) {
            let critLimit = Math.min(Math.ceil(Math.max(netPowerWithoutBattery, 0)), criticalOutputLimit);
            if (critLimit !== getSafeVal(DP_OUTPUT_LIMIT)) {
                setState(DP_AUTO_IN_OUT_LIMIT, critLimit);
                console.info('Critical Mode VERLÄNGERT: auto_in_out_Limit angepasst auf: ' + critLimit + ' W');
            }
            lastSec_criticalMode = nowSec;
            lastSec_outputLimit_auto_in_out_Limit = nowSec;
        } else {
            // Lastspitze vorbei ODER Batterieschutz, dann criticalMode beenden, normale Regelung wieder freigeben
            lastSec_outputLimit_auto_in_out_Limit = 0;
            lastSec_inputLimit_auto_in_out_Limit = 0;
            dplAktiv = true;
            lastSec_criticalMode = nowSec;
            console.info('Critical Mode AUS: Zurück zur normalen Regelung.');
        }
    }

	// 5. normale Regelung Nulleinspeisung & Laderegelung
    if (dplAktiv) {
        // Sicherstellen, dass Zendure im SmartMode (1) läuft
        if (getSafeVal(DP_SMART_MODE) === 0) {
            setState(DP_SMART_MODE, 1);
        }

        let newLimit = 0;
        let currentAcMode = getSafeVal(DP_AC_MODE);
        let acModeTimeOk = (nowSec - lastSec_change_acModeAllowed >= intervalSec_change_acModeAllowed);

        // Aktuell gesetzten Wert ermitteln (Laden negativ, Entladen positiv)
        let currentActiveLimit = 0;
        if (getSafeVal(DP_INPUT_LIMIT) > 0) {
            currentActiveLimit = getSafeVal(DP_INPUT_LIMIT) * -1;
        } else if (getSafeVal(DP_OUTPUT_LIMIT) > 0) {
            currentActiveLimit = getSafeVal(DP_OUTPUT_LIMIT);
        }

        // Hysterese: bei kleiner Abweichung wird nichts geändert
        let difference = Math.abs(netPowerWithoutBattery - currentActiveLimit);
        let hysteresisHold = (difference < wattChangeThreshold);
        if (hysteresisHold) {
            newLimit = currentActiveLimit;
        }

        // FALL A: Überschuss vorhanden, dann Ladeleistung berechnen (Wert wird negativ)
        if (!hysteresisHold && netPowerWithoutBattery <= -100 - safetyReserve) {
            let safeSurplus = netPowerWithoutBattery + safetyReserve;
            let steppedLimit = Math.ceil(safeSurplus / chargingStep) * chargingStep;

            newLimit = steppedLimit > -100 ? 0 : steppedLimit;

            if (newLimit <= (max_inputLimit * -1)) {
                newLimit = max_inputLimit * -1;
            }
        }

        // FALL D: NOTABSCHALTUNG bei Batterieschutz oder leerem Akku
        if ((protectionActive || currentSoc <= minSocLimit) && getSafeVal(DP_OUTPUT_LIMIT) > 0) {
            setState(DP_AUTO_IN_OUT_LIMIT, 0);
            console.info('auto_in_out_Limit 0: Entladen gesperrt (Batterieschutz aktiv / MinSoC erreicht)');
            lastSec_outputLimit_auto_in_out_Limit = nowSec;

        // FALL B: Netzbezug vorhanden, dann aus Akku entladen (Wert ist positiv)
        } else if (!protectionActive && currentSoc > minSocLimit && netPowerWithoutBattery > 0 && !hysteresisHold && (nowSec - lastSec_outputLimit_auto_in_out_Limit >= intervalSec_outputLimit)) {
            let targetDemand = Math.ceil(netPowerWithoutBattery);

            if (targetDemand <= 30) {
                newLimit = 30;
            } else if (targetDemand <= 60) {
                newLimit = 60;
            } else if (targetDemand <= 90) {
                newLimit = 90;
            } else if (targetDemand <= 100) {
                newLimit = 100;
            } else {
                newLimit = Math.ceil(targetDemand / dischargeStep) * dischargeStep;
            }

            if (newLimit >= max_outputLimit) {
                newLimit = max_outputLimit;
            }

            // Senden... Relais-Schutz: Wechsel vom Lade- in Entlade-Modus nur nach der Sperrzeit
            if (newLimit !== getSafeVal(DP_OUTPUT_LIMIT)) {
                if (currentAcMode !== 1 || acModeTimeOk) {
                    setState(DP_AUTO_IN_OUT_LIMIT, newLimit);
                    console.info('Entladen: auto_in_out_Limit gesetzt auf ' + newLimit + ' W');
                    lastSec_outputLimit_auto_in_out_Limit = nowSec;
                }
            }

        // FALL C: Überschuss oder kein Verbrauch, dann Laden bzw. Entladen beenden
        } else if (netPowerWithoutBattery <= 0 && (nowSec - lastSec_inputLimit_auto_in_out_Limit >= intervalSec_inputLimit)) {
            let currentPassMode = getSafeVal(DP_PASS);

            // Ladegrenze erreicht oder Gerät im Pass-Modus -> nicht laden
            let chargeBlocked = (socLimitState === 1 || currentSoc >= maxSocLimit || currentPassMode === 2);
            if (chargeBlocked && newLimit < 0) {
                newLimit = 0;
            }

            if (newLimit !== currentActiveLimit) {
                // Relais-Schutz: Wechsel vom Entlade- ins Lade-Modus nur nach der Sperrzeit (Stoppen ist immer erlaubt)
                if (newLimit === 0 || currentAcMode !== 2 || acModeTimeOk) {
                    setState(DP_AUTO_IN_OUT_LIMIT, newLimit);
                    console.info('auto_in_out_Limit gesetzt auf ' + newLimit + ' W (negativ = Laden, 0 = Aus)');
                    lastSec_inputLimit_auto_in_out_Limit = nowSec;
                    if (newLimit === 0) {
                        lastSec_outputLimit_auto_in_out_Limit = nowSec;
                    }
                }
            }
        }
    }
});

[maxclaudi]

10.10.2026; 16:28h Memo:
Ab Firmware > V2.0.2 (bzw. V2.0.4) wird eine weitere, spezifische proprietäre Endstelle/Adresse hinzugefügt.

Spoiler

Bisher nur:

apiUrl: https://app.zendure.tech/as

Nun zusätzlich:

ocppUrl: wss://mq.zen-iot.com:33033/ocpp

Hintergrund: OCPP (Open Charge Point Protocol) ist der weltweite Standard zur Steuerung von E-Auto-Ladestationen (Wallboxen). Die Aktivierung dieses Endpunkts signalisiert die firmwareseitige Vorbereitung oder bereits vorhandene Funktion auf integriertes EV-Charging (z. B. herstellereigene Wallbox oder Lademanagement).

Für "Cloudless"-Setups: Wer sein System rein lokal betreibt, sollte diese WebSocket-Adresse im Router/DNS blockieren, um unbemerktes "Nachhausetelefonieren" zu verhindern.

---

edit 11.10.2026; 08:20h
2400AC Pro; Firmware: 2.0.4
seit 11.10.2026; 05:51:15h mit mosquitto als Broker über Port: 1883 ohne TLS verbunden (Bridge-Modus Cloud).

Spoiler

edit: Memo

Spoiler

Bei Verbindung Port:1883 wurde automatisch gesetzt:

gridOffMode: 2
gridReverse: 2
inverseMaxPower: 800
outputLimit:200
gridStandard: 0

Setzen der Werte sofort durchgeführt.
Topic: iot/<prod.>/<dev.>/properties/write

{
    "properties": {
    "gridStandard": 0,
    "inverseMaxPower": 2400,
    "chargeLimit": 2400,
    "smartMode": 1,
    "outputLimit": 0,
    "inputLimit": 0,
    "gridReverse": 1
  }
}

toDo_247 - edit 21:40h Analyse abgeschlossen.
Abzweigung 31 analysieren.
edit 11.10.2026; 12:48h
Firmware / apk HTTPS verifiziert.
Treffer; Werte in App werden unabhängig von Abzweigung 31 aktualisiert.

edit 11.10.2026; 12:04h
2400AC Pro; seit 11.10.2026; 05:51:15h mit mosquitto als Broker über Port: 1883 ohne TLS verbunden (Bridge-Modus Cloud).
App: Parallele Steuerung in der Bridge per App funktioniert einwandfrei.

---

edit 11.10.2026; 13:15h report/getALL stabil.

Spoiler

Auszug Log (Report-Intervall: 3000ms):

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:26:45:027
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:26:45:046

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:26:48:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:26:48:086

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:26:51:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:26:51:069

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:26:54:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:26:54:046

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:26:57:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:26:57:087

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:27:00:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:27:00:084

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:27:03:028
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:27:03:056

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:27:06:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:27:06:046

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:27:09:025
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:27:09:093

[getAll] -> iot/2Qe7C9/xXXXxXXX/properties/read
2026-10-11 10:27:12:026
[report] -> /2Qe7C9/xXXXxXXX/properties/report
2026-10-11 10:27:12:067

Ergebnis:
3 sek. Report absolut stabil, lückenlos und ohne Lag möglich.
Man sieht wunderbar, dass der Broker immer exakt zur Sekunde :45, :48, :51 etc. anfragt und die vollständigen Antworten Millisekunden später da sind.

---

Edit 11.10.2026, 21:40 Uhr Analyse abgeschlossen

Spoiler

Analysiert, getestet und verifiziert:
mqttInit und WiFi liegen im Zweig_43 <Datenschutz> und können auch aktiviert werden.

Ergebnis:
WiFi und MQTT können aktiviert werden (toDo_247/Analyse abgeschlossen).
Mehrmals erfolgreich getestet. Das Gerät verbindet sich über Port 1883. Die Aktivierung ist mit zURLtool oder der App V7.0 mit einem Trick möglich.
Weltweit das erste Mal öffentlich dokumentiert.

Hinweis: Eine detaillierte Anleitung zum Verbinden über Port 1883 wird von mir nicht öffentlich publiziert. Entsprechende Anfragen bitte ausschließlich per PN oder E-Mail – ich werde im Einzelfall abwägen.

Damit sind alle entscheidenden Analysen und das Log-Mapping (bis auf wenige Ausnahmen) für mich abgeschlossen.

edit: 12.10.2026; 12:40h Mythos widerlegt: BT und WiFi simultan möglich

Spoiler

verifiziert:
Entgegen der bisherigen Annahme ist eine simultane, dauerhafte Parallelschaltung von MQTT (Port 1883) und Bluetooth möglich.

Damit ist der weitverbreitete Mythos, dass BT und WLAN nicht parallel laufen können, widerlegt.
Interessantes Detail zur Funktionsweise:
Im Gegensatz zu MQTT (Port 1883) sendet die BT-Verbindung sofort nach einmaligem Anstoßen durch ein getAll automatisch alle 5000ms einen Report über einen Timer (wie im standardmäßigen MQTT Port 8883 Modus).

Ein reiner Bluetooth-Betrieb ist somit als dauerhafte, lokale Alternative zu MQTT möglich. Damit stehen nun drei Verbindungswege zur Auswahl: MQTT 8883, MQTT 1883 und reines BT. Zieht man das zenSDK separat in Betracht, sind es vier Verbindungswege.

[T-147]

@maxclaudi

Danke Dir, probier ich die Tage aus.

Hatte nach dem Firmware-Update auf 2.0.2 gestern den Fehlercode 33, der ja offensichtlich ein Bug zu sein scheint. Hab aber noch keine neue Firmware verfügbar bei mir.
Das mit dem Absinken deutlich unter 10% soll auch mit der Firmware zu tun haben, hab ich gestern gelesen, aber 100% sicher ist das natürlich nicht. Evtl schreib ich mal den Support an, ob ich vorgezogen werden kann mit dem Update.
Warte aktuell darauf, dass der Wechselrichter startet, aber die Sonne tut sich grad noch schwer...

[maxclaudi]

@T-147
Neben einem reinen Software-Bug können es auch kurzzeitige Spannungsschwankungen oder Kriechströme an den MC4-Steckern der PV-Module sein. Ich würde an deiner Stelle die Steckverbindungen mal kontrollieren – nicht dass sich dort Feuchtigkeit eingeschlichen hat oder Kontaktprobleme vorhanden sind.
Sollte es sich beim Pro tatsächlich um einen Bug handeln: Nach meinen Analysen ist die V2.0.2 (bzw. die darin enthaltene ESP-Steuerungs-Firmware) – wenn auch vielleicht nicht absolut fehlerfrei – m. M. n. immer noch die stabilste Version.

[maxclaudi]

edit 21.10.2026; 10:54h erledigt.

Suche vertrauenswürdige(n) Mitwirkende(n) für unabhängige, private Tests

⚠️ Wichtiger Hinweis zur Vertraulichkeit:
Da es sich hierbei um ein experimentelles Setup handelt, suche ich Tester, die absolut verlässlich sind.
Ich bitte eindringlich darum, Testergebnisse, Script-Details und den Ablauf der Tests streng vertraulich zu behandeln.
Die Kommunikation soll ausschließlich im privaten Kreis (per PN/E-Mail) stattfinden und nicht öffentlich im Forum oder an anderen Stellen gepostet werden.
DurchgestrichenBitte melde dich nur, wenn du mit dieser Geheimhaltung einverstanden bist.

Voraussetzungen:

• ioBroker
• Das zenSDK-Steuerungs-Script aus diesem Thread
• Zendure-App (nur für Erst-Verbindung nötig)
• Zendure-Gerät mit zenSDK-Unterstützung

Idealerweise vorhanden (vorzugsweise):

• AdGuard Home oder Pi-hole, um eine DNS-Umschreibung einzurichten
• Eigener Mosquitto-Broker (oder ein anderer MQTT-Broker)

und / oder:

• Eine FRITZ!Box (oder ein anderer Router), um dem Gerät die Internetverbindung zu sperren

Gesucht werden maximal 2 Testpersonen. Bei Interesse bitte ausschließlich per PN oder E-Mail bei mir melden, damit der Thread hier sauber bleibt. Danke!

ztool.maxclaudi AT gmail . com

edit: Um Bots oder Fake-Anfragen auszuschließen, ist ein bestehender Account im ioBroker-Forum oder einem etablierten PV-Forum erforderlich.
Interessierte ohne Foren-Historie können leider nicht berücksichtigt werden.
Jedes aktive Mitglied – egal ob Profi oder Einsteiger – ist herzlich willkommen!
Bei Interesse bitte einfach per PM oder E-Mail melden.

---

[petman]

@T-147
ich hab den SF800pro2 mit 2.0.2, war schon bei der Erstinbetreiebnahme drauf, mitZwei AB2000, ein 2 Jahre alter und der vom SF800pro2
Hatte letzte Woche auch "Tiefentladung" bis 2,56V(alter AB) bzw. 2,7V (neuerAB) am Morgen und er ist schon mehrfach im Einspeisemodus hängengeblieben aber bisher noch nie so Teifenladen. Ich musste dann eingreifen und aus dem Netz laden, was ich bisher vermieden habe weil vormittags keine Sonne. Als die Akkus wieder auf 20% waren hat er sich wieder gefangen und wieder normal gearbeitet.
Ich habe das SDK-Skript und den Blockly von maxclaudi, 4x 450Wp OSO/WNW, je eins an einem MPT.
Vorher hatte ich je zwei am SF1200+HM800.
Ich hab das Gefühl die Ausbeute war durch die OpenDTUonBatt besser, weniger ungewollte Einspeisung.

peter

[Daniel 8]

Seit heute Nacht gibt es die Version 2
0.5 Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

[maxclaudi]

@petman sagte:

@T-147
ich hab den SF800pro2 mit 2.0.2, war schon bei der Erstinbetreiebnahme drauf, mitZwei AB2000, ein 2 Jahre alter und der vom SF800pro2
Hatte letzte Woche auch "Tiefentladung" bis 2,56V(alter AB) bzw. 2,7V (neuerAB) am Morgen und er ist schon mehrfach im Einspeisemodus hängengeblieben aber bisher noch nie so Teifenladen. Ich musste dann eingreifen und aus dem Netz laden, was ich bisher vermieden habe weil vormittags keine Sonne. Als die Akkus wieder auf 20% waren hat er sich wieder gefangen und wieder normal gearbeitet.
Ich habe das SDK-Skript und den Blockly von maxclaudi, 4x 450Wp OSO/WNW, je eins an einem MPT.

Bitte verwende statt Blockly mal das JS-Script aus #Post 610
Damit sollte der Batterieschutz übergeordnet greifen, falls die Firmware selbst einmal nicht rechtzeitig einlenkt.

Vorher hatte ich je zwei am SF1200+HM800.
Ich hab das Gefühl die Ausbeute war durch die OpenDTUonBatt besser, weniger ungewollte Einspeisung.

Dazu kannst du die Regelwerte im JS-Skript ganz einfach anpassen und optimieren. Teste dafür mal die Parameter im Konfigurationsbereich:

let intervalSec_outputLimit = 15; // Entladen frühestens nach X Sekunden. Standard: 15 s
let intervalSec_inputLimit  = 20; // Laden frühestens nach X Sekunden. Standard: 20 s
let chargingStep            = 50; // Schritte AC-Laden (z.B. 50 W, 100 W). Standard: 50 W
let dischargeStep           = 10; // Schritte Entladen, wird aufgerundet. Standard: 10 W
let wattChangeThreshold     = 20; // Hysterese Watt oder 15W testen
let safetyReserve           = 20; // Sicherheitsreserve gegen Netzbezug beim Laden. Standard: 20 W
 
let criticalGridPower        = 600;  // Ab wie viel Watt Netzbezug gilt es als hoher Leistungsabruf. Standard: 600 W
let criticalOutputLimit      = 800; // Maximale Entladeleistung im Critical-Mode 
let intervalSec_criticalMode = 30;   // So lange wird die Spitze gehalten (taktende Großverbraucher: Herd, Klima, Durchlauferhitzer)
 
let intervalSec_change_acModeAllowed = 30; // Relais-Schutz z.B. 30s
let batteryLockMinCellVoltage   = 3.20; // Entladesperre z.B. 3.20 V
let batteryUnlockMinCellVoltage = 3.25; // Freigabe nach der Sperre sek
let batteryRecoveryTimeSec      = 300;  // Beruhigungszeit der Zellen in Sekunden. Standard: 300 s (5 min)
 

Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

Trotz der zusätzlichen Wandlerverluste scheint das System inklusive der Regelung bei mir unterm Strich produktiver zu laufen, als die PV-Leistung direkt über DC in das Zendure-Gerät einzuspeisen.

Auch wenn es theoretisch durch die Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) ineffizienter sein müsste, zeigt die Praxis bei mir, dass die exzellente MPPT-Regelung der Hoymiles und deren extrem niedrige Latenz anscheinend die träge Zendure-DC-Regelung ausstechen.

Elektrotechnisch ist das eigentlich paradox und auf den ersten Blick schwer zu erklären – denn der direkte Weg über PV (DC) ➔ Laderegler ➔ Batterie (48V DC) müsste rein rechnerisch immer im Vorteil sein.
Dennoch arbeiten hier völlig unterschiedliche Herstellerphilosophien auf Protokoll- und Hardwareebene gegeneinander, und in meiner Praxis bewährt sich die AC-Variante deutlich besser.

---

@Daniel-8 sagte:

Seit heute Nacht gibt es die Version 2.0.5
Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

Die V2.0.5 kann ich für dein spezifisches Gerät – und auch allgemein – nicht beurteilen.
Normalerweise fahre ich die Strategie: Abwarten.
Wenn das System aktuell stabil läuft, gibt es keinen akuten Grund für Eile. Falls du jedoch gravierende Probleme im laufenden Betrieb hast, würde ich das Update vorziehen.
Wenn alles unauffällig läuft: Lieber erst mal beobachten, was die Community berichtet.

[Daniel 8]

@maxclaudi sagte:

Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

Trotz der zusätzlichen Wandlerverluste scheint das System inklusive der Regelung bei mir unterm Strich produktiver zu laufen, als die PV-Leistung direkt über DC in das Zendure-Gerät einzuspeisen.

Auch wenn es theoretisch durch die Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) ineffizienter sein müsste, zeigt die Praxis bei mir, dass die exzellente MPPT-Regelung der Hoymiles und deren extrem niedrige Latenz anscheinend die träge Zendure-DC-Regelung ausstechen.

Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

[petman]

@maxclaudi sagte:

Bitte verwende statt Blockly mal das JS-Script aus #Post 610
Damit sollte der Batterieschutz übergeordnet greifen, falls die Firmware selbst einmal nicht rechtzeitig einlenkt.

Dankeschön, habs eingepflegt und auf meine daten angepasst.
Schaun mer mal...

petman

[Murphy 0]

@maxclaudi sagte:
Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

Benutze auch meine Hoymiles weiter und lade rein AC-seitig.
Der Hyper kann im Keller stehen und meine Steuerung per Blockly bleibt überschaubar.

Win Win Win sozusagen.

[maxclaudi]

@Daniel-8 sagte:
Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

Meine bisherigen Beobachtungen dazu:
Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

Die Hoymiles-Wechselrichter starten im Vergleich deutlich schneller. Sie speisen selbst bei minimalen Wattwerten bereits ein.
Laut Datenblatt liegt die Einschaltspannung des HM-1200 und HM-400 bei gerade einmal 22 V, während der eigentliche Betriebsspannungsbereich sogar schon ab 16 V beginnt.
Gerade zum Abend hin speisen die Hoymiles dadurch noch absolut zuverlässig Kleinstmengen ein (z. B. 6 W), wenn die Trägheit der Zendure-Regelung schon längst im Standby wäre.
Das MPPT-Tracking der Hoymiles arbeitet meiner Meinung nach um Welten präziser und „holt einfach mehr raus“ – und das jeden Tag aufs Neue.

Wenn das Zendure-Gerät per Skript also ausschließlich über AC geladen und entladen wird, fängt die exzellente Latenz der Hoymiles die theoretischen Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) in der Realität locker wieder auf.

Da kommen über das Jahr gerechnet definitiv einige Kilowattstunden zusammen!

Ich möchte und werde Zendure hier keineswegs schlecht reden.
Es ist schlicht meine persönliche Erfahrung bei meinem spezifischen Setup und Standort.
Gerade im Frühjahr, Herbst und Winter habe ich hier durch ein höheres Nachbarhaus und den tieferen Stand der Sonne mit schwierigen Verschattungen zu kämpfen.
Aber insgesamt sind die Wechselrichter von Hoymiles und deren MPPT-Regelung meiner Meinung nach in solchen Szenarien einfach überlegen.

[Daniel 8]

@maxclaudi sagte:

Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

Meine bisherigen Beobachtungen dazu:
Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

Vielen Dank für deine Meinung.
Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

[maxclaudi]

@Daniel-8 sagte:
Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

Völlig richtig, das steht außer Frage.
Es war ja auch lediglich die Beschreibung meines spezifischen Setups, da bei mir die Hoymiles-Wechselrichter ohnehin schon vorhanden waren.
Wenn man alles neu kaufen muss, sieht die Rechnung natürlich anders aus.

Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

Das verstehe ich ehrlich gesagt nicht ganz, denn es gibt ja verschiedene Kombinationsmöglichkeiten.

Ein AC-Laden mit konstanter, gleichmäßiger Leistung ist oft wesentlich effizienter, energetisch stabiler und materialschonender, als die Batterie über PV-DC bei ständig wechselnder Bewölkung und permanent schwankenden Wattwerten zu füttern.
Genau aus diesem Grund integriert man in sinnvolle Steuerungen ja auch Parameter wie eine Mindestdauer für den acMode (Relais-Schutz).

Zudem könnte man das System ja auch als Hybrid betreiben:
Einige wenige PV-Module, die z. B. „Problemkinder“ sind (geringere Leistung haben oder öfter verschattet werden), können oder bleiben einfach an den reinen DC-PV-Eingängen des SolarFlow angeschlossen.
Die starken, unverschatteten Module laufen parallel über den Hoymiles.

Der SolarFlow 800 Pro kann kontinuierlich mit bis zu 1000 W AC geladen werden – das ist für ein herkömmliches Balkonkraftwerk mehr als genug.
Die maximale Ausgangsleistung ist gesetzlich ohnehin auf 800 W begrenzt.

In meiner Praxis speise ich – abgesehen von kurzzeitigen Lastspitzen im criticalMode – eigentlich fast wie nie mehr als ca. ~500 W gleichzeitig ein.
Das hängt am Ende natürlich immer vom individuellen Grundverbrauch und der Personenanzahl im Haushalt ab.

Ein E-Auto-Lademanagement rechnet sich bei so kleinen Systemen aber im Regelfall sowieso fast nie.

Letzten Endes hängt – wie immer – alles vom einzelnen, spezifischen Setup, den vorhandenen, realen Gegebenheiten und den persönlichen Anforderungen ab.
Eine generelle Empfehlung ist deshalb nie möglich – nur Ratschläge und Ideen, was wie funktionieren könnte.

[T-147]

@Daniel-8 sagte:

Seit heute Nacht gibt es die Version 2
0.5 Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

Nachdem ich bei Firmware 2.0.2 immer wieder den Fehler 33 bekam (wurde mittlerweile vom Zendure-Support als Firmware-Fehler bestätigt) kam mir das Update gestern morgen sehr gelegen.
Ich nehm zwar ungern immer direkt die neueste Firmware, aber hier bleib mir nicht viel anderes übrig.
Wenn man mit der installierten Firmware keine Probleme hat oder nicht unbedingt ein neues Feature erwartet/benötigt, sollte man mMn immer etwas mit dem Update warten.

Bislang läuft mein SF800 Pro2 mit 2.0.5 ohne Auffälligkeiten und Probleme, auch mit dem ZenSDK-Script und der Nulleinspeisung von Maxclaudi (aktuell noch nicht die neueste Version, die mach ich heute erst bereit)

[T-147]

@maxclaudi sagte:
Meine bisherigen Beobachtungen dazu:
Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.
Vor allem, da meine 4 Panels in SO und SW ausgerichtet sind und ich wie Du (in SO-Richtung) in der dunkleren Jahreshälfte mit Verschattung durchs Nachbarhaus zu kämpfen hab.
Den HMS-1000 werd ich jetzt mit einem zusätzlichen Panel in Richtung S an die Offgrid-Dose hängen. Mal sehen, was das über den Winter an Mehrertrag bringt.

Leider lassen sich die Geräte von Zendure nicht so detailliert auslesen, wie die Hoymiles über eine OpenDTU zB, daher kann ich leider aus meinen Daten keine echten, direkten Vergleich herstellen.

[maxclaudi]

@T-147 sagte:
Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.

Meiner Meinung nach sitzt du da leider einem kleinen Mess- bzw. Anzeigefehler auf, was die realen physikalischen Abläufe angeht.

Die SolarFlow 800er-Pro-Serie hat die Steuerelektronik, die 4 MPPT-Regler und den Wechselrichter komplett in einem Gehäuse integriert.
Dieses Gesamtsystem (inklusive ESP32-Chip, WLAN, Bluetooth und Batterie-Management-System) hat einen permanenten, spürbaren Eigenverbrauch für den reinen Betrieb.

Wenn dir die App am Morgen anzeigt, dass mit "10 W" geladen wird, bedeutet das rein physikalisch folgendes:
Deine PV-Module müssen zu diesem Zeitpunkt bereits den kompletten internen Grundverbrauch des Geräts (für CPU, WLAN, BMS-Aktivierung etc.) gedeckt haben. Erst die Leistung, die darüber hinausgeht, bleibt netto übrig und wandert als die von dir gesehenen 10 W in die Batterie.

Man darf hier die reine Startspannung der MPPT-Tracker (die beim Pro 2 erfreulicherweise schon ab 14 V liegt) nicht mit der notwendigen Mindestleistung für den Systembetrieb verwechseln.
Ohne dass die PV-Leistung die interne Grundlast des Speichers vorab komplett kompensiert, kann das Gerät weder einspeisen noch laden.
Die Solarmodule müssen real also schon deutlich mehr als 10 W liefern, damit das System überhaupt aus dem Standby erwacht.

[T-147]

@maxclaudi
Klingt plausibel.
Danke für den Hinweis, soweit hab ich natürlich nicht gedacht.

[maxclaudi]

15.10.2026; 16:00h Weiterer Bericht zum Betrieb über MQTT-Port 1883 und zenSDK

Fortsetzung von:

Da es dazu weltweit quasi null Infos gibt, dachte ich, ich teile meine bisherigen Erkenntnisse mal auszugsweise als kleinen Bericht mit euch.

Wer möchte kann den Bericht im spoiler lesen, für alle anderen ist der Beitrag dann kürzer und kann ignoriert werden

Spoiler

MQTT-Port 1883: Verbindung mit neuen Zendure-Geräten und zenSDK

Wenn das Zendure-Gerät über den unverschlüsselten MQTT-Port 1883 gekoppelt ist, läuft das lokale zenSDK-Skript über HTTP spürbar stabiler und reagiert subjektiv deutlich schneller.
In meinen Testreihen war ein HTTP-Polling im 3000-ms-Takt absolut problemlos und lückenlos möglich.

Im produktiven Betrieb ist ein so schnelles Intervall allerdings sinnfrei.
Es ist besser, das Polling bei ≥ 4000 ms zu belassen.
Das schont das Netzwerk (Traffic), die Netzwerk-Ressourcen des ESP32 und verhindert das hardwarebedingte Empfangen von identischen Altwerten.

Bei meinem aktuellen Test wird keine MQTT-Steuerung/Regelung verwendet. Die gesamte Steuerung erfolgt exklusiv über das zenSDK mittels HTTP-Befehlen aus dem Skript dieses Threads.

Über die unverschlüsselte MQTT-Schnittstelle (Port 1883) sende ich lediglich in einem festen Intervall eine minimale Abfrage, um die MQTT-Verbindung im Hintergrund aktiv zu halten.
Realisiert durch ein Mini-Skript (ein kleines Blockly ist auch kein Problem), das im festen Intervall den MQTT-Adapter-Datenpunkt mit der stets gleichen Abfrage senden lässt.

Für meine eigenen Testreihen habe ich das Skript lediglich um ein paar zusätzliche Helper-Funktionen zum Debuggen erweitert.

Genialer Nebeneffekt:
Über das zenSDK lassen sich plötzlich auch die erweiterten Limits für minSoc (0–95 %) und socSet (6–100 %) völlig frei einstellen und stabil nutzen.
Im herkömmlichen Normalbetrieb über TLS auf Port 8883 sperrt sich die Firmware hier bekanntlich strikt; Werte für socSet unter 70 % sind dort gar nicht möglich.

Es sollte aber zwingend darauf geachtet werden, dass der eingestellte minSoc-Wert stets kleiner ist als der socSet-Wert.

Ich werde wohl das Skript für mich noch um eine integrierte Schutzlogik erweitern:
Sollte diese Bedingung nicht erfüllt sein, wird der Schreibbefehl blockiert.
Zudem möchte ich, dass z. B. socSet immer mindestens 2 % höher liegen soll als minSoc, um unlogische Hystereseschleifen der Hardware zu vermeiden.

Durch ein niedrigeres socSet funktioniert auch weiterhin alles stabil, wie die Erkennung von socLimit und dass der Bypass (pass) mit socSet indirekt gesteuert werden kann – z. B. dass der Bypass automatisch früher ein- oder ausgeschaltet wird.

Befund:
Der allseits bekannte und nervige energyLevel- bzw. SoC-Bug (plötzliche Sprünge oder Einfrieren der Prozentwerte) tritt in diesem unverschlüsselten Setup bei mir bisher nicht auf.

Es ist möglich, über MQTT, das HTTP-zenSDK und Bluetooth-Properties zu regeln.
Alle drei Steuerungsmöglichkeiten sind bzw. wären sogar simultan möglich.

MQTT bietet mehr bzw. alle Möglichkeiten, die aber eigentlich nicht für den normalen, lokalen Betrieb nötig sind.

Richtet man den Broker zusätzlich als Bridge zur Cloud ein, kann die App weiter verwendet werden.
HEMS ist bei mir (bis jetzt) dauerhaft deaktiviert.
Außer für eine Zeitsynchronisation hat die Cloud bisher nicht in das System eingegriffen.

edit 21.10.2026; 10:45 erledigt
PS: Ich suche immer noch [1 Tester]

Wer sich bedanken möchte, weiß ja, wo der Voting-Button ist. Ein extra Post dafür muss nicht sein. ;-)

[T-147]

@maxclaudi

Das neue Java-Script lief gestern ohne erkennbare Probleme und hat die Batteriesperre sauber gesetzt und auch dann aufgehört einzuspeisen.

Was mich nur grad ein wenig stört ist die Tatsache, dass das Einspeisen schon bei 24% SoC beendet wurde, weil die minVol von 3,16V erreicht wurde. So weit über dem MinSoC find ich schon viel. Macht jetzt im Herbst/Winter nicht so viel aus, aber im Sommer würde da schon einiges verschenkt.
Ich weiß, SoC ist (deutlich) ungenauer, aber so viel Unterschied ist schon krass.

Aber das ist ja kein Problem Deiner Skripte, sondern ein generelles Elektronik-/Akku-Thema.

Das mit dem CriticalOutputLimit muss ich über das Wochenende nochmal beobachten. Heute Nachmittag kommt das Kind von der Klassenfahrt zurück, dann steigt der Stromverbauch wieder deutlich