Also soweit ich die Entwickler der Integration verstanden habe, fällt die Anlage nach 1 Minute einfach auf ihren eigenen Sensor zurück, sobald das externe Thermometer nicht verfügbar, oder auch HA komplett abschmiert.
Hatte es Gestern mal Heizen lassen und zwischendurch viel der Sensor für 5min aus. In der Folge sprang IST auf 28°C und Anlage ging aus, nach 5min ging es dann wieder normal weiter mit 22°C.
Was mir aber auffällt, die Anlage überheizt recht genau um 1,8°C, aber das lässt sich ja in den Settings beheben.
Sehr sehr guter Ansatz. Das nicht mehr Herunterregeln über 20°C Soll ist ja das grösste Manko der MHI. Lässt sich tatsächlich sehr leicht durch einen Offset beim externen Thermometer beheben. Habe ich so beim ProtoArt schon genutzt und funktionierte hervorragend.
Deinen Ansatz mit den 19°C Fest und dann über Soll die Leistung steuern finde ich noch besser. Das habe ich allerdings schon mal mit meiner Midea probiert und da funktionierte es nicht. Die Midea braucht eine stete Änderung der Temperatur, denn sonst dreht sie einfach immer weiter auf und versucht mit "Gewallt" eine Temperaturerhöhung zu erreichen. Bekommt sie z.Bsp. permanent 22°C gesendet, dann läuft sie nach ein paar Stunden einfach auf voller Leistung durch.
Mal schauen wie das die MHI handhabt. Wird auf jeden Fall eine spannende Heizsaison.
Noch mal zum COP berechnen. Mit dem ProtoArt geht das sehr gut, da es die aktuell Lüfterstufe in RAW ausliest. Beim WF-RAC wird dies leider nicht gehen, da die Lüfterstufe laut Entwicklern nicht im Modul zur Verfügung steht.
Hat jemand einen Tip wie man aus den Sensoren der Integration einen realistischen COP errechnen könnte?
Das ist wohl der Standardmäßige Offset den die Anlagen haben, wenn sie ausgeliefert werden (aufgrund des internen Temperatursensors). Kann man beheben, in dem man wohl 30 Sekunden die An/Aus Taste an der Inneneinheit drückt. Bei mir regelt die Anlage mit einer Hysterese von ca. +/- 0.2 Grad (also insgesammt 0.4 Grad Hysterese) perfekt um den Zielwert (aber war natürlich nur 1-2h test mal früh am morgen, wird sich dann zeigen wenn es richtig kalt wird)!
Mit einem ESP8266 und einem elektrischen Interface lese ich die Luefterdrehzahl aus. Zudem noch 2 DS1820 um Einlass und Auswurftemperatur zu messen. Die Kubikmeter pro Stunde fuer hoechste Drehzahl aus dem Datenblatt und dann mit den gemessenen Pulsen linear interpolieren. Dann noch elektrische Leistung von einem Shelly und schon kann man den COP live berechnen. Das ganze mit ESPHome. Vielleicht komme ich Ende Oktober mal dazu das ganze auf Github zu posten.
Stimmt, ClimateControl verfügt over eine Schutzfunktion, wodurch sie automatisch auf den internen Sensor zurückschaltet.
Die WF-RAC-Integration hat dies nicht. Fällt Home Assistant aus, läuft die Klimaanlage mit der zuletzt eingestellten Temperatur weiter. Da sich die Zieltemperatur nie ändert, läuft sie ewig weiter, bis die Verbindung wiederhergestellt ist. Das bringt ein großes Risiko mit sich. Deshalb wäre ich damit sehr vorsichtig.
Ich nutze auch einen HomeAssistant Wert eines Thermometers als externen Sensors, aber nicht in Verbindung mit dem WF-RAC sondern mit einem ESP Modul anstelle des WLAN Moduls im Innengerät.
Der Vorteil dabei ist, dass es komplett Lokal (ohne Cloud) läuft und man zusätzlich noch deutlich mehr Sensoren angezeigt bekommt.
Beim ESP Modul kann man in der Konfiguration einstellen, wie lange die Klimaanlage warten soll, bis der interne Sensor wieder verwendet wird, wenn man keinen Wert mehr sendet.
Schau dir die neue Integration nochmal an, die meisten Punkte sind auch ohne ESP moglich.
Die ganzen Werte wir Kompressorfrequenz, etc. Werden dir auch angezeigt.
Ebenfalls ist es komplett lokal.
Auch wird zum internen Sensor gewechselt wenn der externe Sensor keinen gültigen Wert mehr liefert.
Einzig was bleibt ist eine möglicher unbemerkter, längerer Ausfall von HomeAssistant.... Aber ich habe den Eindruck bei den Leuten die HomeAssistant nutzen bleibt das nicht länger als ein paar Stunden "unbemerkt" .
Zu mal man auch so argumentieren könnte, was passiert wenn der ESP ausfällt?
Bleibt jeden selbst überlassen natürlich, gerade wenn man den Umbau schon gemacht hat!
Wollte nur darauf hinweisen, das es sehr ähnlich ist, und das ohne Hardware anzufassen.
Danke für den Tipp. Da hat sich wohl einiges getan bei der Integration.
Ich hatte damals immer mal wieder Probleme, dass Ich die Verbindung verloren hatte (aufgrund der stündlichen Neuverbindung)
Daher hatte Ich auf den ESP umgebaut. Schaue es mir aber nochmal an.
Aber ja - du hast Recht. Ein Ausfall von HomeAssistant würde mir vermutlich auch zeitnah auffallen
Auch das ist wohl mit dem letzten Update gefixt. Bei Ausfall HA wechselt die MHI zurück auf internen Sensor.
Eigentlich bringt die Integration jetzt alles mit was man im Alltag so braucht und verschiedenste Offsetwerte machen eine Anpassung an locale Gegebenheiten kinderleicht.
Nur die real verwendete Lüfterdrehzahlstufe wird wohl nicht kommen aufgrund von Hardwarebeschränkungen. Das ProtoArt liest kurioserweise die Drehzahl 8-stufig aus, obwohl es am selben Port angeschlossen ist.
Wie ist das beim ESP? Wird da die aktuelle Drehzahlstufe bei Einstellung "Lüfter = Auto" angezeigt?
Das Problem ist immer noch nicht gelöst und kann auch nicht gelöst werden. Nur wenn Home Assistant ordnungsgemäß heruntergefahren wird oder wenn der Sensor nicht mehr erreichbar ist, schaltet die Klimaanlage auf den internen Sensor um. Sollte die WLAN-Verbindung abbrechen (was bei vielen Menschen regelmäßig vorkommt) oder Home Assistant abrupt abstürzen, heizt die Klimaanlage einfach weiter.
Wenn Sie die Funktionalität eines externen Sensors nutzen und die Klimaanlage darüber steuern möchten, würde ich mich absolut nicht auf eine Netzwerkverbindung verlassen. Es muss immer die Möglichkeit geben, dass das System selbstständig auf den richtigen Wert zurückgreift.
Ich verstehe nicht ganz warum sie weiterheizen sollte bei Absturtz von Wifi oder HA?
Wenn die Anlage nicht jede Minute den Wert des externen Thermometers gesendet bekommt, dann springt sie doch automatisch wieder auf den internen Sensor, oder nicht?
Interessant, Da alle Module den gleichen Port verwenden wundert es mich dann doch etwas, warum das Signal angeblich am WF-RAC nicht ankommen soll.
Ist eigentlich sehr nützlich, da sich damit recht gut ein Live-Cop rechnen lässt.
Leider kann ich dem Entwickler hierbei auch keine Hilfe sein, aber vielleicht findet sich ja noch ein findiger User, der auch diesen Wert noch integriert bekommt.
Das ProtoART-Modul macht das tatsächlich. Sobald die Verbindung abbricht (Home Assistant oder drahtloser Sensor), schaltet es automatisch auf den internen Sensor zurück.
Die WF-RAC-Integration tut dies jedoch immer noch nicht. Du meintest, dass dies mit dem Update behoben wurde, aber das stimmt nicht. Die WF-RAC ist dafür nicht „smart“ genug. Sobald die Kommunikation mit Home Assistant erzwungen unterbrochen wird, heizt die Klimaanlage mit der zuletzt übermittelten Temperatur weiter, was ein Risiko darstellt.
Der einzige Moment, in dem die WF-RAC mit der Integration auf den internen Sensor umschaltet, ist, wenn Home Assistant vom Benutzer beendet oder neu gestartet wird.
Die Home Assistant-Integration mit dem WLAN-Modul von Mitsubishi (WF-RAC) tut dies nicht. Sie schaltet nicht nach 1 Minute zurück. Das tut sie nur, wenn der Sensor ausfällt, aber die Verbindung zu Home Assistant weiterhin besteht. Letzteres ist das eigentliche Risiko, und das lässt sich mit der WF-RAC nicht lösen.
Trotzdem ist das neue WF-RAC ein Träumchen.
Durch die offsets lassen sich die Inneneinheiten extrem gut in ihrer Heizleistung aufeinander abstimmen. Dazu noch den Raumtemperatursensor mit einem Offset auf cirka 19°C bringen bei zu erreichender gewünschter Raumtemperatur. Dadurch kann man dann "Soll" unter 20°C einstellen und somit niedrigste Modulation erreichen. Bei Sollwerten über 20°C fahren die MHI ja die Mindestmodulation nicht mehr an.
Heraus kommt dann so ein sauberer Graph:
Wichtig! Das verwendete Raumthermometer muss wirklich 0,1°C Auflösung haben und gleichmässig in kurzen Abständen Updates senden. Mit zum Beispiel einem Shelly H&T gen3 wird das nicht funktionieren, damit schwingt die Anlage nur Hin und Her da die Temperatursprünge zu grob und zu selten aktualisiert werden.
Auch wenn die Anlage jetzt extrem sauber läuft, Ich werde wohl trotzdem ein zweites ProtoArt verbauen, da sich der Cop damit sehr schön Live errechnen und anzeigen lässt. Dem WF-RAC fehlt dazu leider die real genutzte Lüfterstufe, welche durch techn. Beschränkungen auch nicht kommen wird.
Kannst du mal ein Screenshot von deinem config schicken? Wie du genau die Werte gewählt hast, mit Vorzeichen etc. um die ganze Regelung 2 Grad abzusenken um immer in der minimalen Modulationsbreite zu bleiben?
Das erspart sicher einigen ein bisschen Trial & Error
Viel ist eigentlich nicht dazu. Ich habe in HA einen Templatehelfer erstellt, welcher mir die real gemessene Temperatur um 4°C absenkt. Diesen Helfer gebe ich dann in WF-RAC als zu verwendenden Sensor an.
Im Grunde reicht das schon, denn aus meinen Wohlfühl 23°C werden so 19°C am Thermometer. Klima dann einfach auf 19°C stellen und sie läuft zuverlässig in niedrigster Modulation.
Die Innengeräte selbst lassen sich dann mit diesem Parameter hervorragend in 0,25°C Schritten abstimmen, damit die gewünscht Raumtemperatur auch zuverlässig und genau erreicht/gehalten wird.
Mach das. Je nach Komfort manuell ablesbar oder einen Shelly, wo du über App schauen kannst, was das Gerät auch gerade an Strom zieht. Das ist für die Optimierung im Heizbetrieb sehr sinnvoll.
Selbst wenn die eine eigene Verbrauchsmessung hätte, taugt das oft nicht viel, weil ungenau und z.B. bekommst du keine Momentanwerte der Leistung. Wobei ich die App nicht kenne, weiß nicht, was die anbietet.
Das habe ich allerdings schon mal mit meiner Midea probiert und da funktionierte es nicht. Die Midea braucht eine stete Änderung der Temperatur, denn sonst dreht sie einfach immer weiter auf und versucht mit "Gewallt" eine Temperaturerhöhung zu erreichen. Bekommt sie z.Bsp. permanent 22°C gesendet, dann läuft sie nach ein paar Stunden einfach auf voller Leistung durch.
.
