Neues Modul: 58_DaikinCloud.pm zur Einbindung von DAIKIN Geräten über Cloud (ONECTA)

[FrankL]

Die Energiedaten werden von der Daikin-Cloud nur in 2-Stunden-Fenstern bereit gestellt. Der aktuelle Leistungsbezug lässt sich über die Cloud nicht abfragen/anzeigen. Da hilft dann nur ein Shelly (bzw. ein Tasmota-Messgerät) in der Stromzuleitung. Und das finde ich echt hilfreich, um besser einschätzen zu können, ob die Klimaanlage sparsam, aber effektiv arbeitet und nicht zu oft taktet.

Man kann auch selber schauen, was die Cloud bzw. die API von Daikin insgesamt an Json-Daten liefert. Dazu einfach im Master-Device das Attribut "SaveRawData" auf "1" setzen. Dann werden die gesamten Json-Daten ab dem nächsten Abruf auch als reading "jsonRawData" im Master-Device gespeichert.

MfG Frank

[Prof. Dr. Peter Henning]

Danke.

Da hilft dann nur ein Shelly (bzw. ein Tasmota-Messgerät) in der Stromzuleitung

Na, da gibt es aber auch noch andere Möglichkeiten.

Ich schlage noch vor, die Readingnamen etwas an die sonstigen FHEM-Gepflogenheiten anzupassen.

onOffMode -> status
operationMode -> mode
kWh_cooling_day -> energy_cooling_day (etc. für die anderen Energiemesswerte)
roomTemperature -> temperature(_measured)
setpoint -> temperature_desired
outdoorTemperature -> temperature_outdoor
roomHumidity -> humidity(_measured)

LG

pah

[Gisbert]

Ich schlage noch vor, die Readingnamen etwas an die sonstigen FHEM-Gepflogenheiten anzupassen.

onOffMode -> status
operationMode -> mode
kWh_cooling_day -> energy_cooling_day (etc. für die anderen Energiemesswerte)
roomTemperature -> temperature(_measured)
setpoint -> temperature_desired
outdoorTemperature -> temperature_outdoor
roomHumidity -> humidity(_measured)

Sehr schön, damit können dann alle ihre funktionierenden Installationen und Automatisierungen umstellen - ich bin nicht begeistert.

[FrankL]

Ich kann den Wunsch zwar nachvollziehen, die Readings mehr an übliche Benennungen anzupassen, sehe da aber mehr Probleme wie Nutzen.

Die Readingnamen werden aktuell fast ausschließlich aus den Json-Daten extrahiert, die die Daikin-Cloud liefert. Da das Modul möglichst flexibel jede Art von Gerät (also verschiedene Innengeräte bei [Multi-]Splitklimaanlagen, Altherma-Wärmepumpen, etc) auslesen soll und es bereits bei den Altherma-Geräten verschiedene Arten der Steuerung und Sensoren (Steuerung über Raumtemperatur, Rücklauftemperatur, Außentemperatur) gibt, halte ich z.B. ein hartes Verlinken des jeweils maßgebenden Datenpunktes auf temperature(_measured) für schwer machbar bzw. problematisch. Ebenso gibt es z.B. bei einigen Altherma-Geräten mehrere Varianten des Readings für "operationMode" bzw. "operationMode_xxx", die z.B. für Heizung und Warmwasserbereitung zuständig sind. Auch da wäre ein allgemeines Herunterbrechen auf ein einheitliches Reading "mode" problematisch.

Letztlich habe ich mich auch dafür entschieden, die Datenpunkte so zu belassen, wie sie aus der Cloud kommen, damit das Absetzen der zulässigen "Set-Befehle" für alle Geräte basierend auf dem jeweiligen Readingnamen mit dem entsprechenden Datenpunkt in der Cloud sichergestellt ist bzw. verknüpft bleibt.

Die Datenpunkte sind halt bei der Vielzahl der über die Onecta-App steuerbaren Geräte derart unterschiedlich, dass sich da eine Verallgemeinerung von Readingnamen nur schwer realisieren lässt.

Im Endeffekt stimme ich aber auch Gisbert zu. Viele haben ihre Automatisierung bzw. das Logging auf die bestehenden Readings ausgerichtet. Daher getreu dem Motto: never change a running system

Falls dennoch das Bedürfnis besteht, einheitliche (zusätzliche) Readingnamen für bestimmte Datenpunkte im Device haben zu wollen, ließe sich das hilfsweise über das Attribut userReadings realisieren. Mir ist aber durchaus bewusst, dass das eine umständliche Lösung wäre.

MfG Frank

[Prof. Dr. Peter Henning]

Nun, das kann jeder Modulautor selber bestimmen. Allerdings plädiere ich in FHEM dennoch für eine minimale Standardisierung.

Es ist übrigen keineswegs so, dass die bisherigen Readings den JSON-Daten entsprechen. "kwh_heating_day" etc. ist beispielsweise eindeutig selbst erfunden - und es ist, pardon, nicht optimal, Readingnamen mit der Einheit anzufangen.

Viele haben ihre Automatisierung bzw. das Logging auf die bestehenden Readings ausgerichtet. Daher getreu dem Motto: never change a running system

Wenn wir das so handhaben würden, gäbe es keinen Fortschritt.

LG

pah

P.S.:

Sehr schön, damit können dann alle ihre funktionierenden Installationen und Automatisierungen umstellen - ich bin nicht begeistert.

Es war doch immer schon mein Begehren, Gisbert zu begeistern. 

[FrankL]

Es ist übrigen keineswegs so, dass die bisherigen Readings den JSON-Daten entsprechen. "kwh_heating_day" etc. ist beispielsweise eindeutig selbst erfunden - und es ist, pardon, nicht optimal, Readingnamen mit der Einheit anzufangen.

Naja ich hatte ja geschrieben, dass die Readingnamen fast ausschließlich aus den Json-Daten generiert werden. Die Readings "kWh_cooling_day, kWh_cooling_week, kWh_cooling_year, kWh_heating_day, kWh_heating_week, kWh_heating_year" gehören natürlich nicht dazu . Da die "Roh-Energie-Daten" aus der Daikin-Cloud für ein Logging nicht wirklich brauchbar waren (Erläuterung siehe hier), werden die Tages-, Wochen- und Jahreswerte berechnet und als eigenständiges Reading erstellt. Dass ich damals die Readings mit "kWh_..." begonnen habe, war wohl eher eine spontane Aktion. Dahingehend wäre ich offen für eine Umbenennung in ...

• z.B. energy_cooling_day

oder bezugnehmend auf deine Frage:

Kann mir jemand bitte noch sagen, auf was sich die Energieangaben in den Readings beziehen? Sind "kWh_cooling_day" und "kWh_heating_day" die abgegebene thermische Energiemenge, oder die elektrisch aufgenommene Energiemenge?

dann lieber gleich:

• z.b. energy_electrical_cooling_day

Ich fände es im Übrigen auch interessent, ob es mittlerweile Geräte von Daikin gibt (egal ob LLWP oder Altherma), die die thermische Energie messen und diese Werte auch in der Onecta-App darstellen. Die BAFA wollte das ja ab 2023 zur Voraussetzung für eine weitere Förderung machen. Ich hab das aber nicht weiter verfolgt, was da letztlich bei rausgekommen ist. Falls also jemand in der Onecta-App auch die thermische Leistung angezeigt bekommt, würde ich mir gern mal die entsprechenden Json-Rohdaten anschauen. Falls da jemand ein aktuelles Gerät hat, kann er im Master-Device mal das Attribut:

Code Auswählen Erweitern

attr <master-device> saveRawData 1setzen und nach dem nächsten Abruf im Master-Device das Reading "jsonRawData" mal nach "kWh" durchsuchen (STRG+F) und schauen, ob davor mal nicht "electrical", sondern z.B. "thermal" oder so steht ...

MfG Frank

[Gisbert]

Hallo Frank,

bei meinem master-device taucht lediglich im Reading jsonRawData nur einmal der Begriff "electrical" auf, "therm..." gar nicht.

Falls in irgendeiner Form an Änderungen von Readingsnamen gedacht wird, dann wäre sicher eine Art von Plan notwendig, der dich und die von deinem Modul begeisterten User nicht überfordert. Ich weiß nicht, ob der Hinweis auf das SolarForecast-Modul von DS_Starter hilft, der nicht nur im Forum sondern auch im Device auf Änderungen und neue Versionen hinweist, z.B. Readings- und Attributsnamen. Oft ist für die User selbst bei größeren Veränderungen wenig zu tun. Das ist natürlich aus Sicht der User erfreulich, allerdings liegt die Arbeit im Feld des Modulautors. Für mich steht die Funktionalität deines Moduls im Vordergrund.

Viele Grüße Gisbert

[Prof. Dr. Peter Henning]

Umbenennen der "kwh"-Readings: Sehr starke Befürwortung meinerseits, und gerne mit "electrical". Oder abgekürzt "e".

setzen und nach dem nächsten Abruf im Master-Device das Reading "jsonRawData" mal nach "kWh" durchsuchen (STRG+F) und schauen, ob davor mal nicht "electrical", sondern z.B. "thermal" oder so steht ...

Mit nagelneuen Geräten: Habe ich längst gemacht, da steht nichts von "thermal". Das ist auch nicht ganz einfach, denn man müsste dafür die Temperaturen Vorlauf/Rücklauf des Kältemittels sowie den Fluss messen, und das mit den Eigenschaften des Kältemittels verrechnen. Wie das geht, habe ich 2014 am Beispiel der Solarthermie gezeigt, siehe https://wiki.fhem.de/wiki/Ertragsmessung_Solarthermie.

Wenn das also nicht von Daikin selbst implementiert wird, ist das wegen des notwendigen Eingriffs in den Kühlkreislauf kaum möglich.

@Gisbert: Du bist seit mehr als 10 Jahren bei FHEM dabei. Also weißt du ganz genau, dass manchmal Abwärtskompatibilität ein Fehler ist. Also hab Dich bitte nicht so, die paar Zeilen wirst Du eben anpassen müssen. Das ist jedenfalls weniger Arbeit, als selbst ein Modul zu schreiben...

LG

pah

[Gisbert]

@pah, keine Frage, dass krieg ich mit Sicherheit hin, Definitionen in Automationen und Log-Dateien zu ändern, inkl. Änderung der Inhalte von Log-Dateien, sowie Plots. Letztlich muss Frank das entscheiden, er hat schließlich die Entwicklung durchgeführt und die letztens von Daikin aufgezwungenen Beschränkungen für die User umgesetzt.

Manchmal lässt sich Einheitlichkeit bei der Benennung von Readingnamen nur schwer umsetzen, jedenfalls nicht ohne deutliche Nebenwirkungen. Man kann natürlich z.B. bei MQTT-Devices als User in Fhem einheitliche Readingnamen verwenden, dann hat man aber den Fakt, dass die Topics meist anders lauten als die Readingnamen. Bei Heishamon (Projekt inkl. Platine zum Auslesen von Panasonic-Wärmepumpen) oder das Auslesen von DEYE-Wechselrichtern (diverse Github-Projekt, teils inkl. Platine) erhält man gut und gerne > 100 Topics. Diese Entwickler - es sei Ihnen an dieser Stelle gedankt - haben aber mit Fhem so gar nichts zu tun. Wenn man da versucht einen Fhem-Standard bei den Readingnamen reinzubekommen, wird es nicht übersichtlicher. Beim Stöbern in anderen Foren, müsste man sich eigentlich noch eine Übersetzungsliste Topic - Readingnamen (vom Inhalt ganz zu schweigen) daneben legen, um den Überblick zu behalten.

Ich kann mit jeder Änderung und Verbesserung gut zurechtkommen und begrüße es natürlich, wenn die Funktionalität und Übersichtlichkeit gegeben ist. Ansonsten, ich nehme, was ich kriegen kann, und versuche das Beste für mich draus zu machen.

Viele Grüße Gisbert