NEWS
Test Adapter PoolControl
-
@dennismenger sagte in Test Adapter PoolControl:
@dasbo1975 Ich habe 2 Ordner pump gefunden

OK. Deine Pumpe ist von dir händisch ausgeschaltet worden. "pump_mode = Aus (off)"
Das heißt, keine Automatik bzw. keine Zeitsteuerung aktiv. Wenn du in diesem Modus die Pumpe einschaltest "pump_switch" dann greift die Sicherheitsschaltung wie ich es gestern beschrieben hatte. Ähnlich wie im Modus "manuell" auch da greift dieser Sicherheitsmodus der die Pumpe wieder ausschaltet wenn nicht klar ist warum sie an ist.
Das ist der Control Ordner. In diesem Pumpenbereich kannst du die Wartung bzw. das Rückspülen starten.
Beschreibung hierzu auf Githup im Wiki direkt auf der Home Seite
LG
Dirk -
Guten Morgen, ich nochmal.
Ich habe gestern den Adapter noch einmal komplett gelöscht, alle Objekte entfernt und den Adapter komplett neu installiert. Alles eingerichtet und über die Zeitsteuerung getestet. Das hat auch alles funktioniert.
Jetzt habe ich folgendes Verhalten beim Adapter festgestellt.
Poolsaison im Adapter: nicht Aktiv
Pumpenmodus: Zeit
Zeitfenster 2: aktiv und Start 9.00 UhrUnd die Pumpe ist um 9.00 Uhr angesprungen. Das soll so wahrscheinlich nicht sein oder?
Bin dann mal alle Datenpunkte durchgegangen und habe festgestellt, dass es 2 Datenpunkte zum Thema "Poolsaison Aktiv/nicht aktiv" gibt.
- poolcontrol/0/control/season/active
- poolcontrol/0/status/season_active
Folgende Verhalten beim Schalten über Adapter und den Datenpunkten habe ich festgestellt:
Schalten/Haken "Poolsaison Aktiv" über den Adapter => poolcontrol/0/control/season/active => keine Reaktion und poolcontrol/0/status/season_active => wird geschaltet
Händisches Schalten über den State poolcontrol/0/control/season/active => State poolcontrol/0/status/season_active wird auch geändert
Händisches Schalten über den State poolcontrol/0/status/season_active => State poolcontrol/0/control/season/active wird nicht geändert
Wie hängen diese beiden States miteinander zusammen?
Ich hoffe das war einigermaßen klar was ich da so zusammengeschrieben habe. -
@dennismenger sagte in Test Adapter PoolControl:
Guten Morgen, ich nochmal.
Ich habe gestern den Adapter noch einmal komplett gelöscht, alle Objekte entfernt und den Adapter komplett neu installiert. Alles eingerichtet und über die Zeitsteuerung getestet. Das hat auch alles funktioniert.
Jetzt habe ich folgendes Verhalten beim Adapter festgestellt.
Poolsaison im Adapter: nicht Aktiv
Pumpenmodus: Zeit
Zeitfenster 2: aktiv und Start 9.00 UhrUnd die Pumpe ist um 9.00 Uhr angesprungen. Das soll so wahrscheinlich nicht sein oder?
Bin dann mal alle Datenpunkte durchgegangen und habe festgestellt, dass es 2 Datenpunkte zum Thema "Poolsaison Aktiv/nicht aktiv" gibt.
- poolcontrol/0/control/season/active
- poolcontrol/0/status/season_active
Folgende Verhalten beim Schalten über Adapter und den Datenpunkten habe ich festgestellt:
Schalten/Haken "Poolsaison Aktiv" über den Adapter => poolcontrol/0/control/season/active => keine Reaktion und poolcontrol/0/status/season_active => wird geschaltet
Händisches Schalten über den State poolcontrol/0/control/season/active => State poolcontrol/0/status/season_active wird auch geändert
Händisches Schalten über den State poolcontrol/0/status/season_active => State poolcontrol/0/control/season/active wird nicht geändert
Wie hängen diese beiden States miteinander zusammen?
Ich hoffe das war einigermaßen klar was ich da so zusammengeschrieben habe.Huhu
Schaue ich mir später an.
Lg.
-
🧩 Hinweis zu control.season.active
In der aktuellen Version des PoolControl-Adapters wird der Datenpunkt
poolcontrol.0.control.season.active nicht mehr benötigt.Er war ursprünglich als Alias-Spiegelung zu status.season_active gedacht,
wird aber seit Version 0.3.x nicht mehr aktiv verwendet und kann daher bedenkenlos gelöscht werden.Wer den Punkt noch im Objektbaum sieht, kann ihn einfach entfernen:
-
@DasBo1975 Vielen Dank für deine schnellen Reaktionen bei Problemen.
Leider habe ich weiterhin das Problem, dass die Pumpe bei Überlast abschaltet. Siehe Screenshots aus dem Log.


@dennismenger sagte in Test Adapter PoolControl:
@DasBo1975 Ich teste den Adapter auch gerade ein wenig. Ich habe aktuell das Problem, dass der Adapter die Pumpe meist nach ca. 1 Minute wieder ausschaltet mit der Meldung "Pumpe läuft unterhalb des Normalbereiches".
Meine Pumpe ist eine Speck Badu Magic II 6, die mit einer Leistungs-Aufnahme von 450 Watt angegeben ist. Diesen Wert habe ich dann im Adapter Poolcontrol bei der maximalen Leistung der Pumpe eingetragen. Wenn die Pumpe ein paar Stunden nicht gelaufen hat, startet die Pumpe meist mit einer Leistungsaufnahme von 470 Watt. Das dauert dann ein paar Minuten bis sie sich so bei 440 bis 445 Watt einpendelt. Ich vermute, dass aus diesem Grund der Controller einen Fehler vermutet und die Pumpe wieder ausschaltet.
Gibt es irgendwie eine Möglichkeit da einen Puffer einzustellen? Oder ab wie viel Prozent Abweichung schaltet der Controller die Pumpe dann mit einem Fehler wieder aus?
-
Hallo @DennisMenger,
vielen Dank nochmal für deine ausführliche Rückmeldung und die Screenshots – die haben mir sehr geholfen, den Auslöser genau zu finden.
Ich habe daraufhin zwei Punkte im Adapter angepasst, um das Verhalten realistischer und stabiler zu machen:
🧠 1. Lern-Toleranz jetzt einstellbar
Im Bereich pump.learning.tolerance_percent gibt es jetzt einen neuen, dauerhaft gespeicherten Datenpunkt.
Damit lässt sich einstellen, wie stark Leistung und Durchfluss vom gelernten Normalbereich abweichen dürfen,
bevor der Adapter eine Meldung wie „Pumpe läuft unterhalb / oberhalb des Normalbereichs“ ausgibt.Standardwert ist 20 %.
Das ist vor allem hilfreich für Pumpen, die sich nach dem Start erst einpendeln oder bei unterschiedlichen Temperaturen leicht schwanken.
️ 2. Überlastschutz angepasst (feste 10 %-Toleranz)Bisher hat der Adapter schon bei kleinsten Überschreitungen des Maximalwerts abgeschaltet.
Das führte bei manchen Pumpen – wie deiner Speck Badu Magic II 6 – zu unnötigen Stopps direkt nach dem Start.Ich habe den Überlastschutz jetzt mit einer fest eingebauten 10 %-Toleranz versehen, die bewusst nicht veränderbar ist.
Damit bleibt der Schutz aktiv, aber kleine Leistungsspitzen beim Anlauf werden ignoriert.
Ich wollte vermeiden, dass jemand versehentlich eine zu hohe Toleranz einstellt und die Pumpe dadurch überlastet.Ein kurzes Rechenbeispiel:
Eingetragene Maximalleistung: 450 W
→ Sicherheitsgrenze (+10 %): 495 W
→ Abschaltung erst ab > 495 WOder anders gesagt:
450 W eingetragen = Abschaltung erst bei über 495 W
600 W eingetragen = Abschaltung erst bei über 660 W
🧩 Fazit
Lernsystem jetzt anpassbar → keine falschen „unterhalb Normalbereich“-Meldungen mehr
Überlastschutz bleibt aktiv, aber praxisgerecht entschärft
Keine Änderungen an bestehenden Einstellungen notwendig
Danke dir nochmal für die Rückmeldung – solche Hinweise aus der Praxis helfen mir wirklich sehr, um PoolControl weiter zu verbessern.
Viele Grüße
Dirk -
@dasbo1975 Vielen Dank für die ausführliche Rückmeldung und zügige Anpassung. Schon krass zu sehen wie viel Arbeit du da investierst. Werde die neue Version umgehend installieren und testen und dir definitiv eine Rückmeldung geben.
Schönes Wochenende.
-
Letztendlich ist es doch nicht nur meine Zeit die dabei drauf geht. Es ist auch eure, die ihr mit dem Testen verbringt. Ich bin genauso dankbar.
-
Hallo, ich habe da einige DP die nicht beschrieben werden, kann ich die löschen?
Die Runtime im Wartungsmodus wird nicht erfasst?
-
@sigi234 sagte in Test Adapter PoolControl:
Hallo, ich habe da einige DP die nicht beschrieben werden, kann ich die löschen?
Die Runtime im Wartungsmodus wird nicht erfasst?
Kurzes Update von mir – es waren tatsächlich zwei getrennte Fehler:
-
Runtime im Wartungsmodus / Rückspülen
Die Start-/Stopperkennung im runtimeHelper war zu eng. Ich habe sie so angepasst, dass jede Änderung von pump.pump_switch sicher erkannt und gezählt wird – unabhängig davon, ob die Pumpe über Solar, Frost, Zeit, Wartung, Rückspülen oder manuell gestartet wurde.
Zusätzlich aktualisiert die Live-Anzeige jetzt alle 10 Sekunden, sodass Current Session, Today und die temporäre Season Total während des Laufens sichtbar steigen. Die endgültigen Werte für Total/Season Total werden wie gewohnt beim Stop festgeschrieben. -
Status-Datenpunkte (Last Start / Last Stop / Today Count / Was On Today)
Diese vier status.*-DPs wurden bisher nicht beschrieben. Ich habe die Logik ergänzt, sodass bei Pumpenstart pump_last_start, pump_today_count, pump_was_on_today gesetzt werden und beim Pumpenstopp pump_last_stop. Damit werden die Status-Infos jetzt konsistent gepflegt.
Bitte die aktuelle GitHub-Version installieren und kurz Rückmeldung geben, ob beides bei dir passt:
a) Runtime zählt im Wartungsmodus/Rückspülen mit und zeigt währenddessen an,
b) Status-Datenpunkte werden korrekt geschrieben. -
-
@dasbo1975 sagte in Test Adapter PoolControl:
Bitte die aktuelle GitHub-Version installieren und kurz Rückmeldung geben, ob beides bei dir passt:
a) Runtime zählt im Wartungsmodus/Rückspülen mit und zeigt währenddessen an,
b) Status-Datenpunkte werden korrekt geschrieben.Gerade einen Wartungsmodus gestartet:

-
@sigi234 sagte in Test Adapter PoolControl:
@dasbo1975 sagte in Test Adapter PoolControl:
Bitte die aktuelle GitHub-Version installieren und kurz Rückmeldung geben, ob beides bei dir passt:
a) Runtime zählt im Wartungsmodus/Rückspülen mit und zeigt währenddessen an,
b) Status-Datenpunkte werden korrekt geschrieben.Gerade einen Wartungsmodus gestartet:

Puh.
Ich habe das bei mir auf zwei Systemen am laufen (Test und Produktivsystem)
und nach der Änderung von letzter Nach läuft das bei mir.Hast du die Saison Aktiv? Sonst würde mir gerade nichts einfallen warum es bei dir nicht hin haut.
-
@dasbo1975 sagte in Test Adapter PoolControl:
Hast du die Saison Aktiv?
Ja
Edit,
läuft jetzt nach einen Update. Hatte von NPM installiert und nicht von GITHUB
-
@sigi234 sagte in Test Adapter PoolControl:
@dasbo1975 sagte in Test Adapter PoolControl:
Hast du die Saison Aktiv?
Ja
Edit,
läuft jetzt nach einen Update. Hatte von NPM installiert und nicht von GITHUB
Ah OK. dann Mach ich Putty erstmal wieder zu. Auf NPM lege ich nur die Version ohne eventuelle Bufixes. Darum ist, solange getestet wird, Github unser freund
Danke für deine Mühe

-
@dasbo1975 said in Test Adapter PoolControl:
@sigi234 sagte in Test Adapter PoolControl:
@dasbo1975 sagte in Test Adapter PoolControl:
Hast du die Saison Aktiv?
Ja
Edit,
läuft jetzt nach einen Update. Hatte von NPM installiert und nicht von GITHUB
Ah OK. dann Mach ich Putty erstmal wieder zu. Auf NPM lege ich nur die Version ohne eventuelle Bufixes. Darum ist, solange getestet wird, Github unser freund
Danke für deine Mühe

An sich spricht aber nichts gegen ein Testen via npm. An sich wird von direkten Installationen direkt von Github ABGERATEN da sich diese auch sehr kurzfristig ändern können,
Was du mit "Auf NPM lege ich nur die Version ohne eventuelle Bufixes." genau meinst ist mir allerdings nicht klar. Ich hoffe doch dass du auf npm nicht nur Versionen ohne Bugfixes (= also MIT Bugs) legst :-).
Im Ernst:
Schau dir das Releasescript mal genauer an. An sich gibt es für Zwischenversionen die Funktiond er ALPHA Releases. Wen du das standard deploy Verfahren verwendest kommen die auf npm aber nicht ins repository. Ideal für Tester da da kein irrtümlicher Update passiert aber eine genau definierte Version für Rückmeldungen existier. -
@mcm1957 sagte in Test Adapter PoolControl:
@dasbo1975 said in Test Adapter PoolControl:
@sigi234 sagte in Test Adapter PoolControl:
@dasbo1975 sagte in Test Adapter PoolControl:
Hast du die Saison Aktiv?
Ja
Edit,
läuft jetzt nach einen Update. Hatte von NPM installiert und nicht von GITHUB
Ah OK. dann Mach ich Putty erstmal wieder zu. Auf NPM lege ich nur die Version ohne eventuelle Bufixes. Darum ist, solange getestet wird, Github unser freund
Danke für deine Mühe

An sich spricht aber nichts gegen ein Testen via npm. An sich wird von direkten Installationen direkt von Github ABGERATEN da sich diese auch sehr kurzfristig ändern können,
Was du mit "Auf NPM lege ich nur die Version ohne eventuelle Bufixes." genau meinst ist mir allerdings nicht klar. Ich hoffe doch dass du auf npm nicht nur Versionen ohne Bugfixes (= also MIT Bugs) legst :-).
Im Ernst:
Schau dir das Releasescript mal genauer an. An sich gibt es für Zwischenversionen die Funktiond er ALPHA Releases. Wen du das standard deploy Verfahren verwendest kommen die auf npm aber nicht ins repository. Ideal für Tester da da kein irrtümlicher Update passiert aber eine genau definierte Version für Rückmeldungen existier.Danke für den Hinweis!

Ich meinte natürlich, dass ich auf npm nur stabile Versionen veröffentliche – also ohne offene Bugfixes.
Die laufenden Tests und Zwischenstände lade ich bislang direkt über GitHub, aber dein Hinweis zu den Alpha-Releases ist sehr hilfreich.
Ich werde künftig für solche Testversionen npm run release alpha verwenden, damit definierte Zwischenstände auch über npm verfügbar sind.
-
Damit's nicht falsch rüberkommt:
Es ist voll ok wenn TESTER von Github installieren wenn es um "experimentelle" Versionen geht. Beispielsweise weil du irgendwo 20 'juhu' debugge eingebaut hast oder irgendwo ein hardcoded Wert mal zum ausprobieren drinnen steht den du ev alle 5 Miniuten für einen neuen Test änderst während du mit einem User zusammen eine Problem suchst.
Prinzipiell ist es nur so, dass "echtes" Teste, sprich beobachten eienr Version über Tage mit einer Versionsnummer nachvollzeihbarer ist. Da hast du dann auch die Info wenn ein User sagt bei mir gehts nicht dass du sehen kannst dass er ja noch die .alpha.5 verwendet während ees schon die .9 gibt ...
Echt abgeraten wird von Github installationen auf produktiven Systemen sofern der User nicht wirklich weiß was er tut...