Mitsubishi Klima als Luft-Wasser-WP

[aiole]

Ob der Temperaturfühler analog oder digital ist, macht für mich keinen Unterschied. Ich bin an dem Wert interessiert und nicht an der Technik, wie er zustande gekommen ist. Und bei einer Heizungssteuerung ist das letzte Zehntel glaube ich nicht wichtig.

klares jein

Belegt nicht jeder T-Fühler einen UVR-Eingang?
Dann muss sternförmig zur UVR verkabelt werden oder geht das noch anders?

Mein Pufferspeicher hat aktuell 6 T-Sensoren, die ich mit nur einer 3-adrigen Leitung per 1-wire auslese. Weiter T-Sensoren binde ich nun am PWT (VL,RL, Heißgas, Flüssigltg), am AG (AT, WT) und an den Mischern an. Da komme ich auf ca. 20-T-Sensoren. Dafür reicht dann keine UVR16x2 und ich bräuchte Extensions, die wieder Standbyverbrauch hätten.
Bei sternförmiger Verkabelung bekomme ich zudem fette Kabelpakete.

Das fehlende Temperatursensor-Bussystem war schon immer ein großes Manko, sichert jedoch den Extensionabsatz. BUS hat die UVR nur untereinander (CAN).

[aiole]

zum Projekt:
Da der KM-Meister das AG noch nicht an den PWT angedockt hat, wird aktuell mit wasserführendem Kaminofen (sporadisch) geheizt. Das erlaubt warmes Duschen , aber die Haupterkenntnis ist, dass die Mitsu eigentlich nur die FBHZ bedienen müsste.

WW kann dann unproblematisch mit dem Ofen erwärmt werden, da der Puffer mit der WP bereits auf 30...38°C vortemperiert wäre. 120l WW reichen hier für ca. 2 Tage.

[Gero]

Belegt nicht jeder T-Fühler einen UVR-Eingang?
Dann muss sternförmig zur UVR verkabelt werden oder geht das noch anders?

Doch, das ist immer noch so. Hatte ich mir auch gar nicht anders vorstellen können, da auch die 1-wire-Fühler der Shellies ja einzeln an den Shelly angeschlossen werden. Ist quasi genauso, wie die Temp-Fühler, die an die UVR gehen. Man kann aber noch die Messwerte einer UVR der anderen zur Verfügung stellen. Man muss also nicht an jedem Regler auch die Hardware dranhaben - die Werte kommen dann über den CAN-Bus. Das können aber vielleicht nicht alle Installateure so einstellen, für sie ist ein neuer Sensor einfacher. Zumal der Kunde es ja auch bezahlt.

Aber gut, wer 20-Temperatur-Sensoren hat, sieht im 1-Wire-Bus natürlich einen klaren Vorteil. (Ich habe derer 12, davon 5 direkt am Pufferspeicher)

[dmq]

Danke aiole + Gero: das mit der Update-Frequenz unter Modbus war mir auch neu (JSON hatte ich schon gelesen) - ich denke für die Heizungssteuerung aber noch verkraftbar.

[aiole]

So - es weiter.
Das AG ist nun endlich mit dem PWT gekoppelt (Kältemittelkreis geschlossen).

Dank der UniPi-EVOK-API, die 1a in Node-Red einbindbar ist, sind nun fast alle Komponenten ausles- bzw. ansteuerbar. Aktuell fehlen noch ein paar Temp.-sensoren (1-wire) am PWT und AG (für die AT), um den wasserseitigen Kreislauf regeln zu können.

Außerdem klemmt die Pumpe (nach fast 7 Jahren Standzeit wenig verwunderlich). Die wird kurzfristig gewechselt bzw. repariert.

Ein erster Test mit seitens UniPi ferngesteuerter Stromzufuhr für das Mitsubishi-Interface + AG ergab, dass der Standbyverbrauch von 4,5W (RPi3 + SSD + UniPi-Ansteuerplatinen) auf ca. 20W hochgeht. Sofern man also die WP-Anlage nachts nicht fährt, kann man 15W Leistungsbedarf einsparen.

Im Tagbetrieb sollte man das System elektrisch durchlaufen lassen, um keine "harten" ON/OFFs zu provozieren. Das wird auch lt. manual empfohlen (Schutz Verdichter und weiterer Komponenten).

####################################################################
Ein erster Test mit dem AG war zunächst ernüchternd, weil es nicht so lief wie gedacht. Eine Nachmessung des 0-10V- Leistungsvorgabe-Steuersignales ergab, dass der Analog-Out des UniPi diese Spannung genau invertiert ausgab. Das war dann also wie Radfahren mit gegenläufigem Lenker .
update: Jetzt wird auch klar warum:
https://kb.unipi.technology/en:hw:03-un ... tion-of-ao
Older variants interpreted 0 % PWM duty cycle as AO = 10 V DC, and 100 % PWM duty cycle as AO = 0 V DC.

Zum Glück waren noch 2 Analog-Ausgänge auf der UniPi-4-fach-AO-Erweiterungsplatine frei (UniPi hat nur 1x AO), womit ich das AG nun korrekt steuern kann.
Das AG läuft z.B. bei 5V-Vorgabe sauber hoch und erwärmt den Kältekreis. Wegen der noch klemmenden Umwälzpumpe kann man das nicht ewig laufen lassen, so dass nach 5 min manuelles Abschalten mit 0-Voltvorgabe angesagt war. Die Heisgasleitung wird bis dahin schön warm (geschätzt 50°C) und ich bin zuversichtlich, dass es funktionieren wird.

Die 6 Betriebsanzeigen des Mistsu-Interfaces hatte ich auch schon auf die UniPi-Eingänge verkabelt und zeigen dort schön mit roten LED's den Betriebszustand (EIN/AUS), den Verdichterbetrieb (Ein/AUS) und den Modus (Heizen/ Kühlen ist "hart" deaktiviert).

aktuelles NR-dashboard für den "Handbetrieb" (Einzelkomponentenansteuerung/-auslesung)

#####################################################################
Sowie Pumpe und restliche T-Sensoren installiert sind, geht's an die erste NR-Steuerung.
Dabei würde ich zunächst die 2 Mischer komplett heraus lassen und nur die Pumpendrehzahl einbeziehen.

[aiole]

So - endlich ist die Pumpe gewechselt. 0-10V-Pumpen sind heutzutage leider nicht in allen Größen lieferbar.

Seit 3 Tagen "spiele" ich mich zunächst MANUELL durch alle Regeloptionen, die das WP-System bietet. Das wären:
* die normalen ON/OFF-Funktionen (Digital outputs: Gesamtsystem, Umwälzpumpe, Abtaumischer)
* die regelungsrelevanten 0-10V-Analogfunktionen (Analog outputs: WP-Leistungsvorgabe, Drehzahlregelung UP, Vorlaufmischer)

Die Rückmeldungen des AG an das Mitsu-Interface und weiter an UniPi/Node-Red sind sehr hilfreich (Digital inputs).
Hier sieht man z.B., was gerade alles aktiv ist (grün) und dass soeben einen Abtauung stattfindet (hellblau). Das kann man dann gut in der eigentlichen Regelung verwenden (Abtauvorgang dauerte bei ca. +1.2°C AT ca. 4...5 min).

Der obere AI 1 zeigt noch die Durchflussmenge an. Diese wird dann mit dem delta_T aus VL- minus RL-Temp. zur wasserseitigen Leistungsabgaberechnung verwendet. Daraus und mit dem vor IG/AG verbautem 1p-SDM120-Zähler kann man dann noch COP/JAZ und dergleichen ermittelt werden.

[aiole]

So - noch eine quick&dirty COP-Berechnung (ca. A2W35).
https://effiziente-waermepumpe.ch/wiki/ ... _%28COP%29

Ich hoffe, dass ich mich nicht vertan habe. Wer will, bitte kritisch prüfen und feedback geben - Danke.
Etwas Abweichung könnte es bei der VL/RL-Temp. geben, da ich dort noch keine Sensoren habe. Stattdessen habe ich die in der Nähe befindlichen VL/RL-Temp. der FBHZ angesetzt (Die WP speist parallel zum 950l-Puffer auf die aktuell arbeitende FBHZ.).

P_Wärme = (delta_Q = c_Wasser x Masse_Wasser x delta_T (VL - RL)) / 60s
= 4,18 kJ/kg*K x 6,31 kg/60s x (32,8°C - 25,3°C) = 3,297 kJ/s = 3297 Watt Wärmeabgabeleistung

COP = 3297 W / 834,6 W = 3,95

Damit bin ich bei +1,3°C AT erst einmal recht zufrieden (alles mit vernünftig gemessenen Werten => Stromzähler mit ALLEN WP-Komponenten + guter Durchflussmengenmesser im RL der WP).

Das Ganze ist noch ohne Tuning. Z.B. sollte einen niedrigere Temp.-spreizung zw. VL und RL zu weiterer COP-Erhöhung führen. Allerdings will ich ohne Pufferbeheizung durch die WB gleich einen sinnvolle VL-Temp. generieren (aktuell 32...34°C), um die Gastherme nicht anspringen zu lassen. PTN soll sein Gas behalten und wir endlich energetisch unabhängiger werden.

[aiole]

Es wird kälter. Aktuell -2°C AT. Damit ergibt sich folgendes Szenario bei frei gewählter 50% Leistungsanforderung:

Ich habe testweise die Fließrichtungsumkehr am PWT beim 5min-Abtauprozess manuell initiiert. Im Ergebnis ist die Verdichterleistung etwas niedriger und vor allem schiebt es nicht 5min lang kaltes Wasser in den VL (Pufferdurchmischung).

Da Abtauen sicher indentifiziert werden kann, werde ich wohl die Fließrichtungsumkehr für die 5min automatisieren. Dazu müssen nur die 2x Drei-Wege-Mische entsprechend angesteuert werden.

Ihr seht - ich versuche gerade die Arbeitsweise anhand Abtauen, Temperaturen, Leistung etc. zu verstehen, um daraus die optimale Regelung abzuleiten. Es ist genau das Gegenteil von "black box". OpenWB ist dabei sehr hilfreich (Diagramm).

[aiole]

Heute war es mit +5°C AT deutlich wärmer.
Abtauen entfällt nun und die 150 m2 (komplett FBHZ) werden mit ca. 40% Leistungsanforderung bei gemessenen P_el_input = 550...800 Watt (enthält alle WP- und Steuerkomponenten) allein durch die Luft-WP beheizt.

Aus den manuellen Tests ergeben sich nun folgende Anforderungen (noch ohne PV-Führung):
1. Heizen (VL-Temp. ca. +28...+33°C je nach AT)
* VL-Temp.-Steuerung in Abhängigkeit der AT
* festes Setzen einer Leistunganforderung (0-10V) + Regeln der UP_Drehzahl (auch 0-10V), wenn VL-temp. nicht erreichbar: Erhöhung der Leistungsanforderung und wieder Pumpendrehzahl regeln, kein VL-Mischer erforderlich (immer voller Durchfluss)
* während des Abtauens zur Vermeidung einer Pufferdurchmischung: Abtausequenz mit VL/RL-Tausch einbauen (VL-Mischer => 10V, Abtaumischer: Rel 4 = ON, danach wieder retour

2. WW (VL-Temp. ca. +48..+52°C)
* Leistungsanforderung auf 100% = 10V setzen (zeitlich beschränkt oder per Puffer-Temp-Sensor im oberen Drittel abschalten, um ca. 100...150l WW zu erwärmen)
* UP mit ca. 50% laufen lassen (5V)
* VL-Temp.-regelung mittels VL-Mischer (0-10V)

Einwände / Hinweise?

Aktuell sind 2 Flows aktiv.
a) UniPi-flow mit den manuellen Steuerungsoptionen
b) Zähler-flow zum Auslesen des SDM120 per Modbus

Zum Schluss wäre a) ein Testmodus mit manuellen Eingriffsoptionen. Nun muss aber das eigentliche Programm (Automatik) noch in einen flow. Ich tendiere zu einem extra flow mit eigenem dashboard.
Packt man a) später als subflow dort darunter? Wozu nimmt man die subflows, wenn aktive flows auch nebeneinander laufen können?

VG

[LutzB]

Subflows sind Flows, die Du mehrfach in anderen Flows verwenden kannst/willst. Im openWB Simulator sind z.B. die Ladepunkt-Flows so umgesetzt. Dadurch ist die Logik nur einmal vorhanden, obwohl drei Ladepunkte simuliert werden.

In Deinem Fall macht das vermutlich keinen Sinn.