Öffentliches Forum
  - Wärmepumpen

@Frank_Pantry: Danke für die Einschätzung.

Mir ist bewusst, dass eine nicht in die Regelung eingebundene HK-Pumpe hinter einem Parallelpuffer regelungstechnisch nicht ideal ist. Unser primäres Ziel ist allerdings die akustische Reduktion, durch eine hydraulische und mechanische Beruhigung des Systems; einen regelungstechnischen Kompromiss würden wir dafür in Kauf nehmen, solange die Anlage dann noch störungsfrei läuft.

Ohne Entkopplung, also ohne Speicher und mit weiterhin von der Steuerung geregelter HK- Pumpe hätten wir nach meinem Verständnis weiterhin exakt die selbe Situation wie jetzt, mit zwei „hart“ geregelten Pumpen im gleichen Kreis und entsprechendem Körperschalleintrag. Die Idee hinter Puffer + externer, sehr weich eingestellter HK-Pumpe wäre daher, zumindest den Heizkreis akustisch zu beruhigen.

Genau diese fehlende Regelung habe ich bei meiner WP mit TP70-Puffer "nachgerüstet", indem ich an das EMS-ESP einen Temperatursensor angeschlossen habe, der den sekundärseitigen Rücklauf misst (gemischte Heizkreisrückläufe kurz vor der Stichanbindung). Mithilfe dieses Sensors stelle ich kontinuierlich die Sollspreizung auf die gemessene sekundärseitige Spreizung - 0,1 K. Hatte ich vor einigen Seiten schonmal erklärt, dann kam zurecht Kritik an den vielen Schreibzugriffen auf. Ich habe jetzt nach und nach meinen Code dazu angepasst, so dass ich jetzt einen für mich akzeptablen Kompromiss zwischen präziser Regelung und wenigen Schreibzugriffen gefunden habe (ca. 100 pro abtauintensivem Tag).
Folgenden JavaScript-Code nutze ich dafür (in Node-RED als HA-App):

const SPREAD_OFFSET = -0.1;
const HYST_INC = 0.4;
const HYST_KMIN_INC = 10;
const HYST_KMIN_DEC = -5;
const EXTRAPOLATION_TIME = 8;
const SMOOTH_SPREAD = 0.5 ** (1 / 0.5); // 30 s half-life
const SMOOTH_DSPREAD = 0.5 ** (1 / 8); // 8 min half-life
const ON_DELAY = 6 * 60000;
const SPREAD_MIN = 3;
const SPREAD_MAX = 10;
const primaryCirc = flow.get('primaryCircuit');
const now = Date.now();

if (primaryCirc.mode == 'heating' && now - primaryCirc.lastModeChange > ON_DELAY) {
const secondaryCirc = flow.get('secondaryCircuit');
let spread = secondaryCirc.flowTemp - secondaryCirc.returnTemp;
const oldSpread = context.get('spread') || spread;
let dt = (now - (context.get('tEval') || now)) / 60000;
let weight = SMOOTH_SPREAD ** dt;
spread = weight * oldSpread + (1 - weight) * spread;
let dSpread = context.get('dSpread') || 0;

if (dt > 0) {
weight = SMOOTH_DSPREAD ** dt;
dSpread = weight * dSpread + (1 - weight) * (spread - oldSpread) / dt;
}

context.set('tEval', now);
context.set('spread', spread);
context.set('dSpread', dSpread);
spread += dSpread * EXTRAPOLATION_TIME + SPREAD_OFFSET;
spread -= Math.max(0, Math.min(spread - primaryCirc.spread, HYST_INC));
spread = Math.floor(Math.max(SPREAD_MIN, Math.min(spread, SPREAD_MAX)) * 10) / 10;
const dev = (spread - primaryCirc.spread) * (now - (context.get('tChange') || 0)) / 60000;

if (dev < HYST_KMIN_DEC || HYST_KMIN_INC < dev) {
context.set('tChange', now);
return {payload: spread};
}
}
else {
context.set('tEval', NaN);
context.set('spread', NaN);
context.set('dSpread', NaN);
}

Es braucht in Node-RED noch ein paar weitere (viel einfachere) Nodes, um die nötige "Infrastruktur" zu schaffen.
Über die großgeschriebenen Parameter oben kann man sowohl den Arbeitspunkt (SPREAD_OFFSET) als auch die Balance zwischen Schreibzugriffen und Regelpräzision einstellen (Hysterese, Extrapolation, Glättung).
Das funktioniert recht gut, der Kältekreis kommt mit der sich verändernden Spreizung genauso gut klar wie mit den dazu alternativen Veränderungen, die man mit der Originalregelung hätte. Man hat allerdings kaum noch mischungsbedingte Verluste und der Puffer wird konsequent auf Vorlauftemperatur erwärmt und gehalten, sofern die WP im Heizbetrieb ist.

An alle, die Python zu ihren Hobbys zählen. ;-)
Ich habe im Netz eine Anleitung gefunden, wie man die InfluxDB von HA mit Python Skripten anzapfen kann.
Damit kann ich beliebige Signale von HA extrahieren, verarbeiten und darstellen, auch rückwirkend. Viel besser als es mit den den eingebauten Helpern bzw. Grafana möglich ist.

https://github.com/villeneuved/InfluxDB_HomeAssistant

Mein erster Versuch war die Abhängigkeit der Abtauvorgänge pro Tag von Umgebungstemperatur und Taupunkt-Delta darzustellen.
Der Zusammenhang ist nicht so eindeutig wie gehofft, aber die Tendenz ist sichtbar.

x = Delta zwischen Verdampfer und Taupunkt (Tagesmittel)
Farbe = Außentemperatur (Tagesmittel)



Je nach Zeit und Lust, werde ich hiermit in Zukunft sicherlich noch häufiger herumspielen.

Den Gedanken hatte ich auch schon mal. Ich habe es mit Grafana und InfluxDB Bordmitteln realisiert, also eine entsprechende Flux-Query formuliert.
Mein Gedanke war aber der: Trage pro Abtau-Event die vergangene Zeit zur vorherigen Abtauung gegen das aktuelle Taupunkt-Delta auf. Hätte es mir auch eindeutiger vorgestellt, aber vielleicht braucht es einfach noch mehr Statistik. Die Tendenz ist aber ebenfalls sichtbar.
Die Farbe der Punkte zeigt die Außentemperatur.


Hier die Query bei Interesse. Voraussetzung ist, dass man auch die Wetterdaten in irgendeiner Form in der DB hat.
https://pastebin.com/5myTubPb

Grafana und InfluxDB sind mir von der Bedienung einfach zu "fremd", bei Python fühle ich mich besser aufgehoben. ;-)

Statt der Außentemperatur habe ich nun den Taupunkt selbst verwendet, weil die Abhängigkeit vom Taupunkt eindeutiger sein dürfte. Nur wenn der Taupunkt unter 0°C liegt, kann auch das Kondensat gefrieren.

Wenn man dann noch einen 3D Plot verwendet und "diagonal durchschielt" erkennt man einen relativ eindeutigen Zusammenhang. Den Ausreißer rechts unten kann man ignorieren, das ist der angefangene Tag heute.

Bleibt die alles entscheidende Frage: Welche Verbesserungen hast du bei Arbeitszahl, Stromverbrauch, Abtauintervallen und möglicher Absenkung der VLT damit erreichen können?

Hier das Bild über den Taupunkt aufgetragen:



Das stimmt nicht, oder?
Bei z.B. AT 3°C und TP 2°C kann der Verdampfer unter 0°C sein. Dann bildet sich daran Kondensat und gefriert.

Ja, natürlich, hatte es richtig im Kopf und falsch geschrieben.
Ich könnte später noch ein Plot mit der mittleren Verdampfer-Temperatur erstellen.

Auch ich hebe per ioBroker-Script die Sollvorlauftemperatur kurz vor Ende des WW an, um den sonst folgenden Takt zu verhindern. Nach dem Umschalten auf Heizbetrieb stelle ich dann nach 3 Minuten wieder die ursprüngliche Solltemperatur ein.

Dieses schrittweise verringern der Temperatur ist bei mir nicht nötig. Dies reduziert die erforderlichen Schreibzyklen auf ein Minimum. Funktioniert das bei Euch nicht?

Hallo und vielen Dank für die bisher wahnsinnig hilfreiche! Ich habe mich durch die kompletten Seiten durchgearbeitet, aber leider verstehe ich (vielleicht aufgrund meines ganzen Arbeitsspeichers) nicht alle Punkte.

Meine Wärmepumpe wurde von meinem Heizungsinstallateur mit einer neuen Fußbodenheizung in einen 130 m² Bungalow im Rahmen einer Sanierung eingebracht. Allerdings bin ich beim Thema Energie Effizienz und Auslegung der Heizung auf möglichst wenig Stromverbrauch auf taube Ohren gestoßen. Denke, der Heizungsinstallateur hatte weder Interesse noch Zeit, sich besonders darum zu kümmern.

Aktuell passe ich mich an die richtigen Einstellungen heran, das Haus wird warm, allerdings habe ich aktuell das Gefühl, dass bei konstanter Raumtemperatur die Vorlauftemperatur ständig sehr große Schwankungen hat (20-36°, siehe Zackenmuster). Und dies bei Außentemperaturen von 5-10°!
Ich habe ein Bild der Daten des EMS-ESP gemacht, vielleicht könnt ihr mir aufgrund der zu Grunde liegenden Daten helfen? Mein nächster Schritt wäre den Durchfluss im Heizkreis zu erhöhen?

Vielen Dank schon mal für eure Anmerkungen im Voraus!


https://c.web.de/@280853731396813723/s3OVHcsIzGiuoHQSTix_qg

Sorry, ich bekomme das Foto nur als Link rein...

Hi THS - um wieviel Grad hebst Du Deine Soll-Vorlauftemperatur an: also wie ich hoch ist die Differenz zwischen Tempo vor der WW-Bereitung - und dann Deine Anhebung um den Takt zu vermeiden?

Ich denke, Du benutzt diese Entitaet: climate.thermostat_hc1?

Heute ist er bei mir nach der WW-Bereitung wieder ausgesteigen (Kompressor aus), obwohl ich etwas die Soll-VL-Temp angehoben habe....

[img]Bild[/img]

Das Zackenmuster sieht so aus, als hättest du allerlei Abtauvorgänge. Wenn die Luft sehr feucht ist (95%) kann das gerade bei ~5-7° so aussehen.
Aber um da irgendwas beurteilen zu können, fehlen allerlei Daten. Z. B. welche WP, Normheizlast, Durchfluss im Heizkreis, Einstellung TC3/TC0, Heizkurve, gibt es einen WW-Speicher ...

Hallo Experten,

ich brauche eure Hilfe für meine Buderus WLW 176i T180.
Es geht um Zeitprogramm Heizen. Das Zeitprogramm für Heizen ist eingestellt von 05:30 bis 22:30 Uhr ( Sollwert 21° ), was nicht eingehalten wird, weil die WLW Nachts weiterläuft. Die Anlage geht pünktlich um 22:30 aus aber immer kurz vor Mitternacht wieder an und läuft mit einer Kompressorleistung ca. 50-60% manchmal höher bis 05:30 danach geht sie auf 99% weiter. Der Heizungsbauer konsultierte den KD und sagte, die Absenkung tiefer stellen also von damals 19°C habe ich auf 16°C gestellt. Leider hat es nicht gebracht und ich habe dadurch hohen Stromverbrauch. Seit 01.11.25 bist 20.02.26
also bei ca. 150 Tagen gab es nur 21 Tage, wo die Anlagen korrekt aus und anging. Einstellung beim Heizen ist auf Auto und Sommer/ Winterschaltung. Was kann das sein?
Für jeden Tipp bin ich dankbar.

VG, Siegmund

Das Problem ist, dass sich das unter Realbedingungen nur mit großen Unsicherheiten messen lässt, außer man hat für beide Szenarien möglichst lange Messreihen (nicht unbedingt am Stück) mit nahezu perfekt gleich verteilten Bedingungen. Alles wirkt sich ständig auf die Arbeitszahl aus.
Dafür müsste ich entsprechend hin- und herwechseln, alles tracken etc., sonst wird das von den Unsicherheiten dominiert und darauf habe ich keine Lust, weil es gut funktioniert und die Theorie klar ist. Bei mir ist der Effekt wahrscheinlich größer, da meine Spreizung vergleichsweise groß und stark schwankend ist. Wenn man nur einen ungemischten Heizkreis mit hohem Durchfluss bzw. kleiner Spreizung hat, wird der Effekt kleiner sein.
Ich habe den Code nochmal (hoffentlich zum Besseren) verändert, damit die Extrapolation weniger anfällig wird ggü. den potenziell schnellen Spreizungsänderungen z.B. nach Änderungen der Kompressordrehzahl, ohne jedoch zusätzliche Eingangsvariablen zu nutzen, da das den Code nicht nur komplizierter, sondern auch komplexer machen würde. Die Hystereselogik habe ich auch verbessert.
Ich poste den Code ein letztes Mal hier, damit es nicht zu unübersichtlich wird. Falls mir noch relevante Verbesserungen jenseits der Parameterwahl einfallen werde ich ggf. ein Github-Repo o.ä. erstellen.

const SPREAD_OFFSET = -0.1; // K
const HYST_INC = 0.4; // K; > 0
const VAR_INTEGRAL_MIN = -2; // K² * min; < 0
const VAR_INTEGRAL_MAX = 4; // K² * min; > 0
const EXTRAPOLATION_TIME = 5; // min; >= 0
const SMOOTH_SPREAD = 0.5 ** (1 / 1); // [0, 1]; 1 min half-life
const SMOOTH_DSPREAD = 0.5 ** (1 / 4); // [0, 1]; 4 min half-life
const DSPREAD_ZERO_BIAS = 0.85; // [0, 1]
const ON_DELAY = 5 * 60000; // ms
const SPREAD_MIN = 3;
const SPREAD_MAX = 10;
const primaryCirc = flow.get('primaryCircuit');
const now = Date.now();

if (primaryCirc.mode == 'heating' && now - primaryCirc.lastModeChange > ON_DELAY) {
const dt = (now - (context.get('tEval') || now)) / 60000;
const secondaryCirc = flow.get('secondaryCircuit');
let spread = secondaryCirc.flowTemp - secondaryCirc.returnTemp;
let dSpread = context.get('dSpread') || 0;

if (dt > 0) {
const oldSpread = context.get('spread') || spread;
const newDSpread = (spread - oldSpread) / dt;
let weight = SMOOTH_DSPREAD ** dt;
weight += (1 - (1 - DSPREAD_ZERO_BIAS) ** Math.abs(newDSpread)) * (1 - weight);
dSpread = weight * dSpread + (1 - weight) * newDSpread;
weight = SMOOTH_SPREAD ** dt;
spread = weight * oldSpread + (1 - weight) * spread;
}

context.set('tEval', now);
context.set('spread', spread);
context.set('dSpread', dSpread);
spread += dSpread * EXTRAPOLATION_TIME + SPREAD_OFFSET;
spread -= Math.max(0, Math.min(spread - primaryCirc.spread, HYST_INC));
spread = Math.floor(Math.max(SPREAD_MIN, Math.min(spread, SPREAD_MAX)) * 10) / 10;
const dev = spread - primaryCirc.spread;
const varIntegral = (context.get('varIntegral') || 0) + Math.sign(dev) * dev ** 2 * dt;
context.set('varIntegral', varIntegral);

if (varIntegral < VAR_INTEGRAL_MIN || VAR_INTEGRAL_MAX < varIntegral) {
context.set('varIntegral', 0);
return {payload: spread};
}
}
else {
context.set('tEval', undefined);
context.set('spread', undefined);
context.set('dSpread', undefined);
context.set('varIntegral', undefined);
}

Hallo,
ich stelle den Parameter "HK1 gewählte Raumtemperatur (hc1/seltemp)" auf 29 °C, damit wird dann durch die WP der Parameter "HK1 berechnete Vorlauftemperatur (hc1/targetflowtemp)" auf etwa 45°C gesetzt.

Nach 3 Minuten stelle ich dann die ursprüngliche Raumtemperatur (21 bis 22°C) wieder ein, die daraus berechnete Sollvorlauftemperatur beträgt dann ca. 35 °C (bei aktuell etwa 0°C Außentemperatur).

Probier mal ohne Nachtabsenkung / nachts aus. Wenn es dann im Haus zu warm wird, Heizkurve bzw. bei der WP angeforderte Raumtemperatur runter. Ich befürchte aber, dass du die Raumtemperatur nich mit Thermostaten regelst. Dann musst du erstmal grundlegend lerne, Wärme zu pumpen. Nachtabsenkung geht nämlich meist nach hinten los, weil du bei den kältesten Außentemperaturen Dein Haus wieder warm bekommen willst und die nachts verlorene Wärme aufholen musst.

Dass die WP nachts läuft liegt vmtl am Frostschutz. Du willst nämlich gar nicht, dass sie nachts bei Frost aus ist, es sei denn, du willst schnell eine neje kaufen müssen.

So mache ich das auch, und es funktioniert. Nur nicht am Mittwoch ... :).

Die Thermostaten an den Heizkörpern ( bei mir sind nur Heizkörper ) sind alle voll aufgedreht. Mit oder ohne Absenkung habe ich Tag und Nacht Temperatur um 21°C, weil die WP durchläuft mit Modulation um die 50-60% und manchmal bis 90%. Die 21°C brauch ich Nachts natürlich nicht, deswegen wundert mich, wenn die WP durchläuft, warum nicht mit zB. 20% Modulation? Das Display zeigt Absenkung zB. 16 oder 19°C aber auch Heizen bei Raumtemperatur von 21°C um zB. 01:20, wo man sich fragt, wie kommt denn das denn? Ich habe die Absenkung auf AUS gestellt sollte die Frostschutzgrenze von 5 auf 3 gesenkt werden?

Dank Dir, @THS: werd ich beim naechsten Mal ausprobieren: ich hab "HK1 gewählte Raumtemperatur (hc1/seltemp)" nur ein paar grad hoeher gestellt gestern --> und dann hat sich der Kompressor ausgeschalten. Stell Sie dann jetzt mal auf 29degC hoch....

Schaltest Du waehrend der WW-Bereitung auch das Heizen aus, um das Überschießen der Vorlauftemperatur nach WW-Ladung zu reduzieren/unterbinden?

Danke fuer das Feedback!

Schaltest Du waehrend der WW-Bereitung auch das Heizen aus, um das Überschießen der Vorlauftemperatur nach WW-Ladung zu reduzieren/unterbinden?

Ich bin dran, in die EMS-ESP32 firmware diesen Pumpkick als Entitaet reinzubekommen (siehe auch @‘riverkitten’ auf Seite 155 hier): noch nicht sicher, wie das wirklich so wird, aber schau mer mal...

GitHub Pumpkick

Nein, mache ich nicht. Meist werden es aktuell nur knapp 2 K mehr. Deswegen irgendwelche Kunstgriffe zu machen, lohnt sich IMO nicht.

Was ist bei dir denn hier eingestellt?

(kopiert aus der BC400 Anleitung)

Durchheizen unter.
Zum Aktivieren Ja auswählen.
-oder-
Zum Deaktivieren Nein auswählen.
Außentemperatur einstellen, ab der das Zeitprogramm
außer Kraft gesetzt werden soll.

Guten Morgen,

was ist denn Fehler 1018, finde ich nicht in der Serviceanleitung?

Compress 6800i

Grüße, Sven.

Die Buderus ProWork App findet dazu nur H08-1018 "Zeitintervall für die notwendig Wartung erreicht". Vielleicht passt das ja auch zur Bosch WP.