wichtiges UPDATE für controller 7.2.2 im stable

[DasBo1975]

Hallo zusammen,

soeben ist PoolControl 1.3.34 verfügbar. Dieses Update bringt zwar keine neuen sichtbaren Funktionen, enthält aber eine wichtige interne Stabilitätsverbesserung, die ich allen Nutzern ausdrücklich empfehle.

Was wurde geändert?

Die interne Chemie-Historie für pH, ORP und TDS wurde vollständig überarbeitet.

Hintergrund ist, dass sich unter bestimmten Umständen die gespeicherten JSON-Historien immer weiter vergrößern konnten. Dadurch konnte die states.jsonl von ioBroker mit der Zeit unnötig stark anwachsen.

In einem Extremfall führte das sogar dazu, dass der js-controller nach einem Neustart aufgrund einer zu großen states.jsonl nicht mehr starten konnte.

Was wurde verbessert?

Die komplette Historienverwaltung wurde neu aufgebaut:

• Begrenzte Kurzzeit-Historie für aktuelle Messwerte
• Zusätzliche kompakte Tageshistorie für Langzeittrends
• Feste Größen- und Sicherheitslimits für alle Chemie-Historien
• Zusätzliche Schutzmechanismen gegen übergroße JSON-States
• Weitere Absicherung für Solar-Logbuch und Debug-Log

Wichtig war mir dabei, keine bestehenden Funktionen zu verlieren.

Deshalb bleiben alle bisherigen Auswertungen weiterhin erhalten:

• 24-Stunden-Trends
• 7-Tage-Trends
• 30-Tage-Trends
• Trendbewertungen
• Reports
• bestehende Datenpunkte für VIS, Blockly, JavaScript oder eigene Dashboards

Die Änderungen finden ausschließlich "unter der Haube" statt und sollen den Adapter langfristig robuster machen.

Update-Empfehlung

Ich empfehle allen Nutzern, auf Version 1.3.34 zu aktualisieren, auch wenn aktuell keine Probleme auftreten. Das Update verbessert die langfristige Stabilität und verhindert, dass interne Historien unnötig groß werden.

Wie immer freue ich mich über Rückmeldungen und Tests. Vielen Dank an alle, die PoolControl testen und mit ihren Ideen und ihrem Feedback zur Weiterentwicklung beitragen! 😊

[RikDRS]

@DasBo1975 sagte:

Danke für deine ausführliche Erklärung. 🙂

gerne

...

• gute PV-Prognose → längere Laufzeit
• schlechte PV-Prognose → kürzere Laufzeit

Dabei ist der tatsächliche PV-Überschuss oder der aktuelle Hausverbrauch für dein Blockly gar nicht entscheidend.

genau

Falls ich das richtig verstanden habe, dann unterscheidet sich diese Logik deutlich vom Auto-PV-Modus von PoolControl.

Der Auto-PV-Modus arbeitet bewusst mit dem tatsächlich vorhandenen PV-Überschuss. Das bedeutet, es wird genau der Überschuss genutzt, der in diesem Moment wirklich vorhanden ist – unabhängig davon, wie die Prognose vorher ausgesehen hat.

Deshalb habe ich im Moment das Gefühl, dass hier zwei unterschiedliche Steuerungsansätze parallel arbeiten. Dein Blockly übernimmt bereits einen großen Teil der Pumpenlogik und PoolControl versucht gleichzeitig ebenfalls, die Pumpe zu überwachen bzw. zu steuern. Dadurch entstehen dann auch die Konflikte mit der Pumpenüberwachung.

Deshalb würde ich gerne zuerst verstehen, ob dein Blockly bereits vor PoolControl entstanden ist und ob du diese komplette Logik weiterhin behalten möchtest.

Oder ist dein Ziel eigentlich, möglichst viel davon zukünftig direkt durch PoolControl erledigen zu lassen?

Das würde mir helfen einzuschätzen, ob wir hier über eine andere Nutzung der vorhandenen Funktionen sprechen oder tatsächlich über eine sinnvolle Erweiterung des Adapters.

es ist vor PoolControl entstanden - Ziel wäre für mich aber trotzdem, mein Skript nicht mehr nutzen zu müssen / brauchen und Deinen Adapter zu verwenden

PS:

Während ich deine Erklärung gelesen habe, ist mir noch ein weiterer Gedanke gekommen.

Ich glaube, wir sprechen hier eigentlich über zwei unterschiedliche Konzepte.

Der aktuelle Auto-PV-Modus von PoolControl nutzt bewusst den tatsächlich vorhandenen PV-Überschuss. Also genau die Energie, die in diesem Moment wirklich übrig ist. Deshalb spielt dort auch der aktuelle Hausverbrauch eine Rolle und nicht nur die theoretisch mögliche PV-Leistung.

Dein Blockly verfolgt dagegen einen anderen Ansatz. Dort wird die Laufzeit der Pumpe anhand einer PV-Prognose verändert. Vereinfacht gesagt:

• gute Prognose → längere Laufzeit
• schlechtere Prognose → kürzere Laufzeit

Das ist aus meiner Sicht aber keine klassische PV-Überschusssteuerung mehr, sondern eher eine Intervallsteuerung, deren Laufzeit anhand einer Prognose variiert wird.

Ich möchte deshalb ungern den bestehenden Auto-PV-Modus in diese Richtung erweitern, weil dadurch zwei unterschiedliche Philosophien vermischt würden.

Was ich mir dagegen grundsätzlich eher vorstellen könnte, wäre irgendwann einmal ein eigener Intervallmodus, der unabhängig vom Auto-PV-Modus arbeitet. Beispielsweise:

• Zeitraum von ... bis ...
• alle X Minuten starten
• für Y Minuten laufen

Die eigentliche Frage wäre dann nur noch, wodurch X oder Y bestimmt wird (fest, Wetter, Prognose usw.).

Das ist im Moment ausdrücklich nur ein Gedanke von mir und keine geplante Funktion. Mir war beim Lesen deines Blocklys nur wichtig zu verstehen, welches eigentliche Problem du lösen möchtest. Deshalb würde ich gerne zuerst sicher sein, dass ich deine Anforderung wirklich richtig verstanden habe.

Stimme Dir in den Punkten zu, keine Frage.
zwei Gedanken die ich noch habe:

• Dein Adapter basiert auf einer "großen" PV-Anlage - oder? Wir haben "nur" ein BKW und da kommt der Überschuss - spätestens mit einer aktiven Klimaanlage - nicht mehr zu Stande ;)
• ist es möglich in Deinem Adapter die verschiedenen Modi kombinieren zu können?
  Also nicht die Auswahl eines einzelnen Modi, sondern die Auswahl der Modi, nachdem der User die Pumpe gesteuert haben möchte.
  Dann wäre es kein Vermischen in dem Sinne - oder?

[DasBo1975]

@RikDRS sagte:

Danke dir, jetzt ist es deutlich klarer. 🙂

Dann habe ich dich richtig verstanden:

Dein Blockly ist vor PoolControl entstanden und du würdest diese Logik langfristig gerne durch PoolControl ersetzen. Es geht dir also nicht darum, PoolControl am Adapter vorbei zu betreiben, sondern darum, eine bisher externe Logik möglichst sauber in den Adapter zu bekommen.

Wichtig ist für mich dabei die fachliche Trennung:

Der Auto-PV-Modus von PoolControl basiert nicht auf einer großen PV-Anlage, sondern auf dem tatsächlich vorhandenen PV-Überschuss. Die Größe der PV-Anlage ist dabei erst einmal egal. Entscheidend ist nur: Ist in diesem Moment wirklich Überschuss vorhanden oder nicht?

Bei einem Balkonkraftwerk kann es natürlich passieren, dass durch andere Verbraucher, z. B. eine Klimaanlage, kaum oder kein echter Überschuss übrig bleibt. Dann startet der Auto-PV-Modus auch nicht, weil genau dieser Modus bewusst nur mit echtem Überschuss arbeitet.

Deine bisherige Blockly-Logik ist anders aufgebaut. Dort wird nicht der echte Überschuss genutzt, sondern eine PV-Prognose. Daraus leitest du dann unterschiedliche Laufzeiten ab:

• gute Prognose → längere Laufzeit
• schlechtere Prognose → kürzere Laufzeit

Das ist aus meiner Sicht eine eigenständige Logik. Eher eine prognoseabhängige Intervall-/Zeitsteuerung und keine klassische PV-Überschusssteuerung.

Mehrere Modi direkt miteinander zu kombinieren sehe ich aktuell kritisch. Wenn Auto-PV, Zeitmodus und Automatik gleichzeitig aktiv in die Pumpensteuerung eingreifen, wird es irgendwann schwer nachvollziehbar, warum die Pumpe gerade läuft oder nicht läuft.

Was ich mir eher vorstellen könnte, wäre eine saubere Erweiterung innerhalb des Zeitmodus oder als eigener Intervallmodus.

Zum Beispiel:

• Zeitraum von/bis
• alle X Minuten oder Stunden starten
• dann Y Minuten laufen
• optional später: Y abhängig von einer Prognose oder einer anderen Bedingung

Dann bleibt die Logik sauber getrennt:

Auto-PV = echter PV-Überschuss
Zeitmodus = feste Zeitfenster
Intervallmodus = wiederkehrende kurze Laufzeiten innerhalb eines Zeitraums
Nachpumpen = fehlende Mindestumwälzung nachholen

Das ist im Moment aber ausdrücklich nur ein Gedankengang und keine zugesagte Funktion. Ich finde deinen Anwendungsfall aber interessant genug, um ihn genauer zu durchdenken. Wichtig wäre mir nur, dass wir die bestehenden Modi nicht vermischen, sondern eine saubere und verständliche Lösung finden.

[DennisMenger]

Guten Morgen. Ich habe heute aufgrund der warmen Wassertemperaturen mal die Mindestmenge der Umwälzung erhöht. Anpassung erfolgte über die Instanz des Adapters selbst.
Der Datenpunkt circulation/daily_required hat sich erhöht, allerdings der Datenpunkt circulation/daily_remaining nicht.

Ein Neustart des Adapters brachte keine Veränderung.

[DasBo1975]

Hallo zusammen,

ich habe soeben die Version 1.3.35 veröffentlicht.

Dieses Update behebt einen Fehler in der Berechnung der täglichen Mindestumwälzung, der von einem Nutzer entdeckt wurde.

Wurde die Poolgröße oder die Mindestumwälzung pro Tag geändert, wurde der benötigte Tageswert zwar korrekt neu berechnet, die verbleibende tägliche Umwälzung (daily_remaining) konnte jedoch unter bestimmten Bedingungen den alten Wert behalten. Dadurch konnten beide Werte nach einem Adapterneustart vorübergehend nicht mehr zusammenpassen.

Mit Version 1.3.35 werden die benötigte und die verbleibende tägliche Umwälzung nun immer gemeinsam und konsistent berechnet. Dadurch stimmen die angezeigten Werte auch nach Änderungen der Konfiguration oder einem Neustart des Adapters sofort wieder überein.

An dieser Stelle möchte ich mich ganz herzlich bei @dennismenger bedanken. 😊

Er hat den Fehler entdeckt, sauber beschrieben und damit geholfen, PoolControl wieder ein Stück robuster zu machen. Genau solche Rückmeldungen aus der Praxis sind unglaublich wertvoll und tragen wesentlich dazu bei, den Adapter kontinuierlich zu verbessern.

Wie immer freue ich mich über euer Feedback und wünsche euch viel Spaß mit der neuen Version.

Viele Grüße

Dirk

[DennisMenger]

@dasbo1975 Vielen Dank für die schnelle Fehlerbehebung.

Und dann habe ich noch eine Frage zum Zeitmodus. Aktuell sind ja maximal 3 Zeitfenster möglich. Ich würde mir wünschen, dass man mehr als 3 Zeitfenster nutzen könnte. Ab einer höheren Wassertemperatur ist sinnvoll, dass das Wasser entweder dauerhaft bewegt wird oder zumindest in mehreren Intervallen. Dafür bräuchte man aber mehr als die 3 bisherigen Zeitfenster um die Pumpe dann zwischendurch mal für 30 Minuten laufen zu lassen oder so. Letztendlich geht das ja auch in deine Gedankenrichtung von gestern Abend.
Ich habe leider noch keinen Frequenzumrichter, mit dem ich die Pumpe mit einem geringeren Stromverbrauch dauerhaft laufen lassen könnte.

Und eine weitere kurze Frage. Der Datenpunkt /poolcontrol.0.general.min_circulation_per_day ist in den Objekten nur lesbar, aber nicht beschreibbar. Leider muss ich dann immer in die Instanz gehen und die Einstellung dort ändern. Ich würde gerne die Möglichkeit haben den Wert auch über die Vis zu ändern. Wäre das auch möglich? Oder ist das so nicht gewollt? Noch besser wäre die Möglichkeit, dass man es einstellen könnte, dass ab einer bestimmten Pooltemperatur die Umwälzmenge automatisch erhöht wird. Das wäre dann sozusagen die Premiumfunktion.

[DennisMenger]

Und nochmal ich zum Automatik PV Modus. Er schaltet bei mir nach ca. 30 Sekunden wieder aus, da er sagt dass die Pumpe oberhalb des Normalbereichs läuft. Durch die neue größere Pumpe passen die Werte im Bereich learning nicht mehr zu den tatsächlichen Werten.

[DasBo1975]

@DennisMenger sagte:

Und nochmal ich zum Automatik PV Modus. Er schaltet bei mir nach ca. 30 Sekunden wieder aus, da er sagt dass die Pumpe oberhalb des Normalbereichs läuft. Durch die neue größere Pumpe passen die Werte im Bereich learning nicht mehr zu den tatsächlichen Werten.

Danke fürs Prüfen. Der Wert aus der Instanz wird beim Adapterstart nach pump.pump_max_watt übernommen und genau dieser State wird für den Überlastschutz verwendet.

Bitte prüfe einmal direkt beim Abschalten:

• poolcontrol.0.pump.pump_max_watt
• poolcontrol.0.pump.current_power
• poolcontrol.0.pump.error
• poolcontrol.0.pump.mode

Die Abschaltung erfolgt, wenn current_power größer ist als pump_max_watt × 1.1.

Wenn pump.error dabei true wird und pump.mode auf off geht, ist es eindeutig der Überlastschutz. Dann wäre entweder pump_max_watt noch zu niedrig oder der Leistungsdatenpunkt liefert einen zu hohen/falschen Wert.

Die Learning-Meldung „oberhalb des Normalbereichs“ schaltet selbst nichts ab. Die zeigt nur an, dass die alten gelernten Werte nicht mehr zur neuen Pumpe passen.

[DasBo1975]

Hallo zusammen,

heute gibt es mit der Version 1.4.0 wieder ein größeres Update für PoolControl. 🎉

Dieses Mal standen vor allem die Themen Umwälzung, Pumpen-Learning und Zeitsteuerung im Mittelpunkt. Einige der neuen Funktionen sind direkt aus euren Anregungen und dem Feedback hier aus dem Forum entstanden. Vielen Dank dafür! 🙂

🆕 Reset-Button für das Pumpen-Learning

Nach einem Pumpenwechsel oder wenn das Learning einmal fehlerhafte Werte übernommen hat, mussten bisher die Lernwerte manuell zurückgesetzt werden.

Dafür gibt es jetzt einen eigenen pump.learning.reset-Button.

Mit einem Klick werden alle gelernten Pumpenwerte zurückgesetzt und das Learning beginnt automatisch wieder von vorne. Persönliche Einstellungen wie z. B. die eingestellte Toleranz bleiben dabei selbstverständlich erhalten.

🆕 Beschreibbarer Umwälzfaktor

Der Datenpunkt

general.min_circulation_per_day

ist jetzt beschreibbar und persistent.

Der in der Adapterkonfiguration eingestellte Wert dient künftig nur noch als Initialwert beim ersten Einrichten. Danach kann der Umwälzfaktor bequem direkt über VIS, HomePanel oder andere Automatisierungen angepasst werden, ohne jedes Mal die Instanz öffnen zu müssen.

Änderungen werden sofort übernommen und die benötigte tägliche Umwälzmenge wird unmittelbar neu berechnet.

🆕 Temperaturabhängiger Umwälzfaktor

Eine weitere neue Funktion ist die temperaturabhängige Anpassung des täglichen Umwälzfaktors.

Ihr könnt jetzt:

einen beliebigen aktiven Temperatursensor auswählen,
eine Temperaturschwelle festlegen,
sowie einen zusätzlichen Umwälzfaktor definieren.

Wird die eingestellte Temperatur überschritten, erhöht PoolControl automatisch den täglichen Umwälzbedarf.

Der ursprünglich eingestellte Basiswert bleibt dabei immer erhalten und wird nicht verändert. Zusätzlich stehen neue Diagnose-Datenpunkte zur Verfügung, über die jederzeit nachvollzogen werden kann, welcher Umwälzfaktor aktuell verwendet wird und warum.

🆕 Intervallbetrieb für die Zeitsteuerung

Auch die bestehende Zeitsteuerung wurde erweitert.

Jedes der drei vorhandenen Zeitfenster kann jetzt wahlweise:

im bisherigen Dauerbetrieb oder
im neuen Intervallbetrieb

verwendet werden.

Beispielsweise kann ein Zeitfenster von 08:00 bis 10:00 Uhr eingerichtet werden, wobei die Pumpe innerhalb dieses Zeitraums nur 15 Minuten pro Stunde oder 30 Minuten pro Stunde läuft.

Dadurch lassen sich viele bisher über Blockly oder eigene Skripte realisierte Intervallsteuerungen jetzt direkt mit PoolControl umsetzen.

Mehrere Zeitfenster können sich dabei auch überschneiden. PoolControl berücksichtigt dies automatisch, sodass sich die einzelnen Zeitfenster nicht gegenseitig abschalten.

🔍 Verbesserte Diagnose

Im Zuge dieser Erweiterungen wurden außerdem verschiedene neue Diagnose- und Statusmeldungen ergänzt.

Dadurch lässt sich künftig deutlich einfacher nachvollziehen,

warum ein bestimmter Umwälzfaktor aktiv ist,
ob der temperaturabhängige Faktor gerade greift,
oder welcher Status aktuell in der Zeitsteuerung vorliegt.
🙏 Vielen Dank

Ein besonderer Dank geht dieses Mal an @dennismenger und @rikdrs .

Durch eure Ideen, Rückmeldungen und Diskussionen hier im Forum sind gleich mehrere dieser neuen Funktionen entstanden oder deutlich verbessert worden. Genau dieses Feedback hilft dabei, PoolControl Schritt für Schritt weiterzuentwickeln.

Wie immer freue ich mich über eure Rückmeldungen, Tests und natürlich auch über weitere Ideen. 😊

Viel Spaß mit der Version 1.4.0!

[DennisMenger]

@DasBo1975 sagte:

@DennisMenger sagte:

Und nochmal ich zum Automatik PV Modus. Er schaltet bei mir nach ca. 30 Sekunden wieder aus, da er sagt dass die Pumpe oberhalb des Normalbereichs läuft. Durch die neue größere Pumpe passen die Werte im Bereich learning nicht mehr zu den tatsächlichen Werten.

Danke fürs Prüfen. Der Wert aus der Instanz wird beim Adapterstart nach pump.pump_max_watt übernommen und genau dieser State wird für den Überlastschutz verwendet.

Bitte prüfe einmal direkt beim Abschalten:

• poolcontrol.0.pump.pump_max_watt
• poolcontrol.0.pump.current_power
• poolcontrol.0.pump.error
• poolcontrol.0.pump.mode

Die Abschaltung erfolgt, wenn current_power größer ist als pump_max_watt × 1.1.

Wenn pump.error dabei true wird und pump.mode auf off geht, ist es eindeutig der Überlastschutz. Dann wäre entweder pump_max_watt noch zu niedrig oder der Leistungsdatenpunkt liefert einen zu hohen/falschen Wert.

Die Learning-Meldung „oberhalb des Normalbereichs“ schaltet selbst nichts ab. Die zeigt nur an, dass die alten gelernten Werte nicht mehr zur neuen Pumpe passen.

So hier einmal die Werte beim Abschalten

poolcontrol.0.pump.pump_max_watt => 650 Watt (so wie auch tatsächlich das Maximum der Pumpe ist und eingetragen ist.
poolcontrol.0.pump.current_power => 605,.. (Toleranz auf 20% eingestellt)
poolcontrol.0.pump.error => kein Fehler
poolcontrol.0.pump.mode => bleibt nach dem Abschalten der Pumpe auf Automatik_PV stehen

Dazu der Text "Pumpe läuft oberhalb des Normalbereiches" im Bereich pump/learning/status_text.

PV-Überschuss ist dauerhaft vorhanden gewesen.

Resetknopf der Werte im Bereich Learning habe ich bisher noch nicht gedrückt.

[DasBo1975]

@DennisMenger sagte:

@DasBo1975 sagte:

@DennisMenger sagte:

Und nochmal ich zum Automatik PV Modus. Er schaltet bei mir nach ca. 30 Sekunden wieder aus, da er sagt dass die Pumpe oberhalb des Normalbereichs läuft. Durch die neue größere Pumpe passen die Werte im Bereich learning nicht mehr zu den tatsächlichen Werten.

Danke fürs Prüfen. Der Wert aus der Instanz wird beim Adapterstart nach pump.pump_max_watt übernommen und genau dieser State wird für den Überlastschutz verwendet.

Bitte prüfe einmal direkt beim Abschalten:

• poolcontrol.0.pump.pump_max_watt
• poolcontrol.0.pump.current_power
• poolcontrol.0.pump.error
• poolcontrol.0.pump.mode

Die Abschaltung erfolgt, wenn current_power größer ist als pump_max_watt × 1.1.

Wenn pump.error dabei true wird und pump.mode auf off geht, ist es eindeutig der Überlastschutz. Dann wäre entweder pump_max_watt noch zu niedrig oder der Leistungsdatenpunkt liefert einen zu hohen/falschen Wert.

Die Learning-Meldung „oberhalb des Normalbereichs“ schaltet selbst nichts ab. Die zeigt nur an, dass die alten gelernten Werte nicht mehr zur neuen Pumpe passen.

So hier einmal die Werte beim Abschalten

poolcontrol.0.pump.pump_max_watt => 650 Watt (so wie auch tatsächlich das Maximum der Pumpe ist und eingetragen ist.
poolcontrol.0.pump.current_power => 605,.. (Toleranz auf 20% eingestellt)
poolcontrol.0.pump.error => kein Fehler
poolcontrol.0.pump.mode => bleibt nach dem Abschalten der Pumpe auf Automatik_PV stehen

Dazu der Text "Pumpe läuft oberhalb des Normalbereiches" im Bereich pump/learning/status_text.

PV-Überschuss ist dauerhaft vorhanden gewesen.

Resetknopf der Werte im Bereich Learning habe ich bisher noch nicht gedrückt.

Ok. Könntest du das mal in einem anderen Modus probieren. Also nicht nur Auto pv. Mich würde interessieren ob der Fehler dort auch passiert. Und noch ein Hinweis die Textausgabe Pump Learning ist nur ein Hinweis Text. Hat mit der reinen Pumpenschaltung nichts zu tun. Sollte wieder normal sein, wenn du den Reset Button gedrückt hast

[DennisMenger]

Der normale Automatik-Modus, sowie der Zeitmodus funktionieren sauber. Dort wird die Pumpe nicht abgeschaltet.

[DasBo1975]

Hallo zusammen,

Version 1.4.1 ist fertig und sollte in den nächsten Stunden über das Repository verfügbar sein.

Dieses Update enthält einen Bugfix, der für mich tatsächlich eine richtig harte Nuss war.

An dieser Stelle möchte ich mich ganz herzlich bei @dennismenger bedanken. Ohne seine ausführlichen Rückmeldungen und seine Geduld bei den vielen Tests hätte ich diesen Fehler wahrscheinlich deutlich später gefunden.

Anfangs sah alles danach aus, als würde der Auto-PV-Modus korrekt arbeiten. Die eingestellten Maximalwerte der Pumpe wurden sauber übernommen und auch die ersten Analysen haben keinen offensichtlichen Fehler gezeigt.

Ich habe mir den kompletten Ablauf anschließend noch einmal in Ruhe vorgenommen und verschiedene Szenarien Schritt für Schritt durchgespielt. Erst dadurch konnte ich die eigentliche Ursache eindeutig eingrenzen und schließlich beheben.

Kurz erklärt:

Bei der Halteentscheidung im Auto-PV-Modus gab es einen Berechnungsfehler. Sobald die Pumpe aufgrund eines ausreichenden PV-Überschusses eingeschaltet worden war, wurde ihre Leistungsaufnahme über den Hausverbrauch bereits korrekt berücksichtigt. Bei der anschließenden Halteprüfung wurde jedoch nochmals geprüft, ob zusätzlich genügend Überschuss für genau diese Pumpenleistung vorhanden ist. Dadurch konnte es passieren, dass der Auto-PV-Modus nach der eingestellten Nachlaufzeit wieder abgeschaltet hat, obwohl tatsächlich weiterhin ausreichend PV-Leistung für den Betrieb vorhanden war.

Die eigentliche Berechnung des PV-Überschusses bleibt selbstverständlich unverändert und zeigt weiterhin den echten verfügbaren Überschuss an. Angepasst wurde ausschließlich die interne Halteentscheidung des Auto-PV-Modus für bereits laufende Pumpen.

Das Ergebnis:

Der Auto-PV-Modus arbeitet jetzt auch bei der Halteentscheidung korrekt.
Die Nachlaufzeit funktioniert weiterhin wie vorgesehen, wenn tatsächlich nicht mehr genügend PV-Leistung vorhanden ist.
Die Berechnung und Anzeige des PV-Überschusses bleibt unverändert.

Ich freue mich ehrlich gesagt besonders über diesen Fix, weil das genau die Art von Fehler ist, die man nicht einfach durch einen Blick in den Code findet. Solche Fehler zeigen sich oft erst im praktischen Einsatz unter ganz bestimmten Bedingungen. Umso schöner ist es, wenn man die eigentliche Ursache am Ende wirklich versteht und nicht nur das Symptom beseitigt.

Deshalb noch einmal ein großes Dankeschön an Dennis für die Unterstützung und die vielen Tests. Genau solche Rückmeldungen helfen mir dabei, PoolControl Schritt für Schritt noch robuster und zuverlässiger zu machen. 😊