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

Begonnen von FrankL, 05 April 2023, 20:48:40

Vorheriges Thema - Nächstes Thema

FrankL

Hallo liebe FHEM-Gemeinde,

ich möchte an dieser Stelle das von mir geschriebene Modul 58_DaikinCloud.pm vorstellen. Es dient der Einbindung von Daikin-Geräten (Klimageräte, Altherma-Wärmepumpen, etc), die nur noch per Cloud über die ONECTA-App erreichbar sind. Betroffen hiervon sind insbesondere die Innengeräte, die mit einem WLAN-Modul vom Typ BPR069C4X ausgestattet sind und über keine lokale API mehr verfügen (und damit nicht mehr über 58_HVAC_DaikinAC.pm integriert werden können).

Mit den Modulversionen v1.x.x erfolgte bislang der Zugriff auf die Daikin-Cloud über eine per Reverse Engineering entwickelte Lösung. Dieser Zugang bzw. die entsprechenden Zugangs-Keys werden von Daikin am 03.07.2024 deaktiviert! Mittlerweile hat Daikin aber für die Cloud-Anbindung eine offene API geschaffen und dokumentiert. Auf dieser offenen API basieren nunmehr die Modulversionen v2.x.x!

Die Einrichtung (bzw. die Umstellung von der Modulversion v1.x.x auf v2.x.x.) wird hier beschrieben. Ich versuche die Beschreibung bzw. mögliche Änderungen auch hier im ersten Post aktuell zu halten.

1. Vorbereitung

Damit die Klimageräte gesteuert werden können, ist es erforderlich, dass der Registrierungsprozess in der ONECTA-App abgeschlossen worden ist. Das heißt die Innengeräte sind mit dem Internet verbunden und in der ONECTA-App ersichtlich.

Um die Schnittstelle (API) von Daikin nutzen zu können, muss zunächst das Daikin Developer Portal aufgerufen werden. Dort meldest du dich mit den Zugangsdaten für die ONECTA-App an.

Im Daikin Developer Portal legst du wie folgt eine neue APP an: Rechts oben bei deiner E-Mail-Adresse öffnest du das Drop-Down-Menü und wählst My Apps -> New App. Du vergibst einen frei wählbaren Application Name (z.B. FHEM - DaikinCloud). Ferner definierst du die REDIRECT_URI. Die REDIRECT_URI wird im Rahmen des Authorisierungsprozesses nur einmal benötigt, um den initialen Authorisierungscode vom Authorisierungsserver zu erhalten. Am einfachsten ist es, dort die Adresse https://my.home-assistant.io/redirect/oauth zu verwenden.

Es besteht auch die Möglichkeit, eine individuelle REDIRECT_URI für FHEM zu definieren. Diese muss nach folgendem Schema erstellt/definiert werden: https://<ip-fhem-server>:8083/fhem?cmd=set%20<Master-Device-Name>%20AuthCode%20. Hierbei ist zu beachten, dass nur sichere Verbindungen (also https) als REDIRECT_URI akzeptiert werden. Eine individuelle REDIRECT_URI funktioniert also nur, wenn ihr SSL auf eurem FHEM eingerichtet habt. IP-FHEM-Server und Master-Device-Name sind durch die entsprechende IP und Device-Namen zu ersetzen. Ferner ist zu beachten, dass bei Nutzung des csrfToken in FHEM (Standard ab FHEM-Version 5.8) noch ein &fwcsrf=<dein CSRF-Token> angehangen wird (zu ersetzen durch den jeweiligen CSRF-Token -> vgl. INTERNAL CSRFTOKEN im Device FHEMWEB). Da die individuelle Konfiguration der REDIRECT_URI mit vielen Fallstricken verbunden ist, kann ich jedem Einsteiger nur empfehlen stattdessen https://my.home-assistant.io/redirect/oauth als REDIRECT_URI zu verwenden.

Im Anschluss werden dir die CLIENT_ID und (einmal!) das CLIENT_SECRET angezeigt. Kopiere und speichere dir diese beiden Werte. Achte insbesondere darauf, das CLIENT_SECRET zu speichern, da es nur dieses eine Mal angezeigt wird! Solltest du das CLIENT_SECRET nicht gespeichert haben oder nicht mehr wissen, hilft nur die App im  Daikin Developer Portal zu löschen und neu anzulegen.


2. Installation

a) Damit das Modul in FHEM verwendet werden kann, ist der folgende update-Befehl in FHEM auszuführen:
update all https://raw.githubusercontent.com/frank-lie/DaikinCloud/main/controls_DaikinCloud.txt

Um automatisch immer die aktuelle Version des Moduls im Rahmen des FHEM-Befehls update zu erhalten, kann man den Link auch generell als Update-Quelle hinzufügen:

update add https://raw.githubusercontent.com/frank-lie/DaikinCloud/main/controls_DaikinCloud.txt

b) Nach einem Update von FHEM sollte in der Regel ein Neustart von FHEM gemacht werden, damit alle Änderungen ordnungsgemäß geladen werden:

shutdown restart

c) Für die Kommunikation mit der Daikin-Cloud ist in FHEM zunächst ein Master-Device anzulegen:

define <NAME Master-Device> DaikinCloud <CLIENT_ID> <CLIENT_SECRET> <REDIRECT_URI>

Verwende hierfür die unter Vorbereitung gespeicherten Werte für CLIENT_ID und CLIENT_SECRET. Achte darauf, dass die REDIRECT_URI zu 100% identisch mit der im Daikin Developer Portal angegebenen REDIRECT_URI ist. Ansonsten wird die Authorisierung fehlschlagen.

Wenn bereits ein Master-Device aus der Modulversion v1.x.x vorhanden ist, kannst du einfach eine Änderung/Umstellung wie folgt durchführen:

defmod <NAME Master-Device> DaikinCloud <CLIENT_ID> <CLIENT_SECRET> <REDIRECT_URI>

d) Sobald das Master-Device erstellt worden ist, kann der AUTHORIZATION_LINK (zu finden als INTERNAL im Master-Device) aufgerufen werden, um den Authorisierungsprozess zu starten. Ihr werdet auf die Seite von Daikin geleitet, müsst euch dort einloggen, den Nutzungsbedingungen zustimmen und die Freigabe der Daten erlauben. Anschließend werdet ihr auf die REDIRECT_URI weitergeleitet.

e) Wenn ihr eine individuelle REDIRECT_URI für FHEM konfiguriert habt, wird der Authorisierungscode automatisch an FHEM übergeben. Wenn dies nicht funktioniert, überprüft eure REDIRECT_URI oder verwendet die oben angegebene allgemeime REDIRECT_URI. Bei Verwendung der allgemeinen REDIRECT_URI erfolgt eine Weiterleitung/Mitbenutzung von https://my.home-assistant.io/redirect/oauth, um den Authorisierungscode zu bekommen. Bevor ihr eine Fehlermeldung wie "Invalid paramaters given" wegklickt, muss der komplette Link der Internetseite aus dem Browser (https://my.home-assistant.io/redirect/oauth/?code=xxxxxxxxxxxx) in die Zwischenablage kopiert und in FHEM als set-command eingegeben werden:

set <NAME Master-Device> AuthCode <kompletter Link der Rückgabe-URL>

f) Mit dem Setzen des Authorisierungscodes bekommt FHEM die erforderlichen Token für den Zugriff auf die Daikin-Cloud übermittelt. Die Einrichtung des Master-Devices ist damit abgeschlossen. Die Innengeräte werden standardmäßig beim Abruf der Daten aus der Cloud als Device in FHEM angelegt. Standardmäßig werden die Daten aus der Cloud alle 900 Sekunden abgerufen / aktualisiert.


3. Verwendung

Die Daten werden in den Readings der jeweiligen Innengeräte dargestellt. Die Innengeräte können über verschiedene "Set"-Befehle gesteuert werden. Die möglichen/zulässigen Befehle sind jeweils modellabhängig. Eine nähere Dokumentation hierzu ist im Modul selbst enthalten.

Aktuell hat Daikin Request-Limits für das Abrufen der Cloud-Daten und das Senden von Kommandos hinterlegt. Pro Tag können maximal 200 Anfragen und pro Minute maximal 20 Anfragen gesendet werden. Sowohl bei dem 24-Stunden-Limit als auch dem 1-Minuten-Limit handelt es sich um gleitende Zeitfenster, die fortlaufend aktualisiert bzw. immer zeitweise zurückgesetzt werden.

Aktuell sind (noch) nicht alle Datenpunkte in der neuen API enthalten. Es fehlen insbesondere: dryKeepSetting, fanMotorRotationSpeed, heatExchangerTemperature, suctionTemperature und diverse wifi-readings. Ferner sind z.B. demandControl und demandValue nicht vorhanden, so dass aktuell auch keine Bedarfssteuerung möglich ist. Es handelt sich hierbei um Einschränkungen, die die neue API mit sich bringt und damit durch das Modul auch nicht behoben oder beseitigt werden können. Sobald Daikin die Daten in der neuen API zur Verfügung stellt, stehen diese automatisch auch (wieder) in FHEM zur Verfügung.

MfG Frank

Starkstrombastler

Hallo Frank,

das sind großartige Neuigkeiten! Das Modul funktioniert auf Anhieb so wie von dir beschrieben. Echt Super!

Meine Installation umfasst ein Multisplitgerät mit drei Inneneinheiten und ein Single-Split-System. Alle Einheiten wurden in kurzer Zeit gefunden und als Geräte in fhem angelegt. Zahlreiche Readings sind vorhanden, und mit Daten gefüllt (Ausnahme: "errorCode_gateway").

Die Steuerung der Geräte via fhem funktioniert, ebenso wie das Polling der Cloud.

Noch zur Info meine Daikin-Hardware:
Multisplit
   Außeneinheit:    3MXM68N2V1B9 
   Inneneinheiten:  FTXM42R2V1B und 2x FTXM20R2V1B   mit WLAN-Modul BRP069C4x
Singlesplit
   Außeneinheit:    RXM25N9
   Inneneinheit:    FTXM25N     mit WLAN-Modul BRP069B4x


Herzlichen Dank und Grüße
Bernhard
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

JoergBo

Hi,

ich habe hier eine sehr ähnliche Konfiguration:

Ein Außengerät 3MXM40A, drei Innengeräte, 2x FTXM20R 1x FTXM25R (Wlan BRP069C4x)

Installation des Moduls 5 min. incl. download, alle Geräte erkannt.
Einstellungen und Istwerte werden gelesen.

PERFEKT!

Lg, Jörg
RasPI4, S5-95U, Hue, Volkszaehler, 1wireTemp, HMLan, sduino, Wlan-IR-Gateway, TelegramBot, Alexa, ...

FrankL

Zitat von: Starkstrombastler am 06 April 2023, 09:46:35Zahlreiche Readings sind vorhanden, und mit Daten gefüllt (Ausnahme: "errorCode_gateway").

Das Reading errorCode_gateway hat auch bei mir keinen Wert. Das stimmt auch so mit den JSON-Rohdaten aus der Daikin-Cloud überein, ist also kein Fehler. Dort hat dieser Key ebenfalls den Wert "" (leer). Ich gehe davon aus, dass der Wert erst dann gefüllt wird, wenn tatsächlich mal ein Fehler vorliegen sollte. Ob man dann mit den Fehlercodes tatsächlich was anfangen kann, ist natürlich eine andere Frage.

Auf jeden Fall schön zu hören, dass es auch mit anderen Kombinationen, also sowohl mit anderen Multi-Split-Kombis als auch mit Single-Split-Installationen problemlos läuft.

MfG Frank

Gisbert

Hallo Frank,

ich hab dir eine PM geschrieben - hab erst danach gesehen, dass du einen neuen Thread aufgemacht hast.
Ich hab die bisher einzige Fehlermeldung dort gepostet. Vielleicht kannst du damit etwas anfangen.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Starkstrombastler

Ich habe mir die energy-Readings angeschaut - und musste erstmal etwas knobeln um da durchzusteigen.

Der Vergleich mit den Daten in der App liefert folgende Erkenntnis:

Die d-Readings beziehen sich auf 2-Stunden-Zeitscheiben gestern (d1..d12) und heute (d13...d24).

Die w-Readings beziehen sich auf ganze Tage (Mo...So) der letzten Woche (w1...w7) und aktuelle Woche (w8...w14).

die m-Readings beziehen sich auf ganze Monate (Jan...Dez) im letzten Jahr (m1...m12) und aktuelles Jahr (m13...m24).

Einige Readings liegen in der Zukunft und sind naturgemäß mit Null gefüllt.

Erkenntnis:
- das kleinste sinnvolle Polling-Intervall für die energy-Readings ist 7200 sek.
- der besseren Lesbarkeit wegen bietet sich ein Mapping der Reading-Namen an, so dass die jeweiligen Zeitintervalle besser erkennbar sind.

Allerdings bilden diese Daten nur einen begrenzten Zeithorizont ab und sind in fhem nicht so einfach grafisch (SVG) darzustellen. Daher folgende Idee: Es wird nur für den zuletz aktualisierten Wert einer Gruppe (heating|cooling_d|w|m) ein Reading erzeugt und in der Standardansicht (attr ConsumptenData 0) dargestellt. Die Anzahl der energy-Readings schrumpft damit von 124 auf 6. Mit fhem-Bordmitteln können diese einfach archiviert und grafisch aufbereitet werden.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

FrankL

Hallo Bernhard,

ich hatte die energy-Readings optional mit eingebaut, aber der Auswertung noch keine große Beachtung geschenkt, weil sie nicht "live" aufgezeichnet/aktualisiert werden, sondern nur im 2-Stunden-Takt und auch die Genauigkeit (kleinste Einheit 100 Wh) und der tatsächliche Verbrauch von meinen gemessenen "realen" Werten gewissene Abweichungen hat. Ich messe bei mir den Verbrauch mit einem Tasmota-Gerät (SONOFF ‎POWR316D), der mir das ganze besser darstellt/aufzeichnet.

Die Daten habe ich bisher stumpf aus den JSON-Werten, die aus der Cloud kommen, extrahiert. Damit sind sie natürlich genauso schön (oder eben auch häßlich), wie sie auch in der ONECTA-App zu sehen sind. Ich gebe dir Recht, dass die Bezeichnungen der energy-Readings nicht gerade selbsterklärend sind.

Nun zu deiner Idee: Ein separates Polling-Intervall für die energy-Readings von 7200 lässt sich nur bedingt umsetzen. Die Abfrage der Clouddaten bzw. die Antwort von der Cloud enthält immer alle Daten, erst bei der Verarbeitung der JSON-Daten kann ich entscheiden, gewisse Daten nicht zu verarbeiten, um Rechenressourcen zu sparen.

Standardmäßig habe ich den erstellten Indoor-Unit-Devices in FHEM das Attribut "event-on-change-reading" spendiert, d.h. es werden nur Events getriggert, bei denen ein geänderter Wert empfangen worden ist. Ich hätte jetzt gedacht, dass das fürs loggen der energy-Readings brauchbar wäre. Ein Mapping der Reading-Namen wäre aber tatsächlich sinnvoll.

Mein Problem ist eher folgendes: Ich wollte das Modul sehr universell für jedwede Geräte von Daikin halten und habe daher versucht, auf eine individuelle Veränderung/Verarbeitung der Cloud-Daten zu verzichten, da ich nicht weiß, ob die Daten von den verschiedenen Geräten jeweils identisch sind. Das fängt halt schon beim unterschiedlichen Funktionsumfang der verschiedenen Innengeräte an. Von daher weiß ich nicht, ob die consumptionData bei allen Geräten 100% identisch gestrickt ist.

Zur Not hilft es vielleicht auch erstmal vorübergehend, sich ein eigenes userReadings-Attribut anzulegen, was zur Verarbeitung/Loggen der Werte dient. Ich werde bei mir die energy-Readings mal mit loggen und schauen, was für Erkenntnisse ich daraus gewinnen kann.

MfG Frank


FrankL

Ich hab mir jetzt mal eine simple Lösung überlegt, mit der der fortlaufende Jahresverbrauch in einem Reading ermittelt und dann geloggt werden könnte. Ich hab es bei mir aber zum Testen erstmal nur als userReadings angelegt. Wenn sich das so bewähren sollte, würde ich es mit ins Modul übernehmen.

Wenn jemand ebenfalls mit testen möchte, kann er bei sich unter dem attribut userReadings der jeweiligen Indoor-Devices folgenden Code speichern:

energy_heating_year:energy_heating_m.* { my $kWh=0; for (my $i=13; $i<25; $i++) {$kWh += ReadingsNum($name,'energy_heating_m_'.$i,0)}; $kWh},
energy_cooling_year:energy_cooling_m.* { my $kWh=0; for (my $i=13; $i<25; $i++) {$kWh += ReadingsNum($name,'energy_cooling_m_'.$i,0)}; $kWh}

Voraussetzung ist, dass das attribut consumptionData im Cloud-Device und in dem jeweiligen Indoor-Device auf 1 gesetzt ist.

Damit wird jeweils der aufsummierte Jahresverbrauch des aktuellen Jahres für heating und cooling als entsprechendes Reading angelegt. Wenn diese beiden Readings geloggt werden, lässt sich damit dann auch eine weitere grafische Auswertung (SVG) gut realisieren.

Als kleiner Nachteil: Zum 01.01. eines jeden Jahres würde der Jahreszähler wieder bei 0 beginnen.

Ich denke, dass dann ein seperater Tagessummen- oder Wochensummenzähler nicht erforderlich ist. Er könnte aber nach dem gleichen System realisiert werden.

MfG Frank

Starkstrombastler

Hallo Frank,
für ein genaues Monitoren sind die Energy Readings eher ungeeignet. Wird aber kein separater Zähler eingesetzt sind damit zumindest tendenzielle Aussagen möglich. Daher halte ich es auf jeden Fall für sinnvoll, die Werte in ein paar wenigen Readings zu aggregieren.

Auf jeden Fall werde ich die vorgeschlagenen User-Readings ausprobieren.

MfG
Bernhard
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

FrankL

#9
Hallo Bernhard,

ich hab deine Idee umgesetzt und eine geänderte 58_DaikinCloud.pm hochgeladen (aktuelle Datei jeweils im ersten Post hier). Die Umsetzung habe ich wie folgt vorgenommen:

Sobald im Master-Device das attribut consumptionData auf 1 gesetzt wird, werden in den Indoor-Units jeweils readings für kumulierte Tages-, Wochen- und Jahreswerte für heating und cooling erzeugt (beginnend jeweils mit "kWh_.."). Wobei es reichen dürfte, den Jahreswert zu loggen. Damit kann man auch zur grafischen Aufbereitung was anfangen. Wenn man im SVG die "delta-d" Funktion verwendet, bekommt man aus den kumulierten Jahreswerten auch die Tageswerte schön angezeigt.

Wenn zusätzlich in der Indoor-Unit das attribut consumptionData auf 1 gesetzt wird, werden in der jeweiligen Indoor-Unit die "Roh-Daten" wie bisher mit angezeigt. Auf ein weiteres Mapping habe ich verzichtet, weil mir das zu aufwendig war bzw. ich aufgrund des o.g. kumulierten Jahreszählers keine Notwendigkeit mehr sehe.

Darüber hinaus habe ich die Fehlermeldung von Gisbert zum Anlass genommen, noch eine Plausi-Prüfung einzuführen: Ein Set-Befehl für eine Indoor-Unit kann grundsätzlich nur erfolgreich abgesetzt werden, wenn die Indoor-Unit auch aktuell mit der Cloud verbunden ist (reading isCloudConnectionUp == true). Dies ist zu beachten, falls z.B. die Geräte per Relais zeitweise (z.B. über Nacht) komplett stromlos gemacht werden. Dann sollte bei automatisierten Abläufen darauf geachtet werden, dass nach dem Einschalten des Stromes ca. 2 Minuten (d.h. ca. 1 Minute bis das Gerät "hochgefahren" ist und sich mit dem Internet/der Cloud verbunden hat + 1 weitere Minute für das erste erfolgreiche Polling mit "isCloudConnectionUp == true") gewartet wird, bis Set-Befehle automatisiert an die Indoor-Unit gesendet werden. Bei mir ist Klimaanlage sonst immer in StandBy, daher war mir diese Problematik bislang nicht aufgefallen.

Für eine Aktualisierung die 58_DaikinCloud.pm herunterladen und in den Ordner fhem/FHEM kopieren. Danach das
reload 58_DaikinCloud.pm
nicht vergessen. Die kWh-Werte kommen dann automatisch beim nächsten Polling, wenn im Master-Device consumptionData auf 1 gesetzt ist.

MfG Frank

Gisbert

Hallo Frank,

vielen Dank für dein Update.
Ich versuche (verzweifelt) dein Modul downzuloaden. Beim Antippen öffnet sich ein neues Fenster mit dem Inhalt des Moduls, auch der Download-Zähler geht eins nach oben, aber die Datei wurde nicht runtergeladen.
Liegt das an der neuen Forums-Software oder an deiner Datei?

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

FrankL

Hallo Gisbert,

das wird wohl an den Einstellungen deines Browsers liegen, wenn er die pm-Dateien standardmäßig anzeigen will, statt herunterzuladen. Du kannst aber auch einfach einen Rechtsklick auf die Datei/Link machen und wählen "Ziel speichern unter ..."

Ich hab den aktuellen Stand auch immer im github unter https://github.com/frank-lie/DaikinCloud abgelegt.

MfG Frank

Gisbert

Hallo Frank,

beim reload 58_DaikinCloud.pm erhalte ich folgende Antwort:
Excessively long <> operator at .//FHEM/58_DaikinCloud.pm line 27.
Ist das so beabsichtigt?

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

FrankL

Ich schau heute Abend nochmal genau drüber, aber so ein Fehler klingt nicht normal und kam bei mir auch nicht.

Wie und wo hast du denn die 58_DaikinCloud.pm runtergeladen (hier im Forum oder Github)? Oder hast du mit copy und paste selbst die Datei erstellt oder editiert?

Da in Zeile 27 nur die Anweisung "use strict;" steht, kann ich deine Fehlermeldung auch nicht wirklich einordnen.

MfG Frank

FrankL

Hallo Gisbert,

ich hab nochmal das Modul gecheckt. Da ist alles in Ordnung. Beim Reload der "58_DaikinCloud.pm" dürften nur die Perl Warnings im Log kommen, dass diverse Subroutinen redefined worden sind. Das wäre so auch vollkommen richtig.

Ich glaube aber zu wissen, wo bei dir der Fehler liegt. Du hast bestimmt im Github versucht, die Datei "58_DaikinCloud.pm" mit Rechtsklick und "Ziel speichern unter ..." runterzuladen, oder? Das funktioniert im Github so nicht. Wahrscheinlich ist deine runtergeladene Datei auch über 800 kB groß und enthält nur html-Zeug.

Daher zur Lösung folgende Varianten:

a) Hier aus dem Forum die "58_DaikinCloud.pm" mit Rechtsklick und "Ziel speichern unter ..." lokal speichern und nach FHEM kopieren.

oder

b) Im Github unter https://github.com/frank-lie/DaikinCloud den grünen Button "Code" anklicken und Download Zip auswählen. Die darin enthaltene "58_DaikinCloud.pm" entpacken und nach FHEM kopieren.

oder

c) Wenn bei dir FHEM auf Linux läuft, kannst du dort in der Shell auch einfach die Datei direkt ins FHEM Verzeichnis runterladen lassen (Option -P <Verzeichnis deiner FHEM-Installation> ggf. anpassen):
sudo wget https://raw.githubusercontent.com/frank-lie/DaikinCloud/main/58_DaikinCloud.pm -O 58_DaikinCloud.pm -P /opt/fhem/FHEM

Egal für welche Variante du dich entscheidest. Danach das
reload 58_DaikinCloud.pm
nicht vergessen.

Sag Bescheid, ob jetzt alles geklappt hat.

MfG Frank