wichtiges UPDATE für controller 7.2.2 im stable

[Jockel_Bln]

@maxclaudi Wow, da hast du ja ordentlich was erstellt - danke fürs Teilen

Mir ist da etwas bezüglich smartMode aufgefallen.
Am Wochenende wollte ich meinen IR Lesekopf etwas nachjustieren, da ist plötzlich das komplette Gehäuse zerbröselt und er damit unbenutzbar geworden.
Ich also zum Baumarkt und habe mir als schnellen Ersatz nen EcoTracker besorgt. Da ich ein neugieriger Mensch bin habe ich ihn natürlich in der Zendure App gekoppelt und den Speicher im Eigenverbrauchsmodus laufen lassen.

Dabei habe ich folgendes beobachtet: Speicher und Tracker kommunizieren nach der Kopplung (via Cloud) lokal und die Regelung funktioniert gut und sehr schnell. Allerdings wechselt der Wert von smartMode je nach dem was gerade für ein acMode aktiv ist. Bei acMode 1 (laden) springt der smartMode auf 0 und umgekehrt. Gerade morgens und abends geschieht das natürlich ständig im Wechsel.
Es läuft nebenher kein weiteres Skript, auch deins nicht, ich frage die Werte nur per http get vom Speicher ab.

Wenn das wirklich so designt ist, wird bei smartMode=0 wirklich alles in den Flash geschrieben? Immerhin wechselt inputLimit am Tage ständig in kurzen Intervallen.
Da Zendure 10 Jahre Garantie auf die Geräte gibt, sollten sie das doch so konstruiert haben, dass der Flash bei der internen Steuerung diese Zeit überlebt.

Das wollte ich nur mal so berichten, jetzt gucke ich mir dein Skript an - ganz schön viel Stoff für einen alten Mann

[maxclaudi]

Hallo @Jockel_Bln,

zu deiner Sorge bezüglich des Flash-Speichers:
Jeder moderne Hersteller setzt bei Steuerungsgeräten heute auf Flash-Komponenten mit sogenanntem Wear-Leveling.
Dieses Verfahren sorgt dafür, dass Schreibvorgänge gleichmäßig über den gesamten Speicher (Blöcke) verteilt werden, um die Lebensdauer der Zellen drastisch zu erhöhen.

Wenn Zendure hier die üblichen Industriestandards nutzt, sollte die Lebensdauer für den "normalen" Betrieb ausreichend ausgelegt sein.
Allerdings altern Flash-Speicher bei übermäßig vielen Schreibzyklen unweigerlich.
Wenn Speicherbereiche degradieren, zeigt sich das meistens nicht durch einen Totalausfall, sondern durch sporadische, schwer zu diagnostizierende Fehler im System.

Meine goldene Regel für Skripte:
Man sollte es trotz Wear-Leveling einfach nicht übertreiben.

Genau aus diesem Grund nutzt mein Beispiel-Blockly die Hysterese und eine Zeitsperre.
Alle wichtigen Werte dafür sind in den Variablen auf die eigenen Bedürfnisse und das eigene Setup einstellbar.

Werte sollten niemals im Sekunden- oder Minutentakt unfiltriert oder in Dauerschleifen zum Zendure-System gesendet werden.
Solange man das beachtet und dem System "Ruhepausen" gönnt, ist man – denke ich – auf der sicheren Seite.

Viel Spaß beim Einlesen in das Skript – nimm Dir ruhig Zeit, es läuft Dir nicht weg! :-)

[Jockel_Bln]

@maxclaudi sagte:

Werte sollten niemals im Sekunden- oder Minutentakt unfiltriert oder in Dauerschleifen zum Zendure-System gesendet werden.
Solange man das beachtet und dem System "Ruhepausen" gönnt, ist man – denke ich – auf der sicheren Seite.

Das sehe ich ganz genau so und das lässt sich ja per externer Regelung so umsetzen.
Um so mehr wundert es mich, dass es bei der internen Regelung eben nicht so läuft. Entweder läuft da etwas anders als von extern, oder sie fahren werkseitig auf Verschleiß

[maxclaudi]

@Jockel_Bln,
es kommt vermutlich ganz darauf an, wie lange man ein System heute überhaupt noch nutzen möchte.

Ich lese in den Foren immer wieder von Amortisierung in X Jahren.
Die Leute kaufen ein Gerät und erwarten voller Vorfreude ein System, das sich nach kürzester Zeit bezahlt gemacht haben soll.
Dabei werden dann Zeiträume von mehreren Jahren oft als „kurze Zeit“ abgetan.

Am Anfang ist man dann mehr oder weniger zufrieden.
Doch nach einigen Monaten oder ein, zwei Jahren ist das System zwar noch lange nicht amortisiert, aber es gibt bereits neuere, bessere Geräte mit noch mehr Software-Features.
Die älteren Generationen profitieren davon meist gar nicht oder nur bedingt.

Ich habe – nicht nur im näheren Bekanntenkreis – beobachtet, dass viele Nutzer dann vom „Mehr-haben-wollen“-Fieber gepackt werden, ähnlich einem kleinen Goldrausch.
Vorbei sind die anfänglichen Berechnungen und das geduldige Abwarten der Amortisation.
Das eigene, eigentlich tadellos funktionierende System wird plötzlich als „altes Eisen“ degradiert.

Kurzerhand wird ein Gerät, das zuvor einige hundert Euro gekostet hat, durch ein neues Modell ersetzt – das nach nicht einmal zwei Jahren Betrieb.
Ich nehme mich da selbst ehrlich gesagt gar nicht mal aus.

Und bis zu diesem Zeitpunkt hält ein FLASH-Speicher wahrscheinlich immer locker durch.

Edit/PS: Beim krampfhaften Hinterherjagen nach jedem einzelnen Watt sollte man immer bedenken: Was kostet eine gesparte kWh – selbst bei einem angenommenen Preis von 1 Euro – im Verhältnis zu einem durchgedrehten Gerät mit defektem FLASH-Speicher?

[Jockel_Bln]

Ich habe testweise in der config das API Skriptes mal "const maxOutputLimit = 2400" eingestellt, trotzdem lässt sich der Datenpunkt control.inverseMaxPower auf max 800 stellen. Wie kommt das?
In der App kann ich die max Ausgangsleistung auf 2400 stellen, das ist dann auch unter properties.inverseMaxPower zu sehen.

[maxclaudi]

@Jockel_Bln sagte:
Ich habe testweise in der config das API Skriptes mal "const maxOutputLimit = 2400" eingestellt, trotzdem lässt sich der Datenpunkt control.inverseMaxPower auf max 800 stellen. Wie kommt das?

maxOutputLimit und control.inverseMaxPower sollten aus meiner Sicht denselben maximalen Leistungswert haben und sind im Script auch so vorgesehen.

maxOutputLimit = 2400 verhindert jedoch nicht, dass Du den Datenpunkt control.inverseMaxPower später auf 800 W setzt. Der Datenpunkt schreibt die Einstellung direkt ins Gerät – genau wie die Zendure-App. Die Script-Konfiguration wird dadurch nicht verändert.

Deshalb ist es ganz normal, dass Du control.inverseMaxPower auf 800 W einstellen kannst, obwohl maxOutputLimit im Script auf 2400 W steht.

Meine Empfehlung ist, inverseMaxPower niemals dynamisch zu verändern. Das Script ist bewusst so aufgebaut, dass maxOutputLimit und inverseMaxPower denselben maximalen Leistungswert repräsentieren.

Wenn Du inverseMaxPower dauerhaft ändern möchtest, solltest Du deshalb auch maxOutputLimit in der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.

Die eigentliche Leistungsregelung sollte anschließend ausschließlich über outputLimit erfolgen. inverseMaxPower sehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.

Der Hintergrund ist auch, dass Zendure inverseMaxPower selbst als maximale Geräteleistung behandelt.
In der App ist eine Erhöhung über die Standardleistung hinaus nur nach entsprechender Bestätigung möglich; für noch höhere Leistungen sind sogar weitere Nachweise erforderlich.
Deshalb habe ich das Script bewusst auf diese Verwendung ausgelegt.

[Jockel_Bln]

@maxclaudi sagte:

Wenn Du inverseMaxPower dauerhaft ändern möchtest, solltest Du deshalb auch maxOutputLimit in der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.

Danke für deine ausführliche Antwort, aber kann es sein, dass wir aneinander vorbei reden?
Ich habe ja maxOutputLimit in der Konfiguration geändert, trotzdem steht im Datenpunkt control.inverseMaxPower weiterhin 800 und lässt sich auch nicht größer einstellen.

@maxclaudi sagte:

inverseMaxPower sehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.

Das habe ich ja auch so verstanden und wollte sie halt zum Test über 800 setzen.
In der App ging es nach einer Bestätigung durch mich. Im Automatikmodus des HEMS regelt er dann auch über die 800 hinaus hoch.

[maxclaudi]

@jockel_bln
ach ja :-)

• Stoppe das Script.
• setze: const maxOutputLimit = 2400;
• Script speichern
• Komplettes Verzeichnis "0_userdata.0.zendure.xxxxx" löschen.
• Script neu starten.

Es sollte auch reichen, wenn bei gestoppten Script - vor Neustart - nur der Datenpunkt gelöscht wird: 0_userdata.0.zendure.xxxxx.control.inverseMaxPower

[Jockel_Bln]

Das war es

[T-147]

Guten Morgen allerseits,

seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer! Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.

Über das Wochenende haben sich aber ein paar Fragen ergeben, auf die ich bis jetzt keine Antwort gefunden habe:

• Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?

• Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?

• Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?

• Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
  Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?

Soweit erstmal von mir :-)
Freue mich, wenn ich zukünftig irgendwie was sinnvolles zum Thema hier beitragen kann

[maxclaudi]

@T-147 sagte:

Guten Morgen allerseits,

seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer!

Dankeschön, wobei das DPL-Blockly-Skript nur eine Basis-Vorlage sein soll ;-)

Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.

Genau dafür ist es gedacht – als Vorlage für den Einstieg.

• Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?

Da über minSoc festgelegt wird, wann die untere Entladegrenze erreicht ist, veranlasst die Firmware automatisch ein Nachladen der Batterie(n), bis mindestens minSoc wieder erreicht ist.

Siehe auch Zendure FAQ, Zitat:

...Zudem erkennt das System automatisch, wenn der Batteriestand kritisch niedrig ist (z. B. bei geringer PV-Erzeugung) und schaltet in diesem Fall selbstständig auf Netzstrom um, um Schäden an der Batterie zu vermeiden.

Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.

Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.

Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.

Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.

• Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?

Die 15 Sekunden sind kein fester Optimalwert, sondern eher ein praxisnaher Erfahrungswert, der sich an den typischen Reaktionszeiten solcher (auch prof.) Systeme orientiert und sich in meinen Tests als praktikabel erwiesen hat. Bei meinen Regelungen gibt es unterschiedliche Zeiten.
Wenn Du das Basis-Script verwendest, kannst Du gerne andere Zeiten testen.

Beim Erhöhen der Ausgangsleistung (Entladen) kommt das System meiner Erfahrung nach auch mit etwa 10 Sekunden gut zurecht. Die neue Leistung sollte dann aber auch für eine gewisse Zeit gehalten werden.

Das Reduzieren der Ausgangsleistung reagiert etwas schneller. Je nach System können hier auch etwa 6 Sekunden ausreichend sein.

Beim AC-Laden würde ich dagegen keine ständig schwankenden Leistungswerte vorgeben. Meiner Meinung nach ist es sinnvoller, mit einer möglichst konstanten Ladeleistung über einen längeren Zeitraum zu arbeiten.

• Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?

Mich interessieren in erster Linie die Zählerwerte, denn das ist letztlich die Energie, die ich bezahlen muss.

Wenn Du dafür einen Shelly Plug oder eine andere Zwischensteckdose einsetzen möchtest, solltest Du darauf achten, dass auch negative Leistungen bzw. Rückspeisung korrekt erfasst werden. Tasmota-basierte Steckdosen unterstützen das beispielsweise.

• Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
  Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?

Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.

Deshalb bin ich beim 1600AC+ auch froh über die Off-Grid-Steckdose, an der sich ein Mikrowechselrichter betreiben lässt.

Der SF800 Pro 2 besitzt diese Möglichkeit ebenfalls.
Du könntest testweise einen 800-W-Hoymiles-Mikrowechselrichter an der Off-Grid-Steckdose betreiben.
Zwar wird die Batterie dann ebenfalls über AC geladen, der zusätzliche Umweg über das öffentliche Netz entfällt jedoch.
Wird gerade keine Leistung benötigt, lädt das System die Batterien automatisch über den an der Off-Grid-Steckdose angeschlossenen Wechselrichter.

Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste.

[T-147]

Vielen Dank für die ausführlichen Antworten.

@maxclaudi sagte:

Genau dafür ist es gedacht – als Vorlage für den Einstieg.

Sehr komfortabler und umfangreicher Einstieg

@maxclaudi sagte:

Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.

Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.

Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.

Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.

OK, also ist das erstmal normal und ich sollte mich um einen entsprechenden Entladeschutz kümmern, das ist gut zu wissen.

@maxclaudi sagte:

Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.

Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste.

Spätestens sobald ich auslesen und messen kann, wieviel kWh ich per AC in den SF800Pro schiebe und wieviel ich wieder ins Haus einspeise, kommen die 4 vorhandenen Panels direkt an den SF800 und es wird nur noch zum Kalibrieren per AC aufgeladen. Mein Hoymiles Wechselrichter kommt bei 4 Panels (SO/SW) sowieso regelmäßig an seine Belastungsgrenze mit den 2 MPPT, durch die 4 MPPT kann der SF800 da noch schön von aufladen.
Ich würde halt gern wissen, wieviel Energie ich per PV gewinne, bzw. einspeise, aber da muss ich ja auch die Energie per AC-Ladung wieder abrechnen. Ich hab mittlerweile nen Shelly dazwischen, der auch beide Richtungen kann (oder können soll), aber bisher blick ich bei den Messwerten von dem nicht durch. Der hat einen Wert für "ReturnedEnergy", was für mich dann die Einspeisung wäre. Und einen Wert "Energy", der aber der Gesamtwert in & out zu sein scheint. Passt für mich aber rechnerisch auch noch nicht ganz zusammen, aber das könnte auch einfach an mir liegen

Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

[maxclaudi]

Erweitertes Blockly auf Basis von:

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads

Das Blockly ist für Einsteiger als Grundlage gedacht. Es kann und sollte an das persönliche Setup sowie an die vorhandenen Verbraucher angepasst werden.

Sämtliche Debug-Ausgaben dienen ausschließlich den Testläufen und können später entfernt werden.

Die Beschreibung der Basis-Vorlage ist identisch mit folgenden zusätzlichen Ergänzungen:

• Batterie-Entladeschutz auf Basis der minimalen Zellspannungen der Batterien.
• Einfache Lasterkennung (Critical-Modus) für größere Verbraucher. Dabei wird die DPL-Regelung vorübergehend deaktiviert und die Leistungsregelung für eine definierte Zeit mit einem festen Wert übernommen.
• unterschiedliche Zeiten für inputLimit und outputLimit (intervalSec_inputLimit_auto_in_out_Limit; intervalSec_outputLimit_auto_in_out_Limit)

Das Blockly ist im Inneren wieder ausführlich kommentiert, sodass ich auf eine lange Erklärung verzichte.

Variable: intervalSec_criticalOutputLimit

Empfohlene Werte:

• 20s: eher aggressiv, häufiges Umschalten, nicht empfehlenswert.
• 30s: guter Kompromiss.
• 45s: im Alltag gut und angenehmer.
• 60s: ebenfalls gut geeignet.

Unter 15 Sekunden würde ich nicht gehen. Andernfalls besteht die Gefahr, dass bei taktenden Verbrauchern (insbesondere Induktionskochfeldern) ständig zwischen DPL und Critical-Modus gewechselt wird.

30 Sekunden halte ich für einen guten Ausgangs- und Testwert. Im Praxistest wird sich zeigen, welcher Wert für die eigenen Verbraucher am besten geeignet ist.

Meine persönliche Empfehlung: 45 bis 60 Sekunden.

Typische Verbraucher:

• Wasserkocher: ca. 2–3 Minuten
• Kaffeemaschine: ca. 20–40 Sekunden
• Mikrowelle: 30 Sekunden bis mehrere Minuten

Ein Induktionskochfeld taktet häufig:

• 3–8 Sekunden EIN
• 3–8 Sekunden AUS

(je nach Leistungsstufe)

Hier wirken 30 bis 45 Sekunden wie eine gute Entprellung.

Beispiel: Elektronischer Durchlauferhitzer:
ein elektronisch geregelter Durchlauferhitzer zieht seine Leistung normalerweise kontinuierlich. Während des Duschens können das mehrere Minuten mit nahezu konstanter Leistungsaufnahme sein.

Bei einem Wert von 45 Sekunden läuft die Regelung beispielsweise folgendermaßen ab:

• Hohe Last wird erkannt.
• DPL-Regelung wird deaktiviert.
• fest definiertes Output-Limit (z. B. 600 W) wird gesetzt.
• Nach 45 Sekunden erfolgt erneute Prüfung.
• Ist die hohe Last weiterhin vorhanden, wird der Zustand weitere 45 Sekunden beibehalten.
• Erst nachdem der Verbraucher abgeschaltet wurde, wird spätestens nach 45 Sekunden wieder auf die normale DPL-Regelung umgeschaltet.

Ziel ist Nulleinspeisung.
Jedoch versucht das Blockly nicht das Ziel, jede Sekunde wieder eine perfekte Nulleinspeisung herzustellen.
Vielmehr soll verhindert werden, dass bei plötzlich auftretenden hohen Lasten ständig zwischen Laden und Entladen geregelt oder die DPL-Regelung permanent nachgeführt wird. Dadurch sollte das Gesamtsystem deutlich ruhiger und praxisgerechter arbeiten.

Hinweis zum Urheber
Bitte den Urheberhinweis im Skript beachten.
Wenn auf Basis dieses Skripts oder von Teilen daraus eigene Veröffentlichungen entstehen, genügt ein kurzer Hinweis mit Verlinkung auf diesen Thread und/oder die Nennung meines Namens maxclaudi.

---

Im nächsten Beitrag folgt der Blockly-Code zum Download.

Viel Spaß damit!

Bilder vom Blockly:

[maxclaudi]

Blockly zum download und importieren vom vorherigen Post

Das Blockly musste als Datei hinzugefügt werden, weil es zu groß ist.

Datei: maxclaudi_dpl.zip enthält nur maxclaudi_dpl.xml

1. Datei herunterladen und Virenscan.
2. maxclaudi_dpl.zip entpacken
3. in iobroker neues, leeres Blockly erstellen
4. maxclaudi_dpl.xml
   importieren:
   

---

Das nächste Bild ist nur ein Beispiel.
Statt zenSDK_DPL_Blockly.xml - > maxclaudi_dpl.xml importieren.

---

Bitte den Urheber im Skript beachten.

Falls es Dir hilft oder Du Dich bedanken möchtest: Ein positives Voting als Dankeschön ist völlig ausreichend :-)

update 17.07.2026; 18:30h
verbesserte Version

• criticalOutputLimit ist Begrenzung: wie viel Watt max. output im criticalMode sein darf,
  (auch max_outputLimit ist erlaubt).

• criticalGridPower definiert ab wie viel Watt ein Verbraucher als kritischer Verbraucher zählt.

Kommentare im Blockly bitte beachten.

download:
maxclaudi_dpl.zip
Hoffe es hilft Euch ein wenig; viel Spaß damit! :-)

[maxclaudi]

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

[Daniel 8]

@maxclaudi sagte:

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Vielen Dank. Wenn ich mal Zeit finde, werde ich es mir mal ansehen. Meine Steuerung läuft aktuell ganz gut für mich.
Bin grad in mehreren anderen Projekten beschäftigt.

[T-147]

@maxclaudi sagte:

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Mögen Dir beim Händewaschen niemals die Ärmel runter rutschen!

[maxclaudi]

Habe soeben noch einmal das Blockly hochgeladen.
War ein Datenpunkt nicht richtig.
Entweder selbst korrigieren oder noch einmal die korrigierte Version downloaden.

Korrektur:

oder die ganzen Blöcke zur Fehlerkorrektur entfernen.

@T-147:
Mögen Dir beim Händewaschen niemals die Ärmel runter rutschen!

:-)))

[Jockel_Bln]

@maxclaudi sagte:

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Da hast du ja ordentlich was zusammen geschraubt
Meine Regierung hat gerade Urlaub, da darf ich momentan nicht so viel spielen.
Aber jetzt schon vorab vielen Dank für deine Arbeit.

[maxclaudi]

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Post

update 17.07.2026; 18:30h
verbesserte Version für kritische Verbraucher

• criticalOutputLimit ist Begrenzung: wie viel Watt max. output im criticalMode sein darf
  (auch max_outputLimit ist erlaubt).

• criticalGridPower definiert ab wie viel Watt ein Verbraucher als kritischer Verbraucher zählt.

Kommentare im Blockly bitte beachten.

Download -> HIER