Neues Modul: 58_DaikinCloud.pm zur Einbindung von Daikin Klimageräten über Cloud

[Mnl]

Das mit dem ESPAltherma ist bestimmt interessant für Bastler und Löt-Enthusiasten; ich gehöre nicht dazu.

Ich sehe eher den Ball bei DAIKIN, die anderen Herstellern von Wärmeerzeugern im Bereich Remote-Monitoring und Remote-Bedienung deutlich hinterherhinken.
Bei meiner Ölheizng z.B. kann ich (abgesehen von den Super-Möglichkeiten in FHEM über BDKM) über die BUDERUS-APP die Anlage steuern, Zeitpläne für Heizen und Warmwasserbereitung hinterlegen, Energiedaten und Sensoren abfragen ...

Da müsste DAIKIN noch kräftig nachlegen...

[Mnl]

Hallo Frank und an alle, die es interessiert:
Hier meine Einbindung des DAIKIN-Cloud-Moduls in FHEM

Screenshot:
Meine Einbindung in FHEM

define Daikin_Master DaikinCloud
attr Daikin_Master autocreate 1
attr Daikin_Master consumptionData 0
attr Daikin_Master interval 60
attr Daikin_Master room Module
#
define WP DaikinCloud c7b2efe8-1664-43ea-8a4a-9dd5f4daf6a4
attr WP devStateIcon on:Ventilator_fett@green off:Ventilator_fett@black
attr WP event-on-change-reading .*
attr WP group Daikin
attr WP icon sani_heating_heatpump
attr WP room Heizung
attr WP webCmd onOffMode:offset
attr WP widgetOverride onOffMode:on,off offset:slider,-10,1,10,1
#attr Daikin_WP webCmdLabel Power<br>:Offset<br>
#
define WP_Daten readingsGroup WP:<%temp_outside>,<Aussentemp.>,outdoorTemperature,<°C> \
WP:<%sani_supply_temp>,<VL-Temp.>,leavingWaterTemperature,<°C> \
WP:<%time_graph>,<Stromverbrauch>,kWh_heating_year,<kWh>
attr WP_Daten group Daikin
attr WP_Daten room Heizung
attr WP_Daten valueFormat %0.0f
attr WP_Daten valueStyle style="text-align:right"

[FrankL]

Wenn du das Reading "kWh_heating_year" anzeigen/auswerten lassen willst, muss im Master-Device

Code Auswählen Erweitern

attr Daikin_Master consumptionData 1 definiert werden. Ansonsten wird das Reading nicht erstellt und fehlt dann in deiner Readingsgroup.

MfG Frank

[Mnl]

Ja, Stimmt !

[Mnl]

Ich muss mich hier nochmal bei Frank für die Entwicklung des DAIKIN-Cloud-Moduls bedanken !!

Ich war schon drauf und dran mir eine externe Zeitschaltuhr installieren zu lassen, damit man die Wärmepumpe zeitgesteuert ein- und ausschalten kann.

Das geht natürlich mit der FHEM-Anbindung viel eleganter;
auch Heizprogramme lassen sich flexibel enpassen, ohne in den Keller rennen zu müssen.

Super !!

[Remstäler]

Hallo,

auch ich habe mit diesem Modul nun meine Daikin Klima-Anlage (Typ Perfera FTXM35R) in FHEM integriert.
Vielen Dank für dieses tolle Modul.

Allerdings ist mir nicht klar, wie ich den Sollwert verändern kann.
Es zeigt mir unter "setpoint" zwar den Sollwert an, aber hierzu gibt es ja keinen Set-Befehl.

Wie kann ich denn die Temperatur anpassen ?
(den schon beschriebenen Offset habe ich an meiner Einheit nicht)

[FrankL]

Eigentlich mit dem Befehl setpoint Zumindest ist das bei meinen Perfera (FTXM20R und FTXM25R) so auch möglich. Sind überhaupt setlist-Einträge vorhanden

Code Auswählen Erweitern

get <name-indoor-device> setlist?

Ansonsten kannst du mir mal deine RawData

Code Auswählen Erweitern

get <name-master-device> rawData senden und ich schau mal, wo der Fehler liegt.

MfG Frank

[Remstäler]

Hallo Frank,

hier ist meine setlist :

demandControl:off,auto,fixed
demandValue:slider,40,5,100,1
econoMode:on,off
horizontal:stop,swing
vertical:stop,swing
fanMode:auto,quiet,fixed
fanLevel:slider,1,1,5,1
onOffMode:on,off
operationMode:fanOnly,heating,cooling,auto,dry
powerfulMode:on,off
streamerMode:on,off
swing:stop,horizontal,vertical,3dswing
fanSpeed:auto,quiet,Level1,Level2,Level3,Level4,Level5


den einzigen "Wert" den ich habe, ist dieser "demandValue" - kenne mich jedoch nicht aus, was dieser bedeutet.

den setpoint selber könnte ich nicht "beschreiben" , der reagiert nicht.
Wobei ich anfangs einen slider hatte, weiß nicht genau was ich falsch gemacht hab und warum der nun fehlt.....

[FrankL]

Welchen operationMode hattest du denn aktuell eingestellt? Bei fanOnly oder dry gibt es keine setpoint einstellung. Die zulässigen Befehle werden immer in Abhängigkeit der aktuellen operationMode dargestellt.

Falls das nicht das Problem sein sollte, kannst du sonst mal das Ergebnis von

Code Auswählen Erweitern

list <name-indoor-device> posten oder per PM schicken. Für eine weitergehende Analyse wäre sonst auch die rawData hilfreich.

Mit demandValue kannst du einstellen (wenn demandControl auf fixed gesetzt ist), auf wieviel Prozent der Leistung das Außengerät runtermodulieren soll. Das hilft ein Takten des Außengerätes zu verhindern und damit auch Energie zu sparen. In der jetzigen Übergangszeit läuft bei mir das Außengerät mit dem Minimalwert von 40 und erbringt bei wenig Stromaufnahme trotzdem optimale Leistung.

MfG Frank

[buennerbernd]

Ich möchte mich auch für das Modul bedanken.
Ich habe eine nagelneue Daikin 3 H HT. Mit deinem Modul kommen schon mal Daten in FHEM an.

Da hier etwas Konfusion um den Offset herrschte.
Die Anlage berechnet mit Hilfe der Heizkurve aus der Außentemperatur einen Sollwert für die Heizkörper. Der Sollwert ist soweit ich verstanden habe der gewünschte Mittelwert zwischen Vor- und Rücklauf. Der Sollwert ändert sich also ständig.
Damit man nicht die Heizkurve neu einstellen muss, falls man mal mit der Temperatur unzufrieden ist, kann man leicht einen Offset zum berechneten Sollwert eingeben und so hoffentlich die gewünschte Temperatur treffen.

In der Onecta-App wird die Wärmepumpe als zwei Geräte dargestellt (Heizung und Warmwasserspeicher).
Ich war etwas überrascht, dass es hier nur ein Device ist. Vielleicht ist das eine Idee, den Code schlank zu halten.

[FrankL]

Danke für die Erläuterungen. Ich kann hinsichtlich der verschiedenen Einstellmöglichkeiten immer nur bedingt weiterhelfen, da ich selbst nur eine Multi-Split-Klima von Daikin im Einsatz habe und keine Altherma. Insoweit kann ich die Eigenheiten der Altherma-Geräte bzw. die unterschiedlichen Modellvarianten/Besonderheiten nur anhand der Zuarbeit der jeweiligen Nutzer über die rawData erahnen

Vom Grundsatz her ist es so, dass Daikin für jedes Gerät, welches über die Onecta-App verbunden wird, eine eindeutige Device-ID ausweist. Diese Device-ID ist das eindeutige Zuordnungskriterium für die weitere Verarbeitung in FHEM. Hierfür wird jeweils ein Device in FHEM mit einem entsprechenden INTERNAL DEF angelegt.

Bei Split-Klimas bzw. Multi-Split-Klimas bekommt jedes Innengerät eine Device-ID, da diese jeweils über ein eigenes Gateway angebunden sind. Bei der Altherma ist es so, dass die Anbindung wohl nur über ein Gateway erfolgt und damit ebenfalls nur eine Device-ID ausgewiesen wird, obwohl sie ggf. mehrere Funktionen (Heizung, Warmwassertank) haben kann (aber nicht muss). In den Strukturen der rawData ist dann ersichtlich, dass neben den üblicherweise vorhandenen managementPoints (gateway, climateControl, indoorUnit, outdoorUnit) weitere managementPoints (z.B. domesticHotWaterTank, indoorUnitHydro, ...) hinzukommen. Wobei ich auch schon festgestellt habe, dass die Benennung der managementPoints nicht immmer identisch ist.

Da ich mich entschieden hatte, die FHEM-Devices nach der eindeutigen Device-ID zu definieren, landen sowohl die Informationen für die Heizung als auch die Warmwasserbereitung mit entsprechenden Readings in einem Device. Eine weitere Aufsplittung in mehrere FHEM-Device würde den Code in der Tat nicht nur aufblähen und komplizierter, sondern auch fehleranfälliger machen. Dafür sind die Kombinationen der mir bislang bekannten managementPoints einfach zu vielfältig. Mein Ziel war es, den Code allgemeingültig für jedwede Kombination einsetzbar zu halten. D.h. das Anlegen der FHEM-Devices erfolgt immer Gateway-bezogen und nicht funktionsbezogen. Insoweit sehe ich das Zusammenfallen der Readings von Heizung und Warmwasserspeicher in einem FHEM-Device nicht als Fehler, sondern eher als "optische Beeinträchtigung" an. Bei Bedarf können hierfür die Attribute "stateFormat", "webCmd", "webCmdLabel" individuell angepasst werden, damit die entscheidenden Informationen oder Befehle im FHEMWEB gut sichtbar bzw. schnell verfügbar sind. Alternativ könnte man auch eine readingsGroup für die wichtigsten Readings erstellen.

MfG Frank
 

[buennerbernd]

Danke, dass du dich auch um Geräte kümmerst, die du gar nicht hast.
Ich kenne das von meinem Velux-KLF200 Modul. Damit wollte ich doch nur meine Rollladen steuern und inzwischen wird das Modul auch für eine Warmwasser-Wärmepumpe eingesetzt.

Schade, dass FHEM keine Hierarchien in den Readings abbilden kann, sonst könnte man die managementPoints übersichtlicher darstellen.
Bei der Anzahl der Readings wird es schnell unübersichtlich.

Könntest du noch den holidayMode unterstützen?
Wenn du interessiert bist, könnte ich dir auch noch rawData schicken, aber eher privat.

[FrankL]

Zu den Readings:
Um die Readings "übersichtlich" zu halten, empfehle ich, das Attribut consumptionData nur im Master-Device auf 1 zu setzen. Dann werden im Indoor-Device bereits die kumulierten kWh-Werte für day, week und year angezeigt. Es reicht dann meines Erachtens sogar aus, den year-Wert für heating/cooling zu loggen.

Die weiteren Energy-Readings, die im Indoor-Device gelistet werden, wenn dort auch das Attribut consumptionData auf 1 gesetzt wird, halte ich eigentlich für nicht notwendig, habe es aber wunschgemäß als Option verfügbar gemacht. Wenn sämtliche Energy-Readings und dann noch von mehreren managementPoints angezeigt werden, wird es halt schnell unübersichtlich.

Die verbleibenden Readings finde ich aber ganz aussagekräftig und "übersichtlich". Im Endeffekt interessieren ja meistens immer ganz bestimmte Readings (onOffMode, operationMode, setpoint, roomTemperature, etc). Insoweit wäre es vielleicht auch eine Lösung bestimmte Readings zu einem userReadings zusammenzufassen:

Code Auswählen Erweitern

attr <name-Indoor-Device> userReadings Info_Klima:.* {'P: '.sprintf("%3.3s",ReadingsVal($name,'onOffMode','0')).' M: '.sprintf("%4.4s",ReadingsVal($name,'operationMode','0')).' Z: '.sprintf("%4.1f",ReadingsVal($name,'setpoint','0')).' T: '.sprintf("%4.1f",ReadingsVal($name,'roomTemperature','0'))}

So könnte man auch die interessierenden Readings für verschiedene Funktionsgruppen (Heizung, Warmwasser) in verschiedenen userReadings übersichtlich zusammenfassen. Oder halt das Attribut stateFormat verwenden, um in der Raumübersicht von FHEMWEB einen Überblick über die wichtigsten Readings zu erhalten.

Zum holidayMode:
Ich hatte (eigentlich) nicht vor, die (Wochen-)Timer-Programme oder den Urlaubsmodus (holidayMode) mit einzubinden. Gerade die Integration der Geräte in FHEM lässt ja eine zeit- oder automationsgestützte Steuerung der Geräte zu. Ich fände es daher auch eher konktraproduktiv, wenn die Steuerung über Wochen-Timer-Programme und gleichzeitig zeit- oder automationsgesteuert über FHEM erfolgen würde.

Nach den Erklärungen in der Onecta-App bewirkt der holidayMode: "Im Urlaubsmodus ist das Gerät ausgeschaltet und Zeitpläne sind deaktiviert." Da ich die Wochen-Timer-Programme schon nicht im Modul integriert habe, sehe ich auch keinen Sinn den holidayMode zur Unterbindung der Wochen-Timer-Programme ins Modul zu integrieren. Die Integration wäre auch ziemlich komplex, da die zulässigen Einstellparameter - im Gegensatz zu den sonstigen in der setlist enthaltenen Befehlen - in den rawData nicht aufgeführt sind. Von daher wäre es auch schwieriger, gewisse Plausibilitätsprüfungen durchzuführen, damit auch sichergestellt ist, dass die gesendeten Befehle auch tatsächlich 1:1 umgesetzt werden.

Ich selber nutze weder die Timer-Programme über die IR-Fernbedienung, noch über die Onecta-App. Ich denke auch, dass sich über FHEM der "eigene individuelle Zeitplan und Urlaubsmodus" viel besser realisieren bzw. automatisieren lässt Ich lasse mich aber gerne eines besseren belehren.

MfG Frank

[skycrack]

Hallo Frank,

Ich hatte die Steuerung ebenso über NodeRed und Mqtt umgesetzt, allerdings hängt es gerade an dem Tokenrefresh, der nicht mehr sauber funktioniert.
Da bin ich auf dein neues Projekt gestoßen und finde es ist Zeit dir für diese Leistung Danke zu sagen.
Einfach genial und vielen Dank
Gruß Rene

[FrankL]

Danke für das positive Feedback.

Ich hab noch ein paar Optimierungen beim Setzen bestimmter Befehle vorgenommen, die manchmal von der Cloud nicht ordnungsgemäß abgearbeitet worden sind. Ferner beginnt nun beim Absetzen eines Befehles das Polling-Interval von vorn, damit nicht direkt nach dem Absetzen des Befehles zufälligerweise der regelmäßige Polling-Abruf noch veraltete Daten bzw. noch nicht verarbeitete Daten aus der Cloud empfängt. Weiterhin habe ich die Logmeldungen vereinheitlicht und die Commandref aktualisiert.

Die aktuelle Version v1.3.5 ist im Anhang verfügbar. Die jeweils aktuelle Modul-Datei ist ersten Post hier zu finden. Ich würde damit die Beta-Phase für beendet erklären und sehe die Version aktuell als final an.

Für eine Aktualisierung die 58_DaikinCloud.pm herunterladen und in den Ordner fhem/FHEM kopieren. Danach das

Code Auswählen Erweitern

reload 58_DaikinCloud.pmnicht vergessen.

MfG Frank