Öffentliches Forum
  - Wärmepumpen

@McMagellan58 Du bist doch bei den Rules fitter als ich, kannst du hier mal drüber gucken?
Ich habe mal versucht den "Kickstart" etwas von Text und Variablen zu befreien um den Speicher vielleicht etwas zu entlasten. Eigentlich sollte das doch genau wie vorher funktionieren, oder? Bevor ich meinen laufenden Test unterbreche, würde ich gern eine Meinung hierzu einholen ;-)
Bei mir ist das so aufgebaut, ich habe einen Starttimer, der dann die gewünschten Module aufruft:

Dann kommen die eigentlichen Rules, hier mal "Kickstart"

@Quiet_Mode_Schedule habe ich erstmal drin gelassen um die Regel abschaltbar zu machen und #KickStarts sollte vorläufig als Zähler dienen. Kann eventuell später noch raus.

Momentan fahre ich gerade einen Test mit waagerechter Heizkurve und Steuerung des VL nach AT über SWV. Damit läuft HeishaMon nun auch schon 14 Tage absturzfrei durch. Allerdings gibt/gab es da noch nicht viel zu steuern, ich bin bisher mit VL 26°/27° ausgekommen.

Sieht doch gut aus und es wird auf den ersten Blick auch funktionieren.
Was ich hieraus lese ist:

Prüfe während einer Taktpause im normalen Heizbetrieb alle 3 Minuten ob die VLT die VLTsoll um mehr als 3K unterschritten hat. Wenn ja dann provoziere für 15 Sekunden eine SWV Erhöhung. Sperre anschliessend für 15 Minuten die weitere Prüfung.

Bei mir verwende ich anstelle der Variable "Pause" die Variable "Stat" für Status. In der bilde ich bis zu 10 verschiedene Betriebsarten ab und sie ist die wichtigste Steuervariable im Programm.

Aus mir unerfindlichen Gründen kommt Rules bzw Heishamon manchmal durcheinander und verschluckt sich bei den Variablen. Dann gibt es dauerhaft zwei Variablen gleichen Namens ??? bei denen eine den Wert "NULL" hat. Was passiert nun wenn deine "Pause" plötzlich den Wert NULL annimmt? Gleiches gilt für "StartDelta" was ich bei mir schon hatte. Hier ist die Abhilfe einfach indem du den Wert als Konstante in die Formel einträgst und auf die Variable verzichtest. Bei "Pause" würde ich einfach einen Check im Timer10 machen wie etwa (if Pause == NULL then Pause = 0). Das habe ich aber bisher noch nicht probiert ob NULL so behandelt werden kann!. Also einfach eine Korrektur falls notwendig, die macht auch nichts kaputt. Ein Watchdog?

Hier mal ein Auszug aus Console der zeigen soll was ich mit den Varablen meine.




Bin grade dabei die Flüstermodus- Chain neu anzupassen nachdem es wieder Starts dank gestiegenen ATs gibt.

Das hatte ich anfänglich auch, habe das dann aber immer darauf geschoben, dass beim Start wohl nicht alle Werte von der WP eingelesen waren.
Wenn das nun auch während des Betriebes auftritt, ist das natürlich blöd.
Seit dem Letzen Reboot vor zwei Wochen, konnte ich das aber auch nicht mehr beobachten. Allerdings habe ich auch nicht viele Variablen, die aktualisiert werden müssen.

Das hattest du auch schon? Ich war bisher der Meinung, dass das nur mit Variablen passiert, die durch Rules selbst verändert werden und nicht bei Festwerten.

Gute Idee, ich kann das aber im Moment auch nicht testen. Muss ich mal im Hinterkopf behalten.
Wenn ich mir das "Regelwerk" hier ansehe, muss es doch eigentlich mit Variablen im Normalfall gut funktionieren.

Was hast du dir denn beim FM wieder neu ausgedacht? Hat doch bei dir gut funktioniert, oder?

Das Problem war das die letzte Zeit die WP nicht mehr getaktet hat und daher die korrigierte Hysterese nicht beobachtet werden konnte.

Nachdem ich aber gesehen habe das nicht nur im AT- Bereich von +3 bis -3 die WP abtaute sondern auch bis in tiefe Minusgrade fast stündlich habe ich umgeschaltet auf Gas und die WP erfrieren lassen. Konnte dabei auch ausgiebig die Frostschutzfunktion testen.

Bei Minusgraden ist die FM- Korrektur kontraproduktiv und bremst die WP ein obwohl die volle Leistung gebraucht wird. Ich habe dann eine Abfrage geschaltet die bei AT unter 1°C die FM- Korrektur auslässt. Dann werde ich bei AT unter 5° eine Kette von 5Min FL2 + 5 Min FL1 schalten. Darüber gibts das volle Programm allerdings zeitverkürzt. 3Min FL3 + 3Min FL2 + 3Min FL1. Und das habe ich gestern ab 12 Uhr geschaltet.

Vorher von 1 Uhr bis 13 Uhr habe ich den Flüstertimer aktiviert weswegen Rules deaktiv wird. Das ist alles schön in der neuen mir iobroker erstellten folgenden Grafiken zu sehen. An der dunkelblauen Linie ist zu sehen wie Rules arbeitet sowohl beim definierten StartKick als auch bei der Schaltung des Bonusgrads. So erreiche ich längere homogenere Laufzeiten.





Interresant ist die Gegensätzlichkeit des Kompressorprofils zum VLT- Profil.
Entweder ist die VLT schnurgrade und die Kompressorleistung krumm oder die Kompressorleistung grade und die VLT- Linie krumm. ???

Ich denke, das hängt mit dem Flüstermodus zusammen. Der holt den Kompressor schnell runter, deshalb steigt der VL nur langsam an. Dann kommt das Bonusgrad und der VL steigt weiter.
Bei den Takten ohne FM kommt der VL schnell hoch und bleibt dann gleich während der Kompressor langsam runter regelt.

Ich weiß immer noch nicht, wie ich die Startüberschüsse am besten ausbremse. Mit @SetPump funktioniert das zwar gut, aber ich weiß nicht, ob das so "gesund" ist. Am Bedienteil ist während des Eingriffs auch immer das Servicemenü zu sehen.
Vielleicht komme ich auch nochmal auf den FM zurück, um das umzusetzen. Momentan ist das aber kein Thema, da ich das Problem nur bei 25° VL habe.
Jetzt wo ich mit 26° und 27° fahre, gibt es keine Abbrüche mehr. Die UWP kommt zwar immer noch spät, aber rechtzeitig hoch.

Was die doppelten Variablen mit NULL angeht, magst du da nicht mal ein Issue aufmachen? Du kannst das doch sicher besser erklären, falls dann Nachfragen kommen. Bei mir tritt das ja momentan nicht auf.

Wünsche schöne Feiertage und eine warme Bude.
Gruß Jörg

Vielleich kann bei meinen Rules auch wer drüber schauen, irgendwie funktionierts leider nicht wie gewünscht.

Was sollen die Rules bei mir bezwecken.

1. Umschaltung von DHW auf Heat wenn mit WW fertig. Funktioniert perfekt.
2. Hier muss ich ein bisschen ausholen, es geht ums WW. Mein WW-Speicher hat zwei Positionen die WW-Temperatur abzugreifen, einmal ein bisschen über den Rücklauf und einmal über dem Vorlauf auf ca. 2/3 des Speicher. Die Position über dem Rücklauf möchte ich nicht verwenden, da die WP dann mit sehr hoher Leistung das WW macht, mit eher geringem AZ. Die zweite Position würde passen, jedoch kann es passieren, dass die WW-Temperatur noch zu hoch ist und die WP den WW-Betrieb nicht startet.

Meine WW-Starts werden immer mittels Wochentimer gestartet. Damit der WW-Takt auf jeden Fall startet, wird die Zieltemperatur auf z.B. 49°C gestellt (ich möchte den Speicher aber zumindest in der Nacht nicht so weit aufladen, die Temperatur soll nur für die morgendlichen Duschen reichen). Somit reduziere ich mit einem zweiten Wochentimer die Temperatur nach einigen Minuten auf z.B. 45°C. Jetzt kann es aber sein, dass der Speicher noch eine Temperatur von 46°C im oberen drittelt hat und die WP beendet den WW Takt.

Hier sollen dann die Rules von Heisahmon eingreifen, und zwar soll außer im WW-Betrieb immer die letzte Speichertemperatur zwischengespeichert werden. Wenn im WW-Betrieb eine neue Zieltemperatur gesetzt wird, soll Rules prüfen, ob die Zieltemperatur geringer als die zwischengespeicherte Temperatur ist. Trifft dies zu, so soll die Zieltemperatur höher gesetzt werden.

Leider macht mein Script dies nicht. Vielleicht findet jemand in meinem Script den Fehler, sind nur ein paar Zeilen Code.

on @DHW_Temp then
if @DHW_Temp >= @DHW_Target_Temp && @Compressor_Freq == 0 && @Operating_Mode_State != 0 then
@SetOperationMode = 0;
end
if @Operating_Mode_State != 3 then
#LastDHWTemp = @DHW_Temp;
end
end

on @DHW_Target_Temp then
if @Operating_Mode_State == 3 && @DHW_Target_Temp <= @DHW_Temp && #LastDHWTemp > @DHW_Target_Temp then
@DHW_Target_Temp = (#LastDHWTemp + 1);
end
end

Edit: Code noch als Bild



LG Hannes

Was passiert denn jetzt überhaupt, bzw. was funktioniert nicht?
Ich bin auch nicht so der Crack, was Rules angeht, aber die Klammern kannst du wohl bei @DHW_Target_Temp = (#LastDHWTemp + 1) weg lassen.
Vielleicht meldet sich @McM noch, der ist da schon weiter ;-)

Das Hochsetzen der Zieltemperatur erfolgt nicht, das Zwischenspeichern der letzten DHW-Temp dürfte passen.

Habe einfach mal drüber geschaut ohne den Programmablauf zu kennen.

Verändere mal die Zeile:
@DHW_Target_Temp = (#LastDHWTemp + 1);

in
@SetDHWTemp = #LastDHWTemp + 1;

Ich meine das alle Schreibbefehle in die WP mit @Set anfangen. Schau mal in der Liste nach wie der Syntax dafür sein muss. Hab sie grad nicht greifbar.

Stimmt das ist mir gar nicht aufgefallen, habe nur auf die Klammern geschaut.
Irgendwie werde ich langsam (Betriebs-)blind ;-)

Danke MC, @SetDHWTemp wird es gewesen sein. Ich habe meine Rules mal angepasst und nun muss ich halt beobachten ob diese umgesetzt wird.

Wie zufrieden seid ihr mit der AT Dämpfung wenn es zügig wärmer wird? Heute gibts bei uns 15° und die Heizkurve kommt entsprechend langsam hoch, so dass er die Kurve eigentlich gefühlt unnötig lange oben hält und immer noch heizt.

Ich bin eigentlich sehr zufrieden, da die WP jetzt wesentlich ruhiger laufen kann. Habt ihr etwas eingebaut, das solche Änderungen berücksichtigt oder kann Mans vernachlässigen.

Meine AT Dämpfung ist mit 8 Messwerten in 2 Std. nicht so hoch, damit verhindere ich eigentlich nur das hin- und herspringen der AT. Du rechnest ja anders, wenn ich mich recht erinnere.
Mittlerweile habe sie aber sogar deaktiviert und fahre mit Festwert VL von 26°C. Wenn ich dann mal irgendwann weiß, wann ich mal 1K hoch oder runter muss, werde ich das automatisch versuchen.

Erstmal ein frohes neues Jahr von mir in die Runde.

Ich fahre was die Dämpfung angeht mit einem Mittel aus 4 Messwerten der letzten 3 Stunden. Ich will damit nur das Zappeln unterbinden und die Spitzenwerte rausnehmen. Zur Zeit ist das aber nicht in Funktion weil die AT über meinem Grenzwert von 9°AT liegen weswegen permanent die VLTsoll immer dem oberen Grenzwewert entspricht. Also abwarten, es wird noch anders werden. Da ich neben der FBH auch noch Radiatoren habe muss ich mit dem VL der AT halbwegs zeitnah folgen.

Dann wollte ich mal zeigen wie das aussieht wenn zwei Variablen unter gleichem Namen existieren.

In dieser Variable ist die Differenz abgelegt ab wieviel °C bei Unterschreitung des VL zur VLsoll der Startkick gesetzt wird. In diesem Fall hier fand er nicht mehr statt.

Ich habe jetzt von der Excel-JSON-Abfrage umgestellt auf IObroker-MQTT auf Raspberry Pi Bullseye. Seit ich den zwischenzeitlichen Parallelbetrieb eingestellt habe kam es nicht mehr vor. Es ist also möglich das Heishamon-Rules dabei überfordert war.

Doppelte Variablen bzw. NULL hatte ich nicht mehr, seit dem ich die Variablen, die mit Systemwerten gefüllt werden sollen, nicht mehr direkt über System#Boot fülle.
Ich definiere sie jetzt über einen Timer erst 40 Sek. nach Reboot.
Was bei jetzt aber schon zweimal hatte, bei meinem KickStart wurde die #Pause nicht nach 15 Min. auf 0 zurückgesetzt, sodass der Start natürlich nicht mehr ausgeführt wurde. Da bin ich der Ursache noch nicht auf die Schliche gekommen.

Weil es im Moment so warm ist, muss ich mich aber erst mal wieder um den Startüberschuss kümmern.
Was sehr gut funktioniert ist mit fester Pumpendrehzahl fahren und den dann bei Beginn und Ende eines Heiztaktes mit @Max_Pump_Duty hoch und wieder runter zu setzen. Beim Abtauen und WW ist kein Eingreifen nötig, da macht sie eh was sie will.
Ich bin mir nur nicht sicher, ob das eventuell Einfluss auf die Lebensdauer des Flash hat, deshalb experimentiere ich nun doch noch einmal mit dem Flüstermodus oberhalb 5° AT.

Hallo erstmal und ein gutes neues Jahr,
hab bis jetzt gerne mitgelesen und bin sehr dankbar über Beiträge zur Umsetzung Heishamoon Steuerung Luftwämrpeumpe.
Hab selber die Heisamoon mit Jeisha 7kW seit Frühjahr 2022 zusammen mit Loxone Hausautomatisierung im Betrieb. Loxone schickt per http Reqest die Befehle an Heishamoon, die Rückmeldung kommt per MQTT über Rasperry (Loxberry) wieder auf den Miniserver (Loxone).
Bis jetzt hat alles einwandfrei funtkioniert, fahre fixen Vorlauf mit fixen Volumstrom (ca. 19l/min), falls draußen kalt bzw. Bude kalt, dann stelle ich über Loxone 1-2Grad höher und lasse sie wieder 2-3 Tage so laufen.
Warmwasser wird an 2 Zeiten am Tag auch automatisch über Loxone gemacht, kann dann selber übers App die Zeiten und die höhe des Warmwassers einstellen.
Am Anfang hatte ich noch das Problem, dass nach Rükschalten vom WW auf Heizen der Kompressor nicht mehr angesprungen ist, geht jetzt aber mit einer Automatikregel "Smart Grid" Erhöhung Heizen und Warmwasser für 40sek. auch ohne Probleme.

Momentan kämpfe ich aber leider mit einem automatischen Abschalten der Jeisha. Das Problem scheint anscheinend mit dem Verlust der WLAN Verbindung der Heishamoon, bzw. umschalten der WLAN Verbindung auf den Router im Dachgeschoss zusammen zu hängen. Sobald Heishamoon keine Wlan Verbindung hat, schaltet sich die Jeisha ab. Hab jetzt als Notlösung eine Rule über Loxone kunfiguriert, wenn Jesiha ausgeschalten ist, Meldung ans Handy und automatische ein nach 180sek. Das funktioniert zumindest.

Jetzt meine Frage, habt ihr ähnliches schon mal beobachten können?
Heishamoon ist bei mit noch auf Ver. 2.0. Liegt es eventuell daran? Habt ihr schon 3.0 am Laufen?
Vielen Dank für eure Hile,
Lg,
Martin

Also ich denke, alle die hier bisher mit diskutiert haben sind mit FW 3.x unterwegs. Die Rules sind ja erst mit 3.0 eingeführt worden.

Dass die WP bei WLAN Verlust von HeishaMon aus geht, habe ich noch nicht gehabt. Normal läuft sie dann weiter, man kann sie dann halt nur nicht mehr extern steuern.
Hast du eventuell die Emulation der optionalen Platine aktiviert? Dann soll die Jeisha ja empfindlich reagieren, wenn HeishaMon nicht schnell genug antwortet, was ja bei WLAN Verlust der Fall sein kann.

Dachte ich eigentlich am Anfang auch, wenn WLAN Verbidnung nicht mehr vorhanden ist, sollte die Jeisha normal weiterlaufen. Macht sie aber leider nicht.

Ok dann wird es mal Zeit auf 3.0 upzudaten. War ja bis jetzt bei mir nicht wirklich notwendig.

Emulation der optionalen Platine ist auch bei mir angehackt. Werde ich mal deaktiviern und weiter beobachten, ob dieses Problem weiter auftritt.

Vielen Dank einmal.

Ich hatte zum Test auch mal die Simulation der Zusatzplatine aktiviert und diese dann in der Programmierung freigeschaltet. Dann entsteht ordentlich Meldungsverkehr wie an der Console zu sehen ist. Habe dann mal die Leistungssteuerung mit URL- Command getestet und festgestellt, das die nach ein paar Sekunden wieder von der Hauptsteuerung durch eigene Werte verworfen wird und deshalb dauernd neu gesetzt werden müsste. Das ist mir die Sache um das Risiko der Störanfälligkeit nicht wert.

Daher konzentriere ich mich ja auf die Heishamon Rules weil ein WIFI- Ausfall oder der komplette Heishamon- Ausfall keine Auswirkungen hat auf die Hauptsteuerung.


Seit ich die Betriebsdatenerfassung nicht mehr parallel mit Excel mache läuft Rules stabil. Probiere mich jetzt mal mit der grafischen Daten Aufarbeitung im IObroker.
Hier mal die Haupt- Übersichtsgrafik mit 16 Datenlinien eigentlich total überfüllt. Das Chart beinhaltet eigentlich 5 Grafiken und soll Abhängigkeiten und Wechselwirkungen erkennbar machen. Detais werde ich dann mit eigenen Grafiken darstellen wie z.B. den Kältekreis. Jemand noch eine Idee dazu? Tue mich mit IObroker noch schwer und bin froh wenn er überhaupt läuft.

Ist ja echt ein bisschen viel in der Grafik ;-) Mit was stellst du das dar, Grafana ist das sicher nicht?
Würde ich mal probieren, denn da kannst du je nach Bedarf die benötigten Kurven ein- und ausblenden.
Was Rules angeht, läuft es momentan bei mir auch. Allerdings habe ich gerade auch nicht viel laufen. Prinzipiell sollte es auch zuverlässig sein, wen ich mir das Regelwerk von CurlyMoo auf github so ansehe.

Grafana war mir zu kompliziert. Das hier ist mit dem "ECharts" Adapter der in iobroker eingestellt ist realisiert. Einzelne Linien wieder rausnehmen zerstört allerdings die Grafik. Ich gehe z.Zt. davon aus, das es neben dieser Gesamtgrafik noch mehrere Themengrafiken geben wird.

Die obige Grafik soll in erster Linie zeigen wie sich der Rules- Eingriff auf das Gesamtsystem auswirkt.
1) Unten ist die Steuerung des Flüstermodus zu sehen mit den Auswirkungen auf die Kompressorfrequenz mit Heissgasentwicklung.

2) Darüber der Volumenstrom (DeltaModus mit 5° Spreizung bei 5KW Jeisha) und die beiden COP- Linien. Schwarz = COP aus externem WMZ mit externem Stromzähler, Grau = Jeisha- Interne COP- Berechnung die auch an der Fernbedienung angezeigt wird.

3) Aussentemperatur mit Grenzlinien der Heizkurve

4) VL / RL mit Sollwertvorgabe (violette Linie Soll ext) durch Heishamon- Heizkurve vorgegeben. Hier sind die Kicks, der Einsatz des Bonusgrads mit deren Auswirkungen zu sehen.

Die grüne Linie "Soll int" beschreibt hier wie die Jeisha- interne Regelung die Heizkurve vorgeben würde mit all dem Zappeln. Das gelingt mit einem Trick. Ich gebe einfach die Eckwerte der Heizkurve in die Parameter des zweiten Heizkreises, den ich nicht nutze, ein und logge dann diese Dummy- Vorgabe als Referenz in der Grafik mit.

5) Hier sind die WMZs, schwarz vom externen, grau vom internen (Heat Produktion). Darunter die Eingangsleistungen vom externen Stromzähler und von der internen "Stromschätzung". Dann noch in grün was die PV beisteuert und wenn grün größer schwarz läuft sie mit PV- Strom.

So kann ich in einer Grafik sehen ob und wie Heihamon eingreift. Für mich sieht es gut aus und sowohl Heishamon als auch der Raspberry mit iobroker laufen bisher gut.

Ich habe mal noch was neues entdeckt. Könnte interressant sein für die Leute die mit zu langem Pumpenschnüffeln zu tun haben.

Ich bin in meiner neuen Grafik am kämpfen mit der COP- Berechnung. In diesem Zusammenhang habe ich den Parameter "Flüssigkeit" mal von Wasser auf Glykol umgestellt in der Annahme das sich die Werte des internen Wärmemengenzählers (Heat Production) verändern was aber nicht passierte.

Stattdessen hat sich das Verhalten der Pumpe verändert hier zu sehen an der blauen Pump Flow Grafiklinie (markiert durch Kreise). Zwischen 13 und 1 Uhr und zur Verifizierung ab 9:30 war "Glykol" eingestestellt, ansonsten "Wasser".

Es sieht so aus, als ob sich der Schaltpunkt in den Taktpausen ab dem der Schnüffelmodus (in Betriebsart Delta T) verlassen wird verändert hat.
Roter Kreis = Glykol, violetter Kreis = Wasser
Die Pumpe fördert also eine ganze Weile vor dem nächsten Start mit erhöhter Leistung. Also wird der untere Hysteresepunkt der Pumpe im Glykol- Modus vorverlegt. Welcher Sinn dahinter steckt erschliesst sich mir noch nicht.


Vielleicht kann mir aber jemand eine Tip geben wie die Formel zur korrekten WMZ- Berechnung mit Wasser und Glykol aussehen muss. In dieser Sache komme ich einfach nicht weiter.

Danke für die Info! Sieht ja interessant aus und werde das auf jeden Fall mal testen. Einen Pumpenstart vor Taktbeginn habe ich noch nie gesehen und wäre sehr wünschenswert.
Denke aber, das eigentliche Problem liegt an irgendeiner Temperatur. Kurz nach dem WW fährt die Pumpe auch sofort bei Taktstart hoch, das "Weiterschnüffeln" tritt immer nach den Taktpausen auf, die bei mir schon mal 3-5h dauern können.
Momentan behelfe ich mir mit Rules und FM, jetzt wird bei Taktstart und AT > 5 FM = 2 und AT > =10 FM = 3 geschaltet bis die Pumpendrehzahl endlich bei min. 90% ist. Dann wieder auf FM = 0 zurück. Klappt bisher ganz gut.
Das sieht dann so aus. Wobei beim Start nach dem WW die Rule noch nicht korrekt war.

Was die COP Berechnung angeht, habe ich auch keine Ahnung. Hängt sicher auch mit der Konzentration des Gemisches zusammen.

Kannst du das mit der Einstellung Glykol auch noch einmal testen, wenn du die WP in den Winterschlaf schickst?
Wäre interessant zu wissen, ob die Frostschutzfunktion dann genauso wie vorher abläuft, oder eventuell gar nicht greift.

Habe mal eine alte Excel- Grafik rausgefischt in der das Ende des Winterschlafs zu sehen ist gefolgt vom Abtaugewitter.

Während der Kältephase habe ich die Parameter "Frostschutz" und "Flüssigkeit" in den Betriebsarten Normal, Bivalenz abgeschaltet und Extern gesperrt getestet. Bei Flüssigkeit habe ich keinerlei Veränderung erkennen können. Aufgeregt habe ich mich aber das in der Betriebsart Bivalenz abgeschaltet die Frostschutzfunktion obwohl aktiviert nicht ausgeführt wird. Grade dann währe sie doch wichtig wenn die Alternativheizung arbeitet und die WP im Frost schläft. Werde ich jetzt mit einem Thermostat und dem Sperrkontakt lösen.

Der Zustand des Schnüffelns in der Taktpause tritt natürlicherweise nur auf, wenn die WP wegen zu hoher Leistung bei min Modulation abschaltet. Das tritt bei mir nur bei AT über 5°C auf. D.h. bei darunterliegenden Temperaturen läuft sie durch, kein schnüffeln.

Ich bleibe aber bei meiner Theorie das nicht nur der Kompressor eine Hysterese hat sondern auch die Pumpe. Entweder sie moduliert hoch bis zur oberen Hysteresegrenze um dann wieder herunterzumodulieren bis zur niedrigen Hysteresegrenze. Wird dieser erreicht geht es wieder aufwärts. Dieser "virtuelle untere Pumpenhysteresepunkt" ist von einer Spreizung der VL oder RL Temp und der VLTsoll abhängig. Im Modus Flüssigkeit Glykol wird diese Spreizung verringert sodass sich die Pumpe früher wieder auf den Weg nach oben macht.

Der eigentliche Grund für das stundenlange schnüffeln liegt aber m.M.n. in den arg niedrigen VLT und RLT einzelner Installationen. Wie soll denn eine Spreizung entstehen wenn im VL nur mit ca 25° geheizt wird und der RL mit Ach und Krach 22° aus dem Estrichpuffer zurückkommt. Ich habe die Heizkurvengrenze auf min 27°C gesetzt und habe die Probleme nicht.