wichtiges UPDATE für controller 7.2.2 im stable

[DennisMenger]

@RikDRS sagte:

Automatik PV - schaltet die Pumpe ein bzw. aus (mit Nachlaufzeit) wenn Photovoltaik Überschuss vorhanden ist.

@dasbo1975 dazu habe ich eine Frage. Bei mir ist seit 8.43 Uhr PV-Überschuss vorhanden. Datenpunkt surplus_active steht auf true. Aber die Pumpe hat nicht eingeschaltet. Oder wartet der Modus Automatik (PV) auch auf eine Solaranforderung?

[DasBo1975]

@DennisMenger sagte:

@dasbo1975 dazu habe ich eine Frage. Bei mir ist seit 8.43 Uhr PV-Überschuss vorhanden. Datenpunkt surplus_active steht auf true. Aber die Pumpe hat nicht eingeschaltet. Oder wartet der Modus Automatik (PV) auch auf eine Solaranforderung?

Hmm. Nein. Im Auto PV Modus ist die Solaranforderung egal. Hast du den Adapter mal neu gestartet?

[RikDRS]

Moin,
& Danke Euch für die Erklärungen!

Dann habe ich eine weitere Frage zu dem Adapter:
wenn ich die Pumpe nun "extern" per Skript starte, stellt sich die Pumpe nach 60Sekunden wieder ab, der Datenpunkt

poolcontrol.0.pump.status

zeigt dann Fehler an. Das ist ein / der Schutzmechanismus

Wie kann ich das Umgehen bzw einstellen, das mein Skript die Pumpe trotzdem steuern darf?

hier ein Teil des Skripts

[DasBo1975]

@RikDRS sagte:

Moin,
& Danke Euch für die Erklärungen!

Dann habe ich eine weitere Frage zu dem Adapter:
wenn ich die Pumpe nun "extern" per Skript starte, stellt sich die Pumpe nach 60Sekunden wieder ab, der Datenpunkt

poolcontrol.0.pump.status

zeigt dann Fehler an. Das ist ein / der Schutzmechanismus

Wie kann ich das Umgehen bzw einstellen, das mein Skript die Pumpe trotzdem steuern darf?

hier ein Teil des Skripts

Guck dann mal bitte im Log nach welcher Fehler dir ausgegeben wird.

Und noch eine Frage zu deinem Blocky. Geht es dir nur da drum dass die Pumpe zu der Uhrzeit laufen darf ? Pool Control hat auch ein Zeit Modus

Schwierig kann es auf jeden Fall werden, wenn du eine externe Logik mit der interne Logik vermischt

[DennisMenger]

@DasBo1975 Werde ich morgen mal testen. Habe heute eine neue Pumpe installiert, die ich dann morgen in Betrieb nehmen werde.

[Andreas67 0]

Hallo @dasbo1975,das Problem von RikDRS (#488) mit dem externen Blockly-Skript zeigt eigentlich sehr gut, wo der Adapter logisch noch verbessert werden kann. Nutzer weichen meistens nur auf externe Skripte aus, wenn ihnen im Adapter eine bestimmte Option fehlt.Statt dass User versuchen, die Pumpe am Adapter vorbei zu steuern (was den Schutzmechanismus triggert), wäre eine Erweiterung der PV-Logik im Adapter die sauberere Lösung.Mein Vorschlag zur Verbesserung:Könnte man im Automatik PV-Modus eine Option wie "Mindestlaufzeit tagsüber erzwingen" einbauen? Wenn die PV-Leistung nicht reicht, schaltet der Adapter die Pumpe aktuell erst abends zur check_time ein. Viele möchten aber, dass die Pumpe z. B. zwingend zwischen 10:00 und 16:00 Uhr läuft (wegen der Sonne/Filterung), egal ob PV-Überschuss da ist oder nicht. Wenn der Adapter diese "Grundlaufzeit" im PV-Modus nativ mitorganisiert, spart man sich fehleranfällige, externe Zusatzskripte komplett.Viele Grüße!

[DasBo1975]

@Andreas67-0 sagte:

Hallo @dasbo1975,das Problem von RikDRS (#488) mit dem externen Blockly-Skript zeigt eigentlich sehr gut, wo der Adapter logisch noch verbessert werden kann. Nutzer weichen meistens nur auf externe Skripte aus, wenn ihnen im Adapter eine bestimmte Option fehlt.Statt dass User versuchen, die Pumpe am Adapter vorbei zu steuern (was den Schutzmechanismus triggert), wäre eine Erweiterung der PV-Logik im Adapter die sauberere Lösung.Mein Vorschlag zur Verbesserung:Könnte man im Automatik PV-Modus eine Option wie "Mindestlaufzeit tagsüber erzwingen" einbauen? Wenn die PV-Leistung nicht reicht, schaltet der Adapter die Pumpe aktuell erst abends zur check_time ein. Viele möchten aber, dass die Pumpe z. B. zwingend zwischen 10:00 und 16:00 Uhr läuft (wegen der Sonne/Filterung), egal ob PV-Überschuss da ist oder nicht. Wenn der Adapter diese "Grundlaufzeit" im PV-Modus nativ mitorganisiert, spart man sich fehleranfällige, externe Zusatzskripte komplett.Viele Grüße!

Danke erstmal für deine Antwort.

Bezugnehmend auf Beitrag #488 hatte ich ja gefragt, warum das externe Skript vorgeschaltet ist. Wenn ich den genauen Zweck kenne, kann ich besser einschätzen, ob daraus eventuell eine sinnvolle Erweiterung für PoolControl entstehen könnte.

Bei dem Vorschlag zur Grundlaufzeit im Auto-PV-Modus muss ich aber kurz die Bremse treten.

Der Auto-PV-Modus ist bewusst als reiner PV-Überschussmodus gedacht. Das bedeutet: Die Pumpe läuft dann, wenn ausreichend PV-Überschuss vorhanden ist. Eine fest eingestellte Grundlaufzeit, z. B. von 10:00 bis 16:00 Uhr, würde dem Grundgedanken dieses Modus widersprechen, weil die Pumpe dann auch ohne PV-Überschuss laufen würde.

Für feste Laufzeiten gibt es in PoolControl den Zeitmodus.

Trotzdem ist auch im Auto-PV-Modus sichergestellt, dass die gewünschte tägliche Mindestumwälzung erreicht werden kann. Dafür gibt es das automatische Nachpumpen. Zu einer vom Nutzer eingestellten Uhrzeit prüft PoolControl, ob die tägliche Mindestumwälzung bereits erreicht wurde. Falls nicht, kann die fehlende Umwälzung automatisch nachgeholt werden.

Kurz gesagt:

Auto-PV = Pumpe läuft bei PV-Überschuss
Zeitmodus = Pumpe läuft in festen Zeitfenstern
Nachpumpen = fehlende Mindestumwälzung wird nachgeholt

Deshalb würde ich zuerst gerne verstehen, was das externe Blockly genau erreichen soll. Vielleicht lässt sich das bereits mit den vorhandenen Funktionen sauber abbilden.

[RikDRS]

@DasBo1975 sagte:

@RikDRS sagte:

Dann habe ich eine weitere Frage zu dem Adapter:
wenn ich die Pumpe nun "extern" per Skript starte, stellt sich die Pumpe nach 60Sekunden wieder ab, der Datenpunkt

poolcontrol.0.pump.status

zeigt dann Fehler an. Das ist ein / der Schutzmechanismus

Wie kann ich das Umgehen bzw einstellen, das mein Skript die Pumpe trotzdem steuern darf?

Guck dann mal bitte im Log nach welcher Fehler dir ausgegeben wird.
hier das gewünschte Log:

2026-06-26 17:02:05.856 - warn: poolcontrol.0 (1757178) [pumpHelper] Fehler: Pumpe EIN, aber keine Leistung!
...
2026-06-26 17:02:09.685 - info: poolcontrol.0 (1757178) [pumpHelper] Pump error resolved
2026-06-26 17:02:09.690 - info: poolcontrol.0 (1757178) [pumpHelper] Pump error resolved

Und noch eine Frage zu deinem Blocky. Geht es dir nur da drum dass die Pumpe zu der Uhrzeit laufen darf ? Pool Control hat auch ein Zeit Modus

Schwierig kann es auf jeden Fall werden, wenn du eine externe Logik mit der interne Logik vermischt

Ich versuche es mal so zu erklären:
ich hätte gerne Zeit und PV verknüpf wie in meinem Skript mit folgender Logik:

• im Zeitraum a-b jede Stunde für Y Minuten die Pumpe einschalten

Abhängig von der Prognose von der Leistung des BKW / PV (bei mir getrackt über PV-Prognose) gibt es zwischen 10 bis 17Uhr eine längere Laufleistung der Pumpe, allerdings unabhängig von tatsächlicher, momentaner Leistung des BKW und unabhängig vom Gesamtbezug des Hauses

• alternativ wäre auch ein Intervall vorstellbar: alle X-Minuten für Y-Minuten die Pumpe einschalten im Zeitraum a-b

ich hänge mal mein Blockly an, vllt wirds dann verständlicher: common.Poolpumpe_variableZeit.xml

Danke für den sehr entspannten Austausch hier im Thread!

sonnigen Pooltag Euch gewünscht!

[DasBo1975]

@RikDRS sagte:

@DasBo1975 sagte:

@RikDRS sagte:

Dann habe ich eine weitere Frage zu dem Adapter:
wenn ich die Pumpe nun "extern" per Skript starte, stellt sich die Pumpe nach 60Sekunden wieder ab, der Datenpunkt

poolcontrol.0.pump.status

zeigt dann Fehler an. Das ist ein / der Schutzmechanismus

Wie kann ich das Umgehen bzw einstellen, das mein Skript die Pumpe trotzdem steuern darf?

Guck dann mal bitte im Log nach welcher Fehler dir ausgegeben wird.
hier das gewünschte Log:

2026-06-26 17:02:05.856 - warn: poolcontrol.0 (1757178) [pumpHelper] Fehler: Pumpe EIN, aber keine Leistung!
...
2026-06-26 17:02:09.685 - info: poolcontrol.0 (1757178) [pumpHelper] Pump error resolved
2026-06-26 17:02:09.690 - info: poolcontrol.0 (1757178) [pumpHelper] Pump error resolved

Und noch eine Frage zu deinem Blocky. Geht es dir nur da drum dass die Pumpe zu der Uhrzeit laufen darf ? Pool Control hat auch ein Zeit Modus

Schwierig kann es auf jeden Fall werden, wenn du eine externe Logik mit der interne Logik vermischt

Ich versuche es mal so zu erklären:
ich hätte gerne Zeit und PV verknüpf wie in meinem Skript mit folgender Logik:

• im Zeitraum a-b jede Stunde für Y Minuten die Pumpe einschalten

Abhängig von der Prognose von der Leistung des BKW / PV (bei mir getrackt über PV-Prognose) gibt es zwischen 10 bis 17Uhr eine längere Laufleistung der Pumpe, allerdings unabhängig von tatsächlicher, momentaner Leistung des BKW und unabhängig vom Gesamtbezug des Hauses

• alternativ wäre auch ein Intervall vorstellbar: alle X-Minuten für Y-Minuten die Pumpe einschalten im Zeitraum a-b

ich hänge mal mein Blockly an, vllt wirds dann verständlicher: common.Poolpumpe_variableZeit.xml

Danke für den sehr entspannten Austausch hier im Thread!

sonnigen Pooltag Euch gewünscht!

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

Ich glaube, jetzt verstehe ich deutlich besser, was dein Blockly eigentlich machen soll. Korrigiere mich bitte, falls ich dich falsch verstanden habe.

Für mich sieht es momentan so aus, als ob dein Blockly gar keinen klassischen PV-Überschussbetrieb umsetzen möchte.

Stattdessen nutzt es die PV-Prognose, um die Laufzeit der Pumpe abhängig von der erwarteten PV-Leistung zu variieren. Also beispielsweise:

• 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.

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.

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.

[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.