Monatsrückblick Juli / August 2026 ist online!

[porty]

!!! EDIT !!!
Scheinbar funktioniert es doch, nur wird bei mir das Umschalten zwischen Laden/Entladen nicht in der App angezeigt.
Ich logge die Umschaltmomente sowie das Laden/Entladen nun mal in in der SQL Datenbank und vergleiche das ganze.

---

Erstmal vielen Dank für das Script @schimi !
Habe Gestern meine 2400AC mit bekommen und direkt mit mit dem Script in Betrieb genommen.
Die Ladereglung funktioniert wunderbar, auch die 0-punkt Entladung.
Was jedoch nicht klappt ist das automatische umschalten zwischen Input / Output Mode.

Ich habe versuchsweise den Mode am Abend von Hand in der App umgeschaltet, das geht natürlich und das Script regelt dann auch schön.

Warum das der AcMode jedoch nicht automatisch umgeschaltet wird habe ich noch nicht raus gefunden.
Hat da vielleicht jemand eine Idee?

// --- ZENDURE MQTT BASISDATEN ---
const MQTT_BASE_PATH = "mqtt.0.Zendure"; 
const DEVICE_ID      = "HOxxxxxxxxxxxxx8";
--------
netz: "smartmeter.0.1-0:16_7_0__255.value",

[Schimi]

@porty hast du HEMS und sowas deaktiviert? nicht das was dazwischen funkt....

auch die Device ID eineggeben? (Muss ja sonst würde die regelung nicht funktionieren....

vielleicht auch mal, in der app (MQTT AUS) und einmal den Netzeingangs und Ausgangs-modus auswählen und jeweils dort 0 eingeben

Auch vielleicht den Debug modus aktivieren (vielleicht reicht ja erstmal Info), ob da was bei raus kommt...

Ich nutze inzwischen einen leichten bezug, finde die Regelung dann etwas besser:

TARGET_W: 20, // Zielwert am Zähler (20 = leichter Bezug).

Ich mache gleich mal oben meine aktuellste version rein, habe ein paar kleine Optimierungen eingebaut

[porty]

Guten Morgen @schimi
wie bereits im EDIT erwähnt funktionierte es ab dem nächsten Morgen doch.
HEMS war deaktivert und auch die anderen Settings (SmartMode Off etc ) waren so eingestellt wie du es mal in irgend einem Post mal erwähnt hattest.
Device ID etc war natürlich drin, sieht man in meinem Bild schlecht da schwarz auf schwarz ausgeblendet :)
wir waren unterwegs an dem Tag und ich hatte es nur in der App gesehen das der Modus auf "Standby" stand obwohl wir zu dem Zeitpunkt einen Verbrauch von ca. 450W hatten.
Habe dann in der App auf "Netzausgangsmodus" gestellt. Am nächsten Morgen dann das Script gestoppt, den Modus von Hand über den MQTT-Datenpunkt geändert was auch funktionierte.

Was ich nicht drin hatte da es als "optional" eingetragen war, war der Datenpunkt
"evccModus: "0_userdata.0.zendure.EVCC_Modus",
diesen hatte ich noch hinzugefügt.

Danach mal das Script von @maxclaudi gestartet und den Modus darüber ungestellt, auch erfolgreich.

Gestern hat es mit deinem Script jedenfalls wunderbar funkioniert, wobei ich auch schon überlegt habe nich auf 0 sondern eher auf Minimalbezug zu stellen.
Habe den Aktuellen Stromverbrauch mal auf meine Ulanzi TC001 gelegt und das springt nicht schlecht :)

Danke fürs Update von deinem Script, schaue ich mir nachher Zuhause mal an.

[Schimi]

Ich habe wieder etwas gebastelt.... (siehe ersten Post, ganz oben)

Gerne für eigene Projekte nutzen und/oder entsprechend umbauen

[maxclaudi]

@Schimi sagte:
Ich habe wieder etwas gebastelt.... (siehe ersten Post, ganz oben)

Sieht beim Überfliegen auf den ersten Blick inhaltlich solide aus. Das REGEL_INTERVALL_MS von 2000 ms finde ich zu hochfrequent. Ansonsten aber ganz ok.

[Schimi]

das Thema hatte ich schon mit jemand anderen... Habe such höhere werte getestet, aber aus irgend einem grund passt das bei mir tatsächlich am besten.... vielleicjt ist es auch nur ein zufall.

[porty]

mal wieder: Danke fürs updaten.
Gibt es eigentlich Infos bezüglich der neuen Firmware? Ich habe das Firmwareupdate aktuell noch nicht durchgeführt.

[Schimi]

Ich habe die neuste (müsste 2.0.1 sein) und keine Probleme

[odysseus]

Ich hatte mit der 2.0.1 weiterhin Probleme mit der Verbindung zwischen meinem Raspi und meiner 2400AC+ (ca. alle 2 Tage Verbindungsabbrüche und dann musste der Speicher resettet werden).
Nach dem Einspielen der neuen Version 2.0.2 auf der 2400AC+ läuft es nun seit 4 Tagen stabil.
Sehr schön, Daumen drücken, dass es so bleibt!

[Schimi]

Ich habe hier einen 2400 AC (ohne +).. da gibt es (noch?) keine 2.0.1...

[TG]

Hallo zusammen. Ich habe das aktuelle Skript auch mal zum testen bei mir laufen lassen (ohne EVCC, nur mit dem Ziel PV-Strom Speichern und wenn benötigt ausgeben). Aber mit dem Ergebnis bin ich bei mir irgendwie noch nicht so ganz zufrieden. Der Stromverbrauch/ Bezug schwank zwar immer so um die 0 herum aber hat hier und da schon mal einen Peak und Wippen drin. Bisher hatte ich die Batterie Lade/Entlade Steuerung immer über das "interne" HEMS von Zendure laufen lassen. Das war im vergleich zu dem Skript deutlich öfter und näher an der wirklichen 0 Einspeisung dran.
Ist das bei euch auch so?
Ich verstehe auch die Idee hinter dem KP / KI Anteil noch nicht so ganz. Warum macht man keine direkte Steuerung (z.B. KP 1.0) damit bin ich doch schneller und mit viel weniger Steuerhandlungen an meinem "Ziel" oder liege ich da falsch? Mit diesem "langsamen Regeln" Verschenke / bzw. Kaufe ich doch am Ende des Tages deutlich mehr Strom ein!?
Mal so als Vergleichswert: bei 24h Steuerung durch HEMS habe ich an einem Tag gerade mal 302Wh durch Schwankungen und Trägheitsverluste vom Stromanbieter gekauft. Habt ihr ähnliche Vergleichswerte mit dem Script erreicht?
Perspektivisch würde ich auch gern auf eine Interne Steuerung durch MQTT und so ein Skript umsteigen, ich schwanke aber aktuell noch, da ich bisher mit noch keinem Skript ein annähernd gutes Steuerergebnis erreichen konnte als mit HEMS oder ZENKI von Zendure selbst :(

[lesiflo]

PI-Regelung ist nützlich wenn du pulsierende Lasten wie z.B. einen eHerd oder Ofen hast. Da pulsiert die Last innerhalb kurzer Zeit von 0 auf 2000 W und schnell wieder runter. Solange man eine recht "einfache" Infrastruktur hat läuft HEMS/Zenki eigentlich recht gut, aber sobald es anspruchsvoller wird "spinnt" das System, zumindest was ich festgestellt habe. Bei mir laufen 3 Zendure Geräte mit PV und ohne, eine große PV (die auch nach Zendure läd), eAuto und Wärmepumpe. Da kommt die Zendure Regelung schnell mal durcheinander. Ausserdem kann man in HEMS die Geräte nicht sperren wenn das eAuto läuft, auch nicht mit evcc.

[Schimi]

Gut – lesiflo hat den „warum überhaupt extern regeln"-Teil schon abgedeckt, das lasse ich raus. Kürzere Fassung, die nur noch das ergänzt, was noch offen ist:

---

Hallo TG,

lesiflos Punkt kann ich unterschreiben – die PI-Regelung zahlt sich genau bei den pulsierenden Lasten aus. Ich ergänze nur die zwei Sachen, die noch offen sind.

Zum Schwanken um die Null

Ich habe hier mal einen Produktivtag mit 4010 Regelzyklen (2-s-Takt) ausgewertet. Eingeschwungen, über 2695 Zyklen:

Netz-Mittelwert  +11 W     Median  +5 W     Streuung σ  77 W

Und dazu das Eigenrauschen meines Shelly 3EM in Ruhe, gemessen als Sprung zwischen zwei aufeinanderfolgenden unterschiedlichen Messwerten:

Median 28 W     p90 76 W     p99 136 W

Die Streuung der Regelung entspricht damit exakt dem Rauschen des Messgeräts. Ein guter Teil dessen, was du als Zappeln siehst, ist gar nicht die Regelung, sondern die Messung – besser als der eigene Sensor kann kein Regler werden. Schau als erstes, wie ruhig dein Zähler in einer Phase ganz ohne Lastwechsel liegt. Das setzt die Untergrenze für alles Weitere.

Dass das interne HEMS näher an der Null wirkt, hat auch einen banalen Grund: es sitzt auf dem Gerät und regelt seinen Wechselrichter direkt. Bei mir läuft der Weg Zähler → MQTT → ioBroker → Skript → MQTT → Zendure, das sind gemessen rund 2,7 s Totzeit. Die holt kein externer Regler auf.

Zum KP = 1.0

Die Intuition trügt hier gleich doppelt.

Ein reiner P-Regler erreicht die Null grundsätzlich nie. Bei Streckenverstärkung 1 bleibt im Beharrungszustand Netz = Störgröße / (1 + KP) stehen – mit KP = 1,0 also die halbe Störgröße. 1000 W Lastsprung heißt 500 W Dauerabweichung. Genau dafür ist der I-Anteil da. Bei mir macht der auch die Hauptarbeit: in 88 % der Zyklen ist er größer als der P-Anteil (Median I = 448 W gegen P = 40 W).

Falls du mit „direkte Steuerung" eher meinst, den gemessenen Netzwert 1:1 auf die Batterieleistung aufzuschlagen – das ist mathematisch ein reiner Integrator mit Verstärkung 1 pro Zyklus. Der erreicht zwar die Null, korrigiert aber den vollen Fehler, bevor die Wirkung der vorherigen Korrektur am Zähler ankommt. Bei 2–3 s Totzeit legt er im nächsten Zyklus nochmal voll nach, schießt über, dreht um. Das ist genau das Wippen, das du loswerden willst. Mein KI von 0,08 bei 2 s Takt sind rund 16 % Fehlerkorrektur pro Zyklus über das Integral – bewusst langsam genug für die Totzeit.

Weniger Stellhandlungen bekämst du damit übrigens auch nicht: deren Zahl bestimmt der Regeltakt, nicht die Verstärkung.

Was bei mir wirklich geholfen hat

Mein Deadband stand auf 15 W und lag damit unter dem Median-Rauschen von 28 W – der Regler ist also permanent dem Sensorrauschen hinterhergefahren, über die Hälfte aller Stellbefehle waren Bewegungen ≤ 25 W. Wenn du weniger Stellhandlungen willst, ist das der Hebel: Deadband ungefähr auf den Rauschpegel deines Zählers. Nur nicht zu groß, sonst bleibt eine Dauerabweichung in dieser Höhe stehen.

Und das Wippen speziell um den Nulldurchgang ist meistens der AC-Moduswechsel (Input ↔ Output), der ist bei der 2400 AC nicht instantan. Ich habe dafür eine Hysterese (Wechsel erst ab 100 W Anforderung) plus 30 s Sperrzeit danach. An einem realen Tag hat das 56 von 86 angeforderten Wechseln unterdrückt – blieben 30 echte übrig. Ohne so etwas schaltet das Gerät bei jeder Wolke hin und her.