Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[nograx]

@bernd1967 Das Problem war mir bisher nicht bekannt. Ursächlich scheint ja zu sein das das Gerät nicht in der deviceList steht. Das ist ein Cloud/Server Problem von Zendure. Die Kollegen vom HA Team haben nur die alte "App"-Authentifizierung mit User/PW wieder aktiviert und dann scheint es zu klappen. Da bin ich aber gerade irgendwie ein wenig dagegen das wieder zu aktivieren. Hast du so ein Gerät?

[maxclaudi]

@Bernd1967 sagte:

@nograx
Gibt es schon eine Lösung für den neuen Solaflow 800 Pro 2 ?
zenSDK oder Lokal MQTT funktionieren aktuell nicht.
Die Kollegen von HA haben es wohl Testweise schon einmal geschafft:

#1263

Vielleicht mit den Adaptern nicht.
zenSDK über den Webserver z.B. mit Script funktioniert.

[Bernd1967]

@nograx sagte:

Hast du so ein Gerät?

Jo, hab ich die Tage erhalten.
Dann warte ich erstmal ab, Zendure wird das wohl noch regeln.

@maxclaudi sagte:

Vielleicht mit den Adaptern nicht.
zenSDK über den Webserver z.B. mit Script funktioniert.

Ok, dann werde ich die Tage das mal testen.

[nograx]

@Bernd1967 Solaflow 800 Pro 2 scheint aktuell wirklich nicht in der deviceList veröffentlich zu werden, das ist definitiv ein Fehler. Ich stehe im Kontakt mit zendure das die sich das anschauen. gebe dir hier eine Rückmeldung sobald ich was näheres weiß!

[Bernd1967]

@nograx
Hier schreibt einer das es wohl an einer EU Richtlinie liegt.
Support for SolarFlow 800 Pro 2 #74

Habe inzwischen die script Methode von @maxclaudi getestet, die funktioniert .
Danke Euch :-)

[peschu]

Hallo,
Ich habe mir das Gerät gekauft, weil ich es mit IObroker verwenden wollte. Wenn nicht absehbar ist, ob und wann es funktioniert, werde ich es zurückschicken und mir den Vorgänger besorgen.

Wie sieht die Scriptmethode aus. irgendwie finde ich da nichts, was ich verwenden kann.

Grüße

Peer

[Bernd1967]

@peschu sagte:

Wie sieht die Scriptmethode aus. irgendwie finde ich da nichts, was ich verwenden kann.

Grüße

Peer

Hier das Script was ich getestet hatte.

[nograx]

@peschu Ich habe bei Zendure noch mal nachgehakt.
@bernd1967 Ich kann mir das nicht vorstellen, das sind auch 2 verschiedene Probleme denke ich. Der SF 800 Pro 2 wird nicht per deviceList beim Api Punkt ausgegeben, ich gehe davon aus das man da vergessen hat den mit in eine Liste aufzunehmen welche Geräte da gepuplished werden dürfen.

[peschu]

Hallo,

das Script funktioniert auf Anhieb. Meine gute Laune ist gerettet. Jetzt kann ich damit weiter arbeiten.

Vielen Dank

[maxclaudi]

@peschu sagte:

Hallo,

das Script funktioniert auf Anhieb. Meine gute Laune ist gerettet. Jetzt kann ich damit weiter arbeiten.

Vielen Dank

Freut mich sehr, dass es hilft!

Für alle, die ebenfalls die neuen Zendure-Generationen (2025/2026) nutzen, für die es aktuell noch keine native Adapter-Unterstützung gibt:

Ich habe ein umfassendes Update (02.05.2026) veröffentlicht.
Das Skript wurde komplett neu überarbeitet und optimiert.

Es funktioniert sofort mit allen neuen Zendure-Geräten (2025/2026) mit integriertem Webserver.
Nur die IP wird benötigt; es sind keine zusätzlichen API-Keys oder Authentifizierungen erforderlich.

• Parallelbetrieb: Cloud und App können parallel weitergenutzt werden (bei deaktiviertem HEMS).
• Lokal: Funktioniert auch komplett ohne Cloud und ohne App (nur die IP wird benötigt).

(In memory of Daisy 02.05.24 – miss you.)

Den Thread und Script findet ihr hier:
Zendure-Geräte Webserver: Steuerung über das zenSDK (HTTP)

[JackDaniel]

(In memory of Daisy 02.05.24 – miss you.) wow, hänge mich unbekannter weise an

[Snooper166]

Hallo,
bin neu mit einer 800 Pro und dem Adapter untwegs. Hab eine fast 0 Einspeisung hinbekommen mit dem Zendure Automation Adapter.. klappt soweit super.
Nun scheitere ich aber an einer vermeintlich einfachen Aufgabe.
Wenn das E-Auto eingesteckt ist möchte ich, dass die 800 Pro direkt den Sonnenstrom von ihren PV Panels ins Haus einspeist (wird ja dann vom E-Auto konsumiert). Der Akku soll dabei einfach so bleiben wie er gerade ist.
Dazu hab ich dann den Automation Adapter deaktiviert, funktioniert auch top ... aber die 800 Pro fällt dann in den Tiefschlaft. Die PV Erträge wandern nirgendwo hin.
Alle Parameter die dazu vorgeschlagen wurden zu setzen funktionieren nicht..
Am einleuchtensten war zuletzt die Idee
.control.setDeviceAutomationInOutLimit --> 800 (Alles raus)...
.control.dischargeLimit --> 100% (Akku bleibt voll)
Das scheitert aber daran das das dischargeLimit sich nicht ändern lässt.
Hat einer Eine Idee von euch?

Danke

Update: Neustart hat leider nicht geholfen :(

[Felli]

@Snooper166 sagte:

Hat einer Eine Idee von euch?

Also die einzige Idee, die ich hätte, heißt ByPass - True! Wenn Du meine Nulleinspeisung im Objektbaum ausmachst, stellt die setDeviceAutomationInOutLimit auf 0 um und der Solarflow beendet seine Arbeit.

Wenn Du nun den ByPass anmachst, sollte alles von den Modulen ins Haus gehen, was gerade reinkommt (max 800W). Da ich einen reinen AC-Speicher habe, war ByPass kein Thema für mich und der Adapter ist halt eine Nulleinspeisung.

Kann man bei den neuen HUB´s nicht den ByPass wie früher auf Auto schalten? Das könnte tatsächlich funktionieren. Dann brauchst Du nur ein kleines Hilfscript, was bei .passMode true den zendure-automation.0.control.enabled auf false stellt und wenn ByPass wieder auf false eben zurück. Das sollte so klappen denke ich.

[Snooper166]

@Felli sagte:

@Snooper166 sagte:

Hat einer Eine Idee von euch?

Also die einzige Idee, die ich hätte, heißt ByPass - True! Wenn Du meine Nulleinspeisung im Objektbaum ausmachst, stellt die setDeviceAutomationInOutLimit auf 0 um und der Solarflow beendet seine Arbeit.

Wenn Du nun den ByPass anmachst, sollte alles von den Modulen ins Haus gehen, was gerade reinkommt (max 800W). Da ich einen reinen AC-Speicher habe, war ByPass kein Thema für mich und der Adapter ist halt eine Nulleinspeisung.

Kann man bei den neuen HUB´s nicht den ByPass wie früher auf Auto schalten? Das könnte tatsächlich funktionieren. Dann brauchst Du nur ein kleines Hilfscript, was bei .passMode true den zendure-automation.0.control.enabled auf false stellt und wenn ByPass wieder auf false eben zurück. Das sollte so klappen denke ich.

Danke dir, den Passmode hab ich bisher noch nicht als Objekt direkt gesehen - er hat "Automatic", "Always on", "Always off".
Dann würde ich den morgen einfach mal auf "Always On" setzen - mal schaun was passiert.
Alternativ hab ich nun ein Script gebaut das den Output immer auf den PV Ertrag setzt, alle paar sekunden - aber das mit den Bypass wäre natürlich besser wenn das geht.

[Felli]

@Snooper166 sagte:

"Automatic"

Automatic wäre hier zu empfehlen, dann macht der HUB das alleine. Sobald Akku voll, geht er in den ByPass und Abends ab einem gewissen Wert, schaltet er wieder zurück. Schalt den besser nicht einfach so um. Bei den alten HUB´s kam da in der App damals auch immer eine Meldung das dies Schaden am Relais verursachen kann. Da Zendure an den Relais, vermutlich nichts geändert hat, besser nicht machen. Automatic sollte gut gehen. Schalte dann aber die Nulleinspeisung also meine Reglung ab, sonst sendet der das Gerät sinnlos zu und das kann dann sogar Probleme machen vermute ich.

[Snooper166]

@Felli sagte:

@Snooper166 sagte:

"Automatic"

Automatic wäre hier zu empfehlen, dann macht der HUB das alleine. Sobald Akku voll, geht er in den ByPass und Abends ab einem gewissen Wert, schaltet er wieder zurück. Schalt den besser nicht einfach so um. Bei den alten HUB´s kam da in der App damals auch immer eine Meldung das dies Schaden am Relais verursachen kann. Da Zendure an den Relais, vermutlich nichts geändert hat, besser nicht machen. Automatic sollte gut gehen. Schalte dann aber die Nulleinspeisung also meine Reglung ab, sonst sendet der das Gerät sinnlos zu und das kann dann sogar Probleme machen vermute ich.

Also ich hab den heute mal Auf "2" Setzen lassen - also Always On. Das hat nix gebracht - da hat er wilde sachen gemacht. Auf Automatic (0) ist er auch beim "Automation" modus ..
Aber leider hab ich da beobachtet das wenn ich den auf Automatic (0) Und Automation --> (Enabled) hab, dann verpufft eben der PV wenn der Akku voll ist.
Ist das bei euch anders?

[Felli]

@Snooper166 sagte:

Ist das bei euch anders?

Du darfst hier die Themen nicht vermischen bitte. Das hat absolut nichts mit Peters (noGrax) Adapter zu tun, schreib mir gerne eine PM, dann versuche ich es dir zu erklären.

Kurz und knapp, wenn du bei vollem Akku keine Nulleinspeisung willst, muss man alle Regelungen in der Richtung abschalten. Dann sollte sich ein ByPass auch so verhalten wie er es sollte und zwar alles einspeisen, was denn gerade vom Dach kommt.

Über das exakte Verhalten des ByPass bei den HUBs der neuen Generation, kann ich nichts sagen, besitze keinen. Wenn Du da konkrete Fragen hast, eventuell mal im Zendurefoum fragen. Da sollten genug dabei sein, die sich damit besser auskennen als ich.

[lesiflo]

@snooper166: Ich habe die komplette Laderegelung für's eAuto in evcc ausgelagert. Da kannst du z.B. festlegen was priorisiert werden soll. War für mich wesentlich einfacher gewesen als das ganze noch in mein Script einzubauen.

[lesiflo]

@maxclaudi: Hast du eigentlich in deinem Script sowas wie eine Pulsladerregelung drin? Damit meine ich das temporäre deaktivieren beim Laden oder runterregeln bei Entladen wenn z.B. ein eHerd an ist. Da pulsiert die Leistung ja ständig. Macht vor allem Sinn wenn die restliche PV Leistung noch ausreicht um die Speicher zu laden.

So was hier z.B.

Ich hab das für's Laden z.B. so gelöst:

// Globale Variablen für Puls-Erkennung
let pulsCounter = 0;
let herdSperreBis = 0;
let lastEVU = 0;
let lastPulseZeit = 0;

  // Erkennung pulsierende Last
    const herdAktiv = erkennePulsierendeLast(daten.evuLeistung);
    if (herdAktiv) {
        ladeStartZeit = null;
        entladeStartZeit = null;
    }

const ladeBedingung = !herdAktiv && (leistungAkkus < -ladenStartSchwelle && speicherMinSOC < socMax);

function erkennePulsierendeLast(aktuellerEVU) {

    const jetzt = Date.now();

    // Änderung zur letzten Messung
    const diff = Math.abs(aktuellerEVU - lastEVU);

    // Starken Sprung erkannt
    if (diff > 700) {
        // Wenn letzter Puls länger her → neu beginnen
        if (jetzt - lastPulseZeit > 45000) {
            pulsCounter = 0;
        }
        pulsCounter++;
        lastPulseZeit = jetzt;
        log(`Puls erkannt: ${diff}W -> Counter ${pulsCounter}`);
    }

    // Pulsierung
    if (pulsCounter >= 3) {
        herdSperreBis = jetzt + 60000;
        visLog('🍳 Pulsierende Last erkannt → Speicher pausiert (60s)', 'warn');
        pulsCounter = 0;
    }

    lastEVU = aktuellerEVU;

    return jetzt < herdSperreBis;
}

Für's Entladen gibt es zwei Varianten, ganz sperren oder die Rampe weniger aggressiv.

  // --- Konfiguration für 5s Intervall ---
            let MAX_STEIGERUNG   = 1000; // Max Watt mehr pro 5 Sek
            let MAX_SENKUNG      = 1500; // Max Watt weniger pro 5 Sek
            let FAKTOR_GLAETTUNG = 0.75; // Etwas aggressiver: 75% neu, 25% alt
            let TOTZONE          = 10;   // Ignoriere Änderungen unter 10W

            if (herdAktiv) {
                //zielLeistung = 0;
                //lastEinstellungGesamt = 0;
                //visLog('🍳 Herd aktiv → Speicher pausiert', 'warn');
                MAX_STEIGERUNG   = 150;
                MAX_SENKUNG      = 300;
                FAKTOR_GLAETTUNG = 0.35;
                TOTZONE          = 80;
            }

[maxclaudi]

@lesiflo sagte:

@maxclaudi: Hast du eigentlich in deinem Script sowas wie eine Pulsladerregelung drin? Damit meine ich das temporäre deaktivieren beim Laden oder runterregeln bei Entladen wenn z.B. ein eHerd an ist. Da pulsiert die Leistung ja ständig. Macht vor allem Sinn wenn die restliche PV Leistung noch ausreicht um die Speicher zu laden.

Ich hab das für's Laden z.B. so gelöst:

// Globale Variablen für Puls-Erkennung
let pulsCounter = 0;
let herdSperreBis = 0;
let lastEVU = 0;
let lastPulseZeit = 0;

  // Erkennung pulsierende Last
    const herdAktiv = erkennePulsierendeLast(daten.evuLeistung);
    if (herdAktiv) {
        ladeStartZeit = null;
        entladeStartZeit = null;
    }

const ladeBedingung = !herdAktiv && (leistungAkkus < -ladenStartSchwelle && speicherMinSOC < socMax);

function erkennePulsierendeLast(aktuellerEVU) {

    const jetzt = Date.now();

    // Änderung zur letzten Messung
    const diff = Math.abs(aktuellerEVU - lastEVU);

    // Starken Sprung erkannt
    if (diff > 700) {
        // Wenn letzter Puls länger her → neu beginnen
        if (jetzt - lastPulseZeit > 45000) {
            pulsCounter = 0;
        }
        pulsCounter++;
        lastPulseZeit = jetzt;
        log(`Puls erkannt: ${diff}W -> Counter ${pulsCounter}`);
    }

    // Pulsierung
    if (pulsCounter >= 3) {
        herdSperreBis = jetzt + 60000;
        visLog('🍳 Pulsierende Last erkannt → Speicher pausiert (60s)', 'warn');
        pulsCounter = 0;
    }

    lastEVU = aktuellerEVU;

    return jetzt < herdSperreBis;
}

Für's Entladen gibt es zwei Varianten, ganz sperren oder die Rampe weniger aggressiv.

  // --- Konfiguration für 5s Intervall ---
            let MAX_STEIGERUNG   = 1000; // Max Watt mehr pro 5 Sek
            let MAX_SENKUNG      = 1500; // Max Watt weniger pro 5 Sek
            let FAKTOR_GLAETTUNG = 0.75; // Etwas aggressiver: 75% neu, 25% alt
            let TOTZONE          = 10;   // Ignoriere Änderungen unter 10W

            if (herdAktiv) {
                //zielLeistung = 0;
                //lastEinstellungGesamt = 0;
                //visLog('🍳 Herd aktiv → Speicher pausiert', 'warn');
                MAX_STEIGERUNG   = 150;
                MAX_SENKUNG      = 300;
                FAKTOR_GLAETTUNG = 0.35;
                TOTZONE          = 80;
            }

@lesiflo
setze das konservativer um und reagiere auf häufige Lastwechsel durch eine Anpassung meiner Regelstrategie.

Meine Vorgehensweise (KISS):
priorisiere die Lebensdauer der Hardware und die Systemruhe vor einer theoretischen 100%igen Nulleinspeisung.

Wenn bei mir hohe pulsierende Last festgestellt wird, wird dabei der vorübergehende Maximalwert ermittelt.
Zum Maximalwert inkrementiere ich einen Puffer von x W.
Es wird ein neues Limit gesetzt (Maximalwert+Puffer) für eine Mindestzeit.

Bei mir
Mindestzeit: hardwarebedingt 2 min.
Puffer (Lastspitzen): 200W
Puffer (normaler Zyklus): 50~60W bei kurzen, kleineren Impulsen.

Erst dann wird neu reagiert.
Schneller regele ich nicht und das hat seine Gründe - u. a. Hardware-Schonung, realistisches Schaltvermögen etc.

Angenommen 1 kWh kostet 0,30 Euro.
Wenn man kocht, dann dauert das wie lang?
Eine Mikrowelle ist wie lange an?
Eine Waschmaschine läuft wie lange?
Ein Wasserkocher?
etc.

Angenommen Herd ca. 30 min - 1h.
Für 0,30 Euro muss nicht die teure Hardware gestresst werden und sinnfrei im Sekundentakt jedem einzelnen Watt hinterher gejagt werden.
Auch ein stetiges nachregeln in kürzester Zeit kann die Hardware nicht wirklich real umsetzen.
Jedenfalls nicht ohne, dass es auf die Lebensdauer des Geräts geht und ohne merklichen Unterschied am Zählerstand.

Dann lieber höhere Hysterese mit längerem Zeitintervall.
Eher etwas mehr einspeisen und wenig/kein Bezug oder eher etwas Bezug nahe 0.

Wenn ein Limit gesetzt wird, sollte es meiner Meinung nach großzügiger sein und lieber länger gehalten werden, statt zu häufig nach zu regeln.

Bei 200 W zu viel Einspeisung für z.B. 15 Minuten werden gerade einmal 0,05 kWh (ca. 1,5 Cent) verschenkt.
Das ist ein sehr geringer Preis für die gewonnene Hardware-Schonung.

Schnelle Regelschleifen neigen bei Latenzen zum Aufschwingen.
Mein Intervall beruhigt das System und sorgt für eine saubere Lastkurve.

Das ist nur meine Einschätzung aus elektrotechnischer Sicht und Vorgehensweise, nicht mehr.