Monatsrückblick Oktober 2026 ist online!

[nograx]

@lesiflo bis was für eine Leistung macht das Sinn? Also ab wann soll er wieder aus dem Akku einspeisen?

[lesiflo]

@nograx sagte:

@lesiflo bis was für eine Leistung macht das Sinn? Also ab wann soll er wieder aus dem Akku einspeisen?

Ich würde das am zendure-solarflow.0.adapterAutomation.setPoint (Sollwert Netzeinspeisung) festmachen.

Mein Script funktioniert aktuell so:

Das Skript regelt selbst keine Leistung. Es setzt nur Freigaben, und die eigentliche Regelung übernimmt der Zendure-Adapter. Dass die PV zuerst ins Haus geht, kommt also aus dem Zusammenspiel von Adapter und Hyper.

Wer was macht

• Der Adapter regelt auf 0 W am Netzanschluss und gibt jedem Hyper vor, wie viel er ins Haus liefern soll.
• Jeder Hyper deckt diese Vorgabe zuerst mit seiner eigenen PV. Nur die Differenz kommt aus seinem Akku, und überschüssige PV lädt den Akku. Das macht der Hyper selbst; im Skript steht dafür keine Zeile.

Normalbetrieb: Entladen ist frei

Das Skript schaltet bei allen drei Hypern feedInSolarOnly aus, setzt das normale Entladelimit (10 %) und lässt die Automation an. Ab da entscheidet allein der Adapter.

Entladesperre (Zeilen 344–395)

Die Sperre greift in zwei Fällen:

• Der Optimizer verbietet das Entladen (Entladen_Freigabe = false).
• Das Auto lädt mit mindestens 500 W und der Gesamt-SOC liegt nicht über bufferSoc.

Während der Sperre gilt:

• Hyper 1 und 2: feedInSolarOnly = true. Die aktuelle PV geht weiter nach Bedarf ins Haus, der Rest in den Akku, und der Akku wird nicht entladen. Fehlt dieser Datenpunkt, hebt das Skript ersatzweise das Entladelimit auf das Ladelimit an.
• Hyper 3 (ohne PV): Das Entladelimit wird auf das Ladelimit angehoben. Die Automation bleibt nur an, wenn mehr als 100 W ins Netz fließen, Hyper 3 also Überschuss aufnehmen kann.

Ist das letzte Signal des Optimizers älter als 25 Minuten, ignoriert das Skript seine Freigaben und lässt das Entladen zu.

[nograx]

Ich habe jetzt erstmal eine Version veröffentlicht die bei Solar >50W und feedInSolarOnly = true nur maximal die aktuelle Solarleistung einspeisen darf. Unter 50W darf auch der Akku hinzugezogen werden.

Das am setPoint festzumachen finde ich noch schwierig, denn wenn jmd. explizit einen negativen setPoint wählt wirds schwierig.

Ich denke da noch mal drüber nach, eventl. würde ja ein selbst konfigurierbarer Wert dafür Sinn machen.

[lesiflo]

Ok, probiere ich morgen mal aus

[lesiflo]

lesiflo sagte:

Ok, probiere ich morgen mal aus

Moin,
ich Nachgang habe ich mir überlegt, das das mit dem Einspeisen aus dem Akku bei PV <50 W bei aktiven feedInSolarOnly doch so keine gute Idee war. Stichwort Endladesperre, wenn das eAuto geladen wird sollte man eigentlich vermeiden das Strom aus dem Akkus gezogen wird, es sein denn man lässt es ausdrücklich zu.
Mit alten Version brauchte man nur feedInSolarOnly auf true setzen, dann ging nur PV ins Netz. Dazu bräuchte man jetzt einen zusätzlichen Schalter "Endladesperre".

Ich bleibe daher erstmal auf der Version 6.1.1.

[darkblu]

Hallo @nograx , ich hab da mal eine "doofe" Frage,
aktuell habe ich noch Adapter Version 5.3.1 installiert und bekomme 6.1.3 angeboten.
Wenn ich auf 6.x update und nichts von deinen neuen Einstellungen aktiviere, ändert sich bei mir doch auch nichts, oder ?
Ich hatte mir mit Chat GPT ein Blockly gebaut, welches für mich sehr gut funktioniert, daran würde beim update doch auch nichts geändert ?

Und noch eine Frage zur AC und Master Firmware, die habe ich auch nie aktualisiert seit kauf vor ein paar Monaten.
Die sind aktuell auf (AC) 3.1.2 und (Master) auf 2.1.30.
Kann ich die eigentlich mal upgraden, oder soll ich die so lassen ?

Ein update der iOS App, kann ich doch machen ?

Ok, sind dann doch mehr als eine "doofe" Frage geworden.

Weil ich mich damit so gar nicht auskenne, lieber mal nachgefragt.
Ich habe einen Hyper 2000 mit einem AB 2000 X Akku.
Das Ganze wird ausschließlich mit meinem Blockly gesteuert.
Also kein HEMS, ZenWave oder so aktiviert.

[nograx]

Adapter Update kannst du problemlos machen. Die neue Automatisierung ist komplett optional und auch nicht sichtbar wenn du sie nicht explizit in den Einstellungen aktivierst.

Firmware Update hängt aktuell davon ab ob du in der Cloud unterwegs bist oder das Gerät lokal per MQTT laufen lässt.

[darkblu]

Danke erstmal, es läuft über „Authorization Auth Key“

[nograx]

@darkblu dann kannst du das Firmware Update durchaus installieren. Eigentlich sollte von Zendure längst ein weiteres (.48) verfügbar sein. Das hängt aber aktuell wohl noch in der Beta Schleife fest.

[Murphy 0]

Die Master Firmware v2.1.48 bekommt man auf Nachfrage beim Support freigeschaltet. Als Begründung kann man Probleme mit der offiziellen HA Integration angeben.
Damit ist dann die SSL Verschlüsselung Geschichte.

[SpeedyBlade]

hallo
ich verwende auch diesen adapter, aber ich kann über den adapter überhaupt nichts schalten am zendure, obwohl alle geräte gefunden werden und auch die statusse korrekt dargestellt werden im iobroker

[nograx]

@SpeedyBlade was genau möchtest du denn Steuern? Wird bei dir über Zendure noch gesteuert?

[SpeedyBlade]

ich möchte das system lokal steuern und nicht mehr über hems
denn diese automatische kalibierung am abend nervt

[nograx]

@SpeedyBlade Dann solltest du im ersten Schritt das HEMS / Automatisierung in der offiziellen App abschalten. Sonst geht keine Steuerung. Dann kannst du wenn du z.B. deinen Shelly (oder welchem Smart Meter du auch benutzt) im ioBroker siehst auch die offizielle Automatisierung vom Adapter nutzen. Die läuft jetzt schon bei knapp 30 Personen sehr stabil.

Einrichtung grob ist die Automatisierung im Adapter einschalten, Smart Meter Datenpunkt auswählen und dann im Objektbaum die Automatisierung aktivieren. Ausführlicher wird es in der Readme beschrieben.

Wenn du uns noch mehr Infos gibst können wir dir hier auch einiges besser helfen.

[SpeedyBlade]

@nograx
HEMS ist mittlerweile deaktiviert 👍🏼
Nutze es nur mehr lokal
Habe die Automation aus dem Adapter aktivert... Besten Dank
Läuft soweit ganz gut, allerdings habe ich noch Anliegen hierzu.
Ich habe drei solarflow 2400 mit ab3000x im Einsatz. Die erzeugende Energie erfolgt über eine separate komplette pv-anlage am Dach.
Somit sind die AC Speicher auch wirklich reine AC Speicher.
Was mir gestern aufgefallen ist, dass ein Speicher den anderen geladen hat, obwohl keine Energie vom Dach kam.
Hier wäre es gut wenn man noch folgendes in die Automation mit einfügen könnte.
Man bräuchte den Wert der pV Anlage der aktuell erzeugt wird, ist dieser kleiner Wert X, dann soll AC Ladung gesperrt werden. Ist der Wert der pv-anlage über Wert X, dann soll AC Ladung wieder aktiv werden. Beides soll jedoch mit einer Zeit hinterlegt werden können. Z.b mindestens 1,2,3,5 Minuten oder ähnliches.
Ich hoffe das war nun verständlich erklärt 😬

[
    {
        "id": "zendure_pv_trigger_in",
        "type": "ioBroker in",
        "z": "tab_zendure_automation",
        "name": "PV-Gesamtwert einlesen",
        "topic": "zendure-solarflow.0.adapterAutomation.totalSolarPower",
        "payloadType": "value",
        "onlyack": true,
        "func": "all",
        "gap": "",
        "x": 160,
        "y": 140,
        "wires": [
            [
                "zendure_logic_function"
            ]
        ]
    },
    {
        "id": "zendure_logic_function",
        "type": "function",
        "z": "tab_zendure_automation",
        "name": "60s Timer & Hysterese",
        "func": "let aktuellePV = msg.payload;\n\n// Zustände aus dem Node-Speicher holen oder initialisieren\nlet statusAktuell = context.get(\"statusAktuell\") || false; // true = Laden erlaubt, false = gesperrt\nlet timerTyp = context.get(\"timerTyp\") || null;           // \"ON\" oder \"OFF\"\nlet timerStart = context.get(\"timerStart\") || 0;           // Zeitstempel\n\nlet jetzt = Date.now();\nlet wartezeit = 60000; // 60 Sekunden in Millisekunden\n\n// --- FALL 1: PV ist hoch genug (Einschalten prüfen) ---\nif (aktuellePV >= 150) {\n    if (!statusAktuell) { // Wenn aktuell noch gesperrt ist\n        if (timerTyp !== \"ON\") {\n            // Start des 60s-Timers für das Einschalten\n            context.set(\"timerTyp\", \"ON\");\n            context.set(\"timerStart\", jetzt);\n        } else if (jetzt - timerStart >= wartezeit) {\n            // 60 Sekunden sind stabil abgelaufen!\n            statusAktuell = true;\n            context.set(\"statusAktuell\", statusAktuell);\n            context.set(\"timerTyp\", null); // Timer zurücksetzen\n            msg.payload = true;\n            return msg;\n        }\n    }\n    else {\n        // Zustand ist bereits ON, eventuellen OFF-Timer löschen\n        context.set(\"timerTyp\", null);\n    }\n}\n\n// --- FALL 2: PV ist zu niedrig (Ausschalten prüfen) ---\nelse if (aktuellePV <= 50) {\n    if (statusAktuell) { // Wenn aktuell noch Laden erlaubt ist\n        if (timerTyp !== \"OFF\") {\n            // Start des 60s-Timers für das Ausschalten\n            context.set(\"timerTyp\", \"OFF\");\n            context.set(\"timerStart\", jetzt);\n        } else if (jetzt - timerStart >= wartezeit) {\n            // 60 Sekunden sind stabil abgelaufen!\n            statusAktuell = false;\n            context.set(\"statusAktuell\", statusAktuell);\n            context.set(\"timerTyp\", null); // Timer zurücksetzen\n            msg.payload = false;\n            return msg;\n        }\n    }\n    else {\n        // Zustand ist bereits OFF, eventuellen ON-Timer löschen\n        context.set(\"timerTyp\", null);\n    }\n}\n\n// --- FALL 3: PV liegt im Hysterese-Bereich (51 - 149W) ---\nelse {\n    // Wenn der Wert dazwischen liegt, wird jeder laufende Timer abgebrochen\n    context.set(\"timerTyp\", null);\n}\n\n// Wenn die Bedingung (noch) nicht erfüllt ist, blockieren wir die Nachricht\nreturn null;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 420,
        "y": 140,
        "wires": [
            [
                "zendure_out_device_1",
                "zendure_out_device_2",
                "zendure_out_device_3"
            ]
        ]
    },
    {
        "id": "zendure_out_device_1",
        "type": "ioBroker out",
        "z": "tab_zendure_automation",
        "name": "Speicher 1: acChargingAllowed",
        "topic": "zendure-solarflow.0.[Seriennummer_A].adapterAutomation.acChargingAllowed",
        "ackval": "false",
        "autoCreate": "false",
        "stateId": "",
        "stateName": "",
        "stateType": "",
        "stateUnit": "",
        "x": 710,
        "y": 80,
        "wires": []
    },
    {
        "id": "zendure_out_device_2",
        "type": "ioBroker out",
        "z": "tab_zendure_automation",
        "name": "Speicher 2: acChargingAllowed",
        "topic": "zendure-solarflow.0.[Seriennummer_B].adapterAutomation.acChargingAllowed",
        "ackval": "false",
        "autoCreate": "false",
        "stateId": "",
        "stateName": "",
        "stateType": "",
        "stateUnit": "",
        "x": 710,
        "y": 140,
        "wires": []
    },
    {
        "id": "zendure_out_device_3",
        "type": "ioBroker out",
        "z": "tab_zendure_automation",
        "name": "Speicher 3: acChargingAllowed",
        "topic": "zendure-solarflow.0.[Seriennummer_C].adapterAutomation.acChargingAllowed",
        "ackval": "false",
        "autoCreate": "false",
        "stateId": "",
        "stateName": "",
        "stateType": "",
        "stateUnit": "",
        "x": 710,
        "y": 200,
        "wires": []
    }
]

[nograx]

@SpeedyBlade Exakt das was du da beschreibst dürfte eigentlich nicht passieren - lediglich wenn der Lade-Keep-Alive gehalten wird (5 Minuten) kann es temporär dazu kommen ODER wenn deine Verbindung schlecht ist und das Kommando zur Leistungsreduktion beim Gerät nicht sauber ankommt (da bitte dann mal setDeviceAutomationInOutLimit mit den aktuellen Werten vergleichen). Letzteres sollte aber auch automatisch innerhalb einer Minute korrigiert werden in dem das letzte Kommando noch einmal geschickt wird.

Es wäre super wenn du mir dazu den Adapter in den Debug Modus schaltest und dann ein Log zukommen lassen könntest sofern das noch mal passiert.

[SpeedyBlade]

@nograx den Log kann ich gerne raussuchen am späteren Nachmittag.

Die Verbindung kann ich definitiv ausschließen, die ist und war immer perfekt. Access Point steht 2m daneben und hatte hier noch nie Unterbrüche.

Wäre mein Vorschlag nicht dennoch integrierbar?
So könnte man definitiv das AC Laden sperren/freigeben?

[nograx]

@SpeedyBlade Als zusätzlich Option wäre es vermutlich ganz hilfreich. Baue ich gerne kurzfristig mit ein.

Hast du noch irgendwelche anderen Speicher im Einsatz die hier gestört haben könnten?

[SpeedyBlade]

@nograx nein, keine weiteren Speicher im Einsatz

Log ist leider nicht mehr verfügbar von gestern.
hab jetzt aber den debug aktiviert vom adapter, lass es jetzt erstmal einige stunden laufen, dann sende ich es dir morgen/übermorgen. Aktuell konnte ich keinen Fehler feststellen, aber ich schaue auch nicht alle paar Minuten auf die App bzw. die Daten ;)

besten Dank für den Einsatz 👍

Wenn ich sonst noch was testen soll, lass es mich wissen.
Bei mir sind die vollen 3x2400W im Einsatz und freigegeben von Zendure, falls es da nen Test oder Infos braucht

was passiert eigentlich, wenn der ioBroker oder der Adapter offline geht?
wird dann der Speicher weder geladen, noch entladen?

[nograx]

@SpeedyBlade In der Version 6.2.0 ist der Schalter "disableAcCharging" mit drin.

Ja wenn ioBroker offline geht funktioniert logischerweise die Steuerung nicht mehr. Wenn du zenSDK aktiviert lässt erfolgt die Steuerung lokal über dein Netzwerk, das bedeutet wenn die Zendure Cloud offline ist funktioniert es weiter. Jetzt darfst du entscheiden welche Variante dir sicherer erscheint