Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[maxclaudi]

@T-147 sagte:
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.

Schön zu hören, dass das Skript an sich erst einmal sauber läuft!

Zu dem frühen Stopp bei 24% SoC: Das ist bei LFP-Zellen (wie den 15S-Akkus von Zendure) unter Last völlig normal.

Die LFP-Spannungskurve ist extrem flach, und unter aktiver Entladung bricht die Spannung durch den Innenwiderstand der Zellen künstlich ein (sogenannter Voltage Sag).
Eine Zelle, die laut BMS-Schätzung noch bei 24% steht, kann unter Last also kurzfristig unter die 3,16 V rutschen.
Sobald die Last weg ist, erholt sich die Spannung wieder.
Zudem neigt der angezeigte SoC zum "Driften", wenn länger nicht voll- und tiefer entladen wurde.

Als reiner Erfahrungswert (ausdrücklich KEINE allgemeine Empfehlung!):
Meine Batterien stehen im unbeheizten Innenbereich (nie unter 10°C).
Bei meinem Setup fahre ich im Normalbetrieb hiermit sehr gut:

let batteryLockMinCellVoltage   = 3.14; // Entladesperre normal (entspricht unter Last ca. 8-12% realem Rest-SoC)

Wenn es draußen richtig kalt wird (0°C oder Minusgrade), passe ich es an, da Kälte den Spannungsabfall unter Last noch verstärkt:

let batteryLockMinCellVoltage   = 3.16; // Entladesperre bei Kälte

Allgemein empfehlen möchte ich das aber nicht, da jedes Setup anders reagiert. Bei mir hat das System dieses Jahr bisher nur zweimal komplett abgeschaltet. Die normalen Ladevorgänge finden meistens statt, bevor es so weit runtergeht.

Um die SoC-Berechnung des BMS wieder zu kalibrieren, lasse ich die Akkus 1x monatlich komplett auf 100% aufladen – und zusätzlich immer dann, wenn die minVol doch mal häufiger erreicht wurden bzw. erreicht werden sollten.

Vielleicht hilft Dir das ein wenig weiter.

[T-147]

@maxclaudi sagte:
Zu dem frühen Stopp bei 24% SoC: Das ist bei LFP-Zellen (wie den 15S-Akkus von Zendure) unter Last völlig normal.

Die LFP-Spannungskurve ist extrem flach, und unter aktiver Entladung bricht die Spannung durch den Innenwiderstand der Zellen künstlich ein (sogenannter Voltage Sag).
Eine Zelle, die laut BMS-Schätzung noch bei 24% steht, kann unter Last also kurzfristig unter die 3,16 V rutschen.
Sobald die Last weg ist, erholt sich die Spannung wieder.
Zudem neigt der angezeigte SoC zum "Driften", wenn länger nicht voll- und tiefer entladen wurde.

Genau das meinte ich mit "Elektronik-/Akku-Thema"

Als reiner Erfahrungswert (ausdrücklich KEINE allgemeine Empfehlung!):
Meine Batterien stehen im unbeheizten Innenbereich (nie unter 10°C).
Bei meinem Setup fahre ich im Normalbetrieb hiermit sehr gut:

let batteryLockMinCellVoltage   = 3.14; // Entladesperre normal (entspricht unter Last ca. 8-12% realem Rest-SoC)

Wenn es draußen richtig kalt wird (0°C oder Minusgrade), passe ich es an, da Kälte den Spannungsabfall unter Last noch verstärkt:

let batteryLockMinCellVoltage   = 3.16; // Entladesperre bei Kälte

Ich habe hier ähnliche Bedingungen: ungeheizter Dachboden, auch im Winter nie unter 10° gewesen. Ich werde mich mal ganz langsam rantasten.

Um die SoC-Berechnung des BMS wieder zu kalibrieren, lasse ich die Akkus 1x monatlich komplett auf 100% aufladen – und zusätzlich immer dann, wenn die minVol doch mal häufiger erreicht wurden bzw. erreicht werden sollten.

Vielleicht hilft Dir das ein wenig weiter.

Wie machst du die Kalibrierung? Schaltest du die DPL-Regelung einfach solange ab, machst du das über ein separates Script als CronJob oder sowas? Einfach manuell auf volle Last Aufladen stellen geht ja nicht, dann schaltet die Regelung das direkt wieder ab.
Oder setzt Zendure beim Kalibrieren irgendwo ein Flag, was man für eine automatische Steuerung nutzen könnte, oder sowas?
Hab gestern auf nem Screenshot der App was von Zwangskalibrierung gelesen und dass die Steuerung derzeit blockiert ist und nach der Kalibrierung wieder automatisch freigegeben wird.

Und nur nochmal zur Info:
Mein SF800 Pro 2 arbeitet mit der neuen FW 2.0.5 bisher ohne Auffälligkeiten, auch mit den ZenSDK- und DPL-Scripten.

[maxclaudi]

@T-147 sagte:

@maxclaudi sagte:
Zu dem frühen Stopp bei 24% SoC: Das ist bei LFP-Zellen (wie den 15S-Akkus von Zendure) unter Last völlig normal.

Genau das meinte ich mit "Elektronik-/Akku-Thema"

Unter plötzlicher großer Last oder im criticalMode kann die Spannung auch nur kurzzeitig einbrechen.
Um das sauber abzufangen, habe ich die Logik im Skript erweitert.

Neu bzw. Änderungen zum bisherigen JS-Script Post #610:

• Frühes Abschalten durch kurze Lastspitzen wird verhindert:
  Das Skript wurde um eine gefahrlose Pufferzeit erweitert.
  Wenn die schwächste Zelle die batteryLockMinCellVoltage (z. B. 3,14 V) erreicht, passiert erst einmal nichts.
  Erst wenn die Spannung nach Ablauf der Pufferzeit immer noch dauerhaft bei oder unter dem Grenzwert liegt, schaltet das Skript die Entladung ab.
  Das überbrückt das typische Taktungsverhalten von Großverbrauchern (wie dem Herd) perfekt.
  Da eine echte Tiefentladung bei LFP-Zellen erst etwas unter 2,50 V beginnt, besteht bei 3,14 V für wenige Minuten absolut kein Risiko für die Hardware.

• Einfache und verständliche Umsetzung: Die Verzögerung wurde auch diesmal sehr einfach gelöst – komplett ohne komplizierte Schleifen, Timeouts oder Ähnliches.
  Es bleibt für Einsteiger leicht verständlich und ist im Code ausreichend kommentiert.

• Keine neuen Parameter nötig:
  Die Logik nutzt einfach die bereits vorhandene Variable batteryRecoveryStartSec, um sich den Beginn des Spannungseinbruchs zu merken.
  Für die Dauer der Pufferzeit (z. B. 5 Minuten) wird auch der Wert aus der bestehenden Konfigurationsvariable batteryRecoveryTimeSec verwendet.

Vielleicht ist das Skript in dieser Form noch hilfreicher für Dich bzw. Euch! ;-)

// 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 16.10.2026_12:30h 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.
// ======================================================================================
 
//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), bitte kein "+", keine Sonderzeichen und keine Umlaute verwendnen!
const folderZendureApi = '0_userdata.0.zendure.' + "2400ACproZENsdk";
 
// Wie viele Batterien hast du? Mögliche Werte: 1, 2, 3, 4, 5 oder 6
const vorhandeneBatAnz = 1;
 
// 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";
 
 
// 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.16; // 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/Verzögerungszeit der Zellen in Sekunden. Standard: 300 s (5 min)

//---------------------------------------------------------------------------------------
// AB HIER NICHTS VERÄNDERN!
//---------------------------------------------------------------------------------------
 
// Anzahl Batterien sichern (nur 1 bis 6 erlaubt)
let batAnz = Math.round(vorhandeneBatAnz);
if (!(batAnz >= 1)) batAnz = 1;
if (batAnz > 6) batAnz = 6;
 
// Basis-Pfade zu Zendure-Eigenschaften
const BASE_PATH_PROPERTIES = folderZendureApi + '.properties.';
const BASE_PATH_CONTROL    = folderZendureApi + '.control.';
const BASE_PATH_PACKDATA   = folderZendureApi + '.packData.';
 
// Zellspannungs-Datenpunkt einer Batterie zusetzen
// (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;
 
// NEU: Zeitstempel für Beginn des Spannungseinbruchs (0 = alles ok)
let batteryVoltageDropStartSec = 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();
 
    // ZELLSPANNUNGEN UND GERÄTE-WERTE AUSLESEN
    // Es wird die niedrigste Zellspannung aller vorhandenen Batterien verwendet; Fallback 3.30V
    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);

    // BATTERIE-ENTLADESCHUTZ (Erweitert um verzögerten Zellschutz unter Last)
    if (socLimitState === 2) {
        // Sofortiger Stopp bei hartem SoC-Limit der App
        if (!batteryLock) {
            batteryLock = true;
            console.info('Zellschutz AKTIVIERT. SoC-Limit der App erreicht.');
        }
    } else if (minCell <= batteryLockMinCellVoltage && packState !== 1) {
        // Spannung unterschritten, aber Gerät lädt nicht aktiv
        if (batteryVoltageDropStartSec === 0) {
            // Der Spannungseinbruch fängt gerade erst an -> Zeitpunkt merken
            batteryVoltageDropStartSec = nowSec;
            console.info('Mindestspannung unterschritten (' + minCell + ' V). Pufferzeit von ' + batteryRecoveryTimeSec + ' Sekunden läuft...');
        } else if (nowSec - batteryVoltageDropStartSec >= batteryRecoveryTimeSec) {
            // Die Pufferzeit (z.B. 5 Min) ist abgelaufen und die Spannung ist immer noch zu niedrig
            if (!batteryLock) {
                batteryLock = true;
                console.info('Zellschutz AKTIVIERT. Mindestspannung nach Ablauf der Pufferzeit dauerhaft unterschritten.');
            }
        }
    } else {
        // Spannung ist wieder über dem Grenzwert -> Timer zurücksetzen
        batteryVoltageDropStartSec = 0;
    }
 
    // 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;
            batteryVoltageDropStartSec = 0; // Komplett zurücksetzen
            console.info('Zellschutz ERFOLGREICH DEAKTIVIERT. Batterien wieder stabil.');
        }
    }
 
    // true = Entladen ist gesperrt
    let protectionActive = (batteryLock || socLimitState === 2);
 
	// aktuellen Hausverbrauch (ohne Bat) berechnen
    // positiv = Verbrauch / Netzbezug, negativ = Überschuss
    let netPowerWithoutBattery = (gridMeterValue - getSafeVal(DP_GRID_INPUT_POWER)) + getSafeVal(DP_OUTPUT_HOME_POWER);
 
	// 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.');
        }
    }
 
	// normale Regelung Nulleinspeisung & Laderegelung
    if (dplAktiv) {
        // Sichern, 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]

@T-147 sagte:
Wie machst du die Kalibrierung? Schaltest du die DPL-Regelung einfach solange ab, machst du das über ein separates Script als CronJob oder sowas? Einfach manuell auf volle Last Aufladen stellen geht ja nicht, dann schaltet die Regelung das direkt wieder ab.

Richtig: Wenn die normale Regelung aktiv ist, funkt sie natürlich dazwischen und regelt die AC-Ladeleistung sofort wieder weg.
Das lässt sich im Skript elegant über einen eigenen Software-Schalter lösen.

Ich mache das über eine einfache Erweiterung des Skripts durch einen zusätzlichen Boolean-Datenpunkt (z. B. 0_userdata.0...batteryCalibrationActive).

Das Prinzip ist denkbar einfach:

• Wenn true (Wert 1): Das Skript läuft im ganz normalen Alltagsmodus (Nulleinspeisung/CriticalMode)

• Wenn false (Wert 0): Die komplette normale Regelung und der Entladeschutz werden vollständig deaktiviert. Stattdessen wird eine separate Ladefunktion aufgerufen.

Wie läuft meine "sanfte" Kalibrierungs-Funktion ab?

1. Sanftes Laden per AC: Die Batterie wird zu einer bestimmten Zeit (vorzugsweise nachts bei günstigem Strom oder geringer Netzlast) materialschonend aufgeladen.

2. Drosselung ab 80 %: Sobald ein SoC von 80 % erreicht wird, drosselt die Funktion die AC-Ladeleistung automatisch herunter, um den Zellen im oberen Bereich Zeit zum Ausgleichen (Balancing) zu geben, und lädt sie so behutsam auf echte 100 % voll.

3. Die wichtige Ruhephase: Ist die Batterie voll, schaltet das Laden ab und es folgt eine programmierte Ruhephase (bei mir von 20 Minuten).
   In dieser Zeit können sich die Zellchemie und die Spannungen setzen.

4. Nachladen & Freigabe: Nach den 20 Minuten prüft die Funktion noch einmal die Spannungen.
   Ist eine Zelle wieder leicht abgesackt, wird kurz nachgeladen. Ist der Akku final stabil, setzt die Funktion den Boolean-Datenpunkt automatisch wieder auf true (1).
   Ab diesem Moment übernimmt sofort wieder die normale Nulleinspeisung.

Hinweis: Ich triggere diesen Datenpunkt ganz bewusst nur manuell, wenn ich merke, dass es Zeit für die Kalibrierung ist oder der monatliche Turnus ansteht.
Vollautomatisch möchte ich das nicht laufen lassen.
Die Funktion sorgt dann selbstständig dafür, dass das Ganze sauber in der Nacht durchgezogen wird.
Die zeitliche Steuerung (wann es nachts losgeht) kann sich dann ja jeder so anpassen, wie es zum eigenen Setup passt.

Hab gestern auf nem Screenshot der App was von Zwangskalibrierung gelesen und dass die Steuerung derzeit blockiert ist und nach der Kalibrierung wieder automatisch freigegeben wird.

Das würde doch dazu passen:

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.

[maxclaudi]

update 16.10.26 21:00h
batCalTime zusätzliche Type-Prüfung; fallback 01:00h / control.socCompSwitch ohne Funktion, entfernt

Wer bisher das Script bereits nutzt: Bitte vor Ausführung des Scripts den Datenpunkt:

control.socCompSwitch

löschen.

Alternativ gesamtes Verzeichnis mit allen Datenpunkten (inkl. dp properties etc.) löschen, für zusätzliche Beschreibungen.

Zum aktuellen Skript: HIER KLICKEN

[maxclaudi]

@T-147 sagte:

Oder setzt Zendure beim Kalibrieren irgendwo ein Flag, was man für eine automatische Steuerung nutzen könnte, oder sowas?

Zu deiner Frage mit den Flags von Zendure:
Ja, die gibt es. Man kann dazu zwei spezifische Datenpunkte (Keys) verwenden. Ich habe das bisher allerdings noch nicht im Live-Betrieb getestet und weiß nicht, wie gut die Firmware das handhabt oder ob die Cloud auch eine Rolle spielt.

1. Kalibrierungs-Flag (socStatus)
   Zendure bietet ein Info-Flag, das den aktuellen Zustand ausgibt:

socStatus - SOC calibration Info, 0: No Calibrating / 1: Calibrating

Wenn die Kalibrierung aktiv angelaufen ist, steht der Wert auf 1. Solange sie nur geplant ist und auf den Start wartet, bleibt der Status vermutlich auf 0.

2. Die Startzeit festlegen (control.batCalTime)
   Wenn das System eine Kalibrierung als notwendig erachtet, kann man den Startzeitpunkt beeinflussen.

batCalTime

Du kannst die Startzeit im gewohnten Uhrzeitformat von 00:00 bis 23:59 eingeben. Mein Skript fängt Fehleingaben ab: Wenn ein ungültiger Wert eingegeben wird, setzt das Skript automatisch 01:00 Uhr als Fallback.
Wichtig bei der Eingabe: Uhrzeiten vor 10:00 Uhr müssen mit einer führenden Null eingetragen werden, also zum Beispiel:

04:00

Erlaubte Werte: 00:00 bis 23:59

Könnte man im Regelungsscript einbauen, habe ich aber bisher im zenSDK-Steuerungs-Script nicht getestet. Weder mit noch ohne Cloud.

PS: Falls noch jemand Popcorn übrig hat: Ich hoffe, meine kleinen Monologe hier im Thread bieten zumindest guten Lesestoff für den Drink am Abend! ;-)

[MP_Trixi]

@maxclaudi
Hi. Wie oben geschrieben habe ich sowohl die FW als auch das Script auf Stand gebracht. Dazu noch die Max AC Ladeleistung auf 1000W gesetzt. Zwei Dinge sind mir aufgefallen:
wenn ich in 0_userdata.0.zendure.SolarFlow800Pro2.control.auto_in_out_Limit 0 schreibe war es so, dass nichts von AC geladen, nichts eingespeist aber von den Modulen die Batterien geladen wurden (glaube ich zumindest, kann auch sein dass es sich vorher so verhalten hat weil z.B. meine max. AC Ladeleistung auf 0 war). Jetzt sieht es komisch aus. In der App hat er „keinen Modus“, also weder Netzeingang noch Netzausgang. Die 0 scheint er aber zu registrieren aber faktisch arbeitet er mit dem letzten Modus und eingestellten Wert weiter.

[maxclaudi]

@MP_Trixi

Bitte stoppe das zenSDK-Steuerungsscript.
Lösche danach am besten den kompletten Pfad mit allen Datenpunkten.
Ersetze das bisherige zenSDK-Steuerungs-JS-Script mit der aktuellen Version und passe die Konfig an:

maxclaudi sagte:

update 16.10.26 21:00h
batCalTime zusätzliche Type-Prüfung; fallback 01:00h / control.socCompSwitch ohne Funktion, entfernt

Wer bisher das Script bereits nutzt: Bitte vor Ausführung des Scripts den Datenpunkt:

control.socCompSwitch

löschen.

Alternativ gesamtes Verzeichnis mit allen Datenpunkten (inkl. dp properties etc.) löschen, für zusätzliche Beschreibungen.

Zum aktuellen Skript: HIER KLICKEN

[MP_Trixi]

@maxclaudi
Ok. Ich habe einige aliase gesetzt. Sind die danach wieder da oder reicht es wie in deinen Post oben geschrieben nur control.socCompSwitch zu löschen?

[maxclaudi]

@MP_Trixi
Es reicht auch nur control.socCompSwitch zu löschen.

[MP_Trixi]

@maxclaudi
danke für deinen Input - habe ich gemacht (altes Script gestoppt, control.socComSwitch gelöscht, neues Script gestartet). Ich werde testen

[maxclaudi]

@MP_Trixi
Kann es sein, dass im Moment keine oder zu wenig Leistung kommt?
Ist bei mir so.
Es gibt eigenlich unter properties nur:

properties.outputPackPower
properties.packInputPower

Zur Kontrolle kannst Du das Script zur Nulleinspeisung stoppen.
Setze dann mal im dp:

control.auto_outputLimitMode

100 oder -100

gib dem Befehl 10 sek Zeit.
Danach ändert sich auch der Wert in
properties.packInputPower
oder
properties.outputPackPower

Wenn das funktioniert ist zu wenig PV-Leistung vorhanden. Müsstest Du auch in properties.solarInputPower feststellen.

Für die PV-Leistung oder Sonne kann ich nichts ;-)

PS: Durch das Edit von Dir sieht mein Post nun super aus :-)

[maxclaudi]

maxclaudi sagte:

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.

Heute ist bei mir so ein Tag - Regen - trüb.
2400ACpro werden PV-Leistung: 0 angezeigt obwohl 3 Module (420W, 200W, 200W) per DC MC4 angeschlossen sind.
Im Gegensatz Hoymiles:
Jedes einzelne Modul an einem Hoymiles speist mit 9 bis 23W ein.

[maxclaudi]

Update: Das zenSDK-Skript ist aktuell.
Wichtigste Änderung bleibt das auto_in_out_Limit (Danke @danitz!).
Da anscheinend noch ein paar ältere Versionen genutzt werden, obwohl es im letzten Skript schon drin war: Bitte updaten!

maxclaudi sagte:

update 16.10.26 21:00h
batCalTime zusätzliche Type-Prüfung; fallback 01:00h / control.socCompSwitch ohne Funktion, entfernt

Wer bisher das Script bereits nutzt: Bitte vor Ausführung des Scripts den Datenpunkt:

control.socCompSwitch

löschen.

Alternativ gesamtes Verzeichnis mit allen Datenpunkten (inkl. dp properties etc.) löschen, für zusätzliche Beschreibungen.

Zum aktuellen Skript: HIER KLICKEN

[maxclaudi]

20.10.2026; 15:18h Fortsetzung von:

15.10.2026; 16:00 Uhr: Weiterer Bericht zum Betrieb über MQTT-Port 1883 und zenSDK POST #628

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

Die Fortsetzung ist vermutlich gleichzeitig der Abschluss.

Wer möchte, kann den Bericht im Spoiler lesen;
für alle anderen ist der Beitrag dann kürzer und kann ignoriert werden. :-)

Spoiler

Ich habe meine Analysen abgeschlossen und teile ein paar Ergebnisse mit euch.

TLS Verbindung Port: 8883
Das wichtigste Ergebnis vorab:
Der herkömmliche, vorgesehene "Normal-" Betrieb über TLS ist absolut stabil möglich.

Es gibt keine Verbindungsabbrüche und keine Reconnects mehr – und das gilt auch für den Mosquitto-Bridge-Betrieb, sofern die eigene lokale IP im Zendure-Gerät (mithilfe meines zURLtool) konfiguriert ist.
Alles läuft extrem schnell und stabil.
Für mich gibt es dadurch keinen Grund mehr, einen anderen Weg einzuschlagen - vor allem nicht mit zusätzlichen Optionen (mehr dazu folgt weiter unten).
Durch die Stabilität und Schnelligkeit bei der jetzigen, regulären Betriebsart (TLS-Port 8883) kann ich keinen Mehrwert mehr über eine alternative Verbindung feststellen.
Zuvor war der ESP anscheinend auch teils durch die ständige Verarbeitung der Disconnects und Reconnects überlastet.
Jetzt ist alles super.

Die ständigen Disconnects/Reconnects der 8883-TLS-Verbindungen - seltsamerweise vom Client zum mosquitto-Broker und vermehrt im Bridge-Betrieb - waren für mich ein Kernproblem.
Laut Log passierte das ja quasi ununterbrochen im Minutentakt, teilweise sogar mehrfach pro Minute, obwohl man es subjektiv nicht richtig bemerkte.
Dachte immer, dass der ESP32-C überlastet wäre - jedoch explizit durch was?
Nur weil TLS verwendet wird und mit 1883 gab es keine Probleme.
Konnte doch nicht sein...
Nach tagelanger Analyse habe ich des Rätsels Lösung gefunden.
Im Nachhinein betrachtet fast trivial – aber mein Reverse Engineering hat sich hier definitiv gelohnt.
Die zuvor beobachteten ständigen Disconnects/Reconnects und OpenSSL-Fehler, die den ESP unbemerkt auslasteten, sind damit behoben.

Bisher dachte ich, die kursierenden Informationen der Open-Source-Community zu Bluetooth, MQTT & Co. seien korrekt oder nur minimal fehlerbehaftet, weil sie sich an vielen Stellen fast eins zu eins gleichen.
Dem ist aber nicht so.
Scheinbar wurde hier oft nur voneinander abgeschrieben.

---

Wenn man weiß, wie es geht, eröffnen sich ein paar sehr interessante Optionen:

• HTTP-Server komplett abschalten (localAPIenable true/false):
  Damit lässt sich der HTTP-Port bzw. der interne Webserver gezielt ein- oder ausschalten.
  Wenn er deaktiviert ist, kann das zenSDK natürlich leider nicht genutzt werden.
  Den reglementierten, „offiziellen lokalen HA-MQTT“ möchte man aber sowieso eher nicht nutzen.
  Der Vorteil:
  Ist der Server aus, wird der ESP32-C zusätzlich entlastet.

• Freie SoC-Grenzen:
  Es ist möglich, minSoc (5–98 %) und socSet (6–100 %) völlig frei einzustellen.
  Theoretisch beide von 0–100 %, jedoch muss socSet immer größer sein als minSoc!
  Damit lassen sich beispielsweise der Bypass (pass:0 / pass:2) und die Wirkung von socLimit indirekt steuern.
  Wenn der Webserver eingeschaltet bleibt, funktioniert das auch für zenSDK.
  Außer es wird in einer künftigen Firmware wieder geändert.
  Ich hoffe sehr, dass der Hersteller nichts ändert!
  Die Probleme mit den Verschlimmbesserungen beim SoC-Thema sollte endlich ein Ende finden.
  Hier gibt es bisher überhaupt kein Problem.
  Hoffentlich hört das Reglementieren auf..
  Aktuell getestet mit einigen Geräten <= V2.0.2 und V2.0.4 beim SF2400ACpro.

---

Cloud- & Bridge-Modus:

Bisher läuft alles tadellos über den Mosquitto-Broker im Bridgemodus zur Cloud.
Das Ganze ist absolut flexibel:

• Bei Bedarf muss man nur eine einzige Zeile auskommentieren und ist innerhalb von Sekunden entweder komplett lokal oder wieder mit der Cloud verbunden.

• Das Gleiche gilt für den Bridge-Mode: Man kann sich mit der Cloud verbinden – wahlweise mit oder ohne Schreibrechte für die Cloud.

• Bei deaktiviertem HEMS hat die Cloud von sich aus (bis jetzt) ausschließlich die Uhrzeit aktualisiert. Gut so.

---

HEMS- & NVS-Verschleiß (Flash):

Ich nutze HEMS selbst zwar nicht, habe es aber nun genauer auf dem Schirm.
So wie es „für mich aktuell“ aussieht, werden bei der Nutzung von hemsEp sehr wohl manche Parameter direkt in den NVS geschrieben.
Zwar nicht permanent kontinuierlich, aber bestimmte Keys landen dort.
Das betrifft nicht nur den Hyper, sondern auch mindestens 1600ACplus und SF2400ACpro, vermutlich alle Geräte.
Wer glaubt, dass alles ausschließlich im RAM landet, soll das gerne glauben.

Wie geht es weiter?
Für meinen Teil muss ich nun noch die Dokumentationen vervollständigen und ordnen.
Werde noch einmal die Geräte – pro forma erneut, frisch – aufsetzen und im reinen, produktiven Testbetrieb beobachten und loggen.
Evtl. widme ich mich nun noch etwas dem Thema hemsEp NVS/RAM – hat aber keine Priorität für mich, weil ich es nicht nutzen möchte.
Weil wir gerade beim Thema NVS sind: smartMode: 1 lässt sich für mich schwerer nachverfolgen als hemsEp.
Manches kann ich bis jetzt nicht eindeutig nachvollziehen, deshalb äußere ich mich auch nicht dazu.

Das war es dann.

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

Wie bei einem langweiligen Film: Endlich Ende! :-)

edit 21.10.26; 10:35h
Keine Tester mehr gesucht.
Tester und Nuzer denen ich mit mosquitto broker half, bitte per PM oder email melden. Danke.

Testers and users whom I have assisted while they were working with the Mosquitto broker: please get in touch with me via pm or email. Thanks.

[Daniel 8]

@maxclaudi sagte:

TLS Verbindung Port: 8883
Das wichtigste Ergebnis vorab:
Der herkömmliche, vorgesehene "Normal-" Betrieb über TLS ist absolut stabil möglich.

Kann man den Port über die app Option einfach so einstellen?

Das heißt mit dem läuft alles schneller und über mqtt. Dann bräuchte man Zensdk gar Nicht mehr.

Irgendwie übersteigt das ganze hier jetzt mein können.

[maxclaudi]

@Daniel-8 sagte:

@maxclaudi sagte:

TLS Verbindung Port: 8883
Das wichtigste Ergebnis vorab:
Der herkömmliche, vorgesehene "Normal-" Betrieb über TLS ist absolut stabil möglich.

Kann man den Port über die app Option einfach so einstellen?

Um es verständlicher zu erklären: Es geht hier um zwei unterschiedliche MQTT-Verbindungen.

Port 1883 ohne TLS:
Man kann den Port 1883 ohne TLS am Gerät und in der App (gewusst wie) freischalten und aktivieren.
Ab dann ist das Gerät über Port 1883 mit einer DNS-Adresse verbunden.
Diese DNS-Adresse muss per AdGuard, Pi-hole oder über einen eigenen DNS-Server auf den lokalen Broker umgebogen werden, wenn man lokal über die Datenpunkte steuern möchte.
Aber bei dieser Verbindung sind zu viele - ich nenne es mal - Möglichkeiten vorhanden und sollte m. M. n. nur kurzzeitig verwendet werden, näher gehe ich darauf nicht ein.

---

Port 8883 mit TLS:
Das ist der Standard.
So verbindet sich jedes Gerät.
Das Gerät ist über Port 8883 mit einer DNS-Adresse verbunden.
Diese DNS-Adresse kann ebenfalls per AdGuard, Pi-hole oder DNS-Server auf die IP des lokalen Brokers umgebogen werden, wenn man lokal über die Datenpunkte steuern möchte.

Alternativ:
Man konfiguriert die Variable für DNS/IP auf dem Gerät mit dem zURLtool um auf den lokalen Broker.
Auf dem lokalen Broker (z.B. Mosquitto) kann zusätzlich eine Bridge eingerichtet werden, damit das Gerät mit der Cloud verbunden bleibt.
Es ist in wenigen Sekunden erledigt, diese Bridge wahlweise abzuschalten oder der Cloud nur Lesezugriffe oder vollen Zugriff zu erlauben.

Mit einem lokalen Broker über MQTT ist die Steuerung zuverlässig, stabil und schneller als über die Cloud oder die lokale API (also auch zenSDK).

zenSDK macht nach meinen Analysen und Tests nur einen kleinen Unterschied, solange kein erhöhter HTTP(S)-Traffic im jeweiligen IP-Bereich bzw. Netzwerk vorliegt.
Wenn diese Voraussetzung gegeben ist und ein Abfrageintervall (Get) von etwa 4000 ms stabil möglich ist, kann auch das zenSDK genutzt werden.
Es ist dann nur unwesentlich langsamer als MQTT.

Der Grund dafür ist hardwarebedingt.
Auch wenn MQTT durch den schnelleren, automatischen Bericht-Versand (Report Publish) vom Gerät und das schnellere Publizieren neuer Werte klar im Vorteil ist, benötigt das Gerät hardwarebedingt Zeit.
Eine Limit-Umschaltung von inputLimit oder outputLimit braucht beispielsweise Zeit, um den Zielwert vollständig umzusetzen.

Einfacher Vergleich:
Du kannst bei einem Auto mit Automatikgetriebe und Turbolader zwar das Gaspedal oder die Bremse voll durchtreten, aber es dauert dennoch eine gewisse Zeit, bis die Höchstgeschwindigkeit oder der Stillstand erreicht sind.

Alle Klarheiten beseitigt? ;-)

---

Das heißt mit dem läuft alles schneller und über mqtt. Dann bräuchte man Zensdk gar Nicht mehr.

Richtig.
zenSDK ist, wie erklärt, unter den passenden Voraussetzungen langsamer als der lokale Broker über MQTT.
Eigentlich ist MQTT vorzuziehen, da hier nicht auf neue Werte gepollt werden muss, sondern diese sofort automatisch publiziert werden.
Zudem kann die lokale API abgeschaltet werden (gewusst wie) und der ESP32-C wird dadurch weiter entlastet.

22.10.2026:
ESP32-C, das ist übrigens die Standard-CPU, die verwendet wird und noch nirgendwo offiziell weltweit dokumentiert wurde.

Irgendwie übersteigt das ganze hier jetzt mein können.

Jetzt nicht mehr ;-)

Hinweis:
Ich überlege gerade ein MQTT-Steurungs-Script anzupassen, damit es als Ersatz für das zenSDK-Steuerungs-Script verwendet werden kann.
Damit bleiben alle Datenpunkte identisch, wenn man es gleich konfiguriert wie das zenSDK-Steuerungs-Script.
Bei identischer Benennung und Konfiguration, muss man darauf achten dass nur 1 Steuerungs-Script aktiv ist.

Bei unterschiedlicher Benennung kann zenSDK und MQTT gleichzeitig, simultan genutzt werden oder auch nur eins von beiden als vorrangiges Steuerungsscripts.

MQTT liefer natürlich einiges mehr an Infos.

[Daniel 8]

Vielen Dank für die ausführlichen Antworten.

Dann belasse ich es mal bei der Steuerung über zenSDK.

Ich Kämpfe seit 3 Tagen mit einem Problem wo ich nicht weiß woher das kommt.
Immer um 6.57 Uhr bringt das Script die Meldung Das ich meine IP Adresse überprüfen soll.

Und heute hat irgendwie mein Steuerungsscript komplett verrückt gespielt und mal alles ins Netz eingespeist. Das lief bis jetzt ohne Probleme schon eine Weile. Wobei ich heute auch das Firmware Update auf 2
0.5 gemacht habe.

War leider arbeiten und konnte nicht schauen warum dies heute so passiert ist.

[maxclaudi]

@Daniel-8 sagte:
Immer um 6.57 Uhr bringt das Script die Meldung Das ich meine IP Adresse überprüfen soll.

Wenn das täglich zur gleichen Uhrzeit vorkommt:
Prüfe mal deinen WLAN-Router oder WLAN-AP, ob dort ein täglicher Neustart konfiguriert ist.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Immer um 6.57 Uhr bringt das Script die Meldung Das ich meine IP Adresse überprüfen soll.

Wenn das täglich zur gleichen Uhrzeit vorkommt:
Prüfe mal deinen WLAN-Router oder WLAN-AP, ob dort ein täglicher Neustart konfiguriert ist.

Ist nicht immer ganz genau zur gleichen Zeit. So ca. Plus minus 6 Minuten.

Nein habe nichts programmiert. Ich werde mal beobachten. Jetzt ist ja zumindest der Speicher mal neu gestartet mit der neuen Firmware.
Und so werde ich schritt für schritt testen. Habe ja auch nichts verändert. Deswegen verstehe ich es nicht warum es jetzt so ist.