Klimaanlage über Panasonic Comfort Cloud

Begonnen von Guybrush, 05 Juli 2022, 14:02:26

Vorheriges Thema - Nächstes Thema

Guybrush

Es gibt hier bereits einige Themen bzgl. einer Einbindung von Panasonic Klimaanlagen in FHEM. Die Lösungsansätze hier waren eine Einbindung mittels HTTPMOD. Ich habe mir jetzt mal die Zeit genommen hierfür ein Modul zu schreiben, was das ganze deutlich einfacher macht. Es ist auch stabiler, da die API teilweise echt merkwürdige Verhaltensweisen hat. Ich habe das Modul jetzt schon seit ein paar Tagen im Einsatz und es läuft gut. Dennoch ist es noch eher in einem frühen Stadium, so dass ich für feedback und Fehlermeldungen dankbar wäre.

Um die Panasonic Comfort Cloud nutzen zu können, benötigt man Klimageräte mit einem Wlan Modul, was in allen neuen werkseitig bereits integriert ist. Bei nicht allzu alten Klimageräten lässt sich das übrigens einfach nachrüsten (CT-CNT Port muss vorhanden sein). Hierfür gibt es das Nachrüstset CZ-TACG1 für 70-80 €. Im folgenden wird davon ausgegangen, dass die Klimageräte über die Panasonic Comfort Cloud App bereits angelegt und konfiguriert wurden.

1. Module installieren
Die Dateien 50_PanasonicAC.pm und 51_PanasonicACDevice.pm in das Verzeichnis FHEM kopieren.

2. PanasonicAC definieren
Nun legen wir in FHEM das Device an und hinterlegen die Zugangsdaten zur Panasonic Comfort Cloud:
define PAC PanasonicAC
attr PAC loginID <E-mail>
set PAC password <Passwort>

Das Passwort wird nicht als Reading, sondern verschlüsselt im KeyValue Store gespeichert.

3. Fertig
Das Modul legt nun per AutoCreate alle gefundenen Klimageräte im Room PanasonicAC an und benennt diese so wie sie in der Panasonic Comfort Cloud konfiguriert sind. Die Klimageräte müssen vorher natürlich über die Panasonic Comfort Cloud App angelegt worden sein! Der Rest sollte selbsterklärend sein. Ich habe für die set Befehle eine CommandRef zusammengestellt, da die Values der Readings sich einem sonst nicht ohne weiteres erschließen. 

Das Modul polled im angegebenen Interval die API. Anders ist das scheinbar nicht möglich. Hierbei sollte unbedingt der Mindestwert für den Interval bei 1 Minute belassen werden, da bei zu viel Requests der Zugang andernfalls temporär geblockt würde. Leider gibt es keine API Description, so dass ich alles nur im Try & Error Verfahren ermitteln konnte. Falls jemand eine finden sollte, immer her damit.

Falls etwas nicht funktionieren sollte, habe ich für die Loglevel 4 und 5 ein grundlegendes Logging integriert.

marboj

Super, ich werde es direkt mal testen 8)

Dankeschön
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

teufelchen

Vielen Dank für das Modul.

Eingerichtet, alle 4 Analgen wurden erkannt und können aus FHEM geschaltet werden.
Raspberry Pi 3
CUL433: V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
Debmatic mit RPI-RF-MOD

marboj

Hallo Guybrush,

sehe ich es richtig, dass sich die Readings nur aktualisieren, wenn die Klimaanlage eingeschaltet wird? Ich nutze die gemessene Innentemperatur auch für andere Zwecke.

Kann man die Readings auch bei ausgeschalteter Anlage aktualisieren? Vielleicht in einem größeren Intervall wie in Betrieb?

Gruß
Marco
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

Guybrush

Die Readings werden unabhängig vom Zustand der Anlage aktualisiert. Dass die Innentemperatur nicht aktualisiert wird hat eine andere Ursache. Die API liefert im GroupRead leider sowohl die Innentemperatur als auch die Aussentemperatur von der Outdoorunit nicht mit. Diese Werte bekommt man nur, wenn man einen Request je Gerät macht. Das habe ich aber bewusst so umgesetzt, da man sonst n+1 Requests hätte, was schnell zu einem Block / Error 403 führen kann. Daher wird das aktuell nur dann aktualisiert, wenn man ein Reading schreibt, da ich hier im Anschluss die Werte des Gerätes abfrage um die Readings unmittelbar  aktualisieren zu können. In dem Zusammenhang werden dann auch die Temperaturwerte übermittelt und als Reading geschrieben. Kurz: nur wenn du per set ein Reading aktualisierst, werden die Temperaturen aktualisiert.

Ich bin zur Zeit am überlegen, ob ich unabhängig vom GroupRead zusätzlich noch in einem größeren (!) Interval die Daten je Device abfrage, damit man auch die Temperaturwerte regelmäßig bekommt. Hier sollten 5 Minuten Intervalle genügen, da sich die Temperatur ja eher träge entwickelt?

Funktioniert denn sonst alles? Ich entnehme deinem Post zumindest, dass der Rest soweit funktioniert?

marboj

5 Minuten Intervall reicht locker, auch 15 Minuten.

Ansonsten läuft bisher alles, was ich ausprobiert habe!!!
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

marboj

Hallo zusammen,

habe die Ansicht der Devices ein wenig "angepasst". Falls Interesse besteht:

attr PanasonicAC.Zimmer devStateIcon on:gefrierschrank@orange off:gefrierschrank
attr PanasonicAC.Zimmer icon icoKLIMA
attr PanasonicAC.Zimmer webCmd on:off:temperatureSet
attr PanasonicAC.Zimmer widgetOverride temperatureSet:slider,16.0,0.5,30.0,1


PanasonicAC.Zimmer muss durch eure Device-Namen ersetzt werden ;-)

Gruß
Marco
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

Guybrush

Ich habe gerade eine neue Version hochgeladen.

Änderungen:


  • temperatureSet umbenannt in desired-temp
    Beta-User war so nett mir ein paar Feedbacks zu geben. Ich habe daher das bisherige Reading "temperatureSet" in "desired-temp" umbenannt

  • Temperaturen
    Man kann jetzt in einem PanasonicACDevice Device das Attribut "intervalDetails" (mind. 300s) setzen, um die Temperaturwerte Innen + Aussen als Reading zu erhalten. Das sollte natürlich nur für die Devices gesetzt werden, in denen man das wirklich braucht, da jedes mal ein API Request erfolgen muss und die Panasonic Comfort Cloud API einen User (temporär) blockt, wenn zuviele Requests innerhalb einer bestimmten Zeit erfolgen. Um dem vorzubeugen habe ich hier aber auch ein minimales Delay von 15s zwischen jedem Request definiert. Möchte man z.b. nur die Aussentemperatur haben, genügt es diese nur bei einem Device zu setzen.

  • Switch Paket
    wird nicht mehr benötigt

  • devStateIcon
    die Funktion PanasonicACDevice_devStateIcon($name) liefert nun ein abhängig von Betriebsmodus passendes devStateIcon zurück. Dies wird beim neu anlegen automatisch gesetzt. Wenn es nachträglich genutzt werden soll:

    attr <name> devStateIcon {PanasonicACDevice_devStateIcon($name)}


Die Innentemperaturen der Klimageräte nutze ich selbst nicht mehr. Ich hab das Ganze nun über meine KNX Taster gelöst, die Temperaturen bereits messen. desired-temp wird dementsprechend per notify bei mir nun immer den SOLL Werten vom KNX Taster angepasst.

Guybrush

Ich habe soeben eine neue Version hinterlegt, da Panasonic die API verändert hatte, wodurch das Modul nicht mehr funktionierte.  In dem Zuge habe ich auch weitere Anpassungsmöglichkeiten integriert.

  • Attribut version
    Man kann jetzt über das Attribut "version" im PanasonicAC Device selbst die Versionsnummer modifizieren. Die API meldete nämlich direkt ein 403 (blocked) bei dem hier zuvor verwendeten Header X-APP-VERSION: 1.20.0. Die Version kann man daher nun selbst anpassen, falls es wieder zu einer Änderung kommen sollte
  • Attribut delayAfterWrite
    Nachdem per set Werte verändert wurden, werden diese an die API übertragen. Bislang wurde der Read zum aktualisieren des Status hard coded 2 Sekunden nach Rückmeldung des Writes durchgeführt. Das hat aber nicht immer funktioniert. Daher ist der Wert nun anpassbar (default bleibt 2s).

EinEinfach

ZitatAttribut version
Man kann jetzt über das Attribut "version" im PanasonicAC Device selbst die Versionsnummer modifizieren. Die API meldete nämlich direkt ein 403 (blocked) bei dem hier zuvor verwendeten Header X-APP-VERSION: 1.20.0. Die Version kann man daher nun selbst anpassen, falls es wieder zu einer Änderung kommen sollte

Kann das Modul nicht automatisch erledigen. Das Problem gibt es ja immer wieder bei der Verbindung mit HTTPMOD.

Gruß
Alexander
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

Guybrush

Das geht leider nicht. Die API überprüft beim Login, ob die Version exakt übereinstimmt. Wenn die nicht stimmt, gibt es mittlerweile direkt einen 403 forbidden. Derzeit ist 1.15.0 aktuell.

Ich habe die Version auch soeben nochmal aktualisiert, da Panasonic da wieder an der API was geändert hat, wodurch der Login trotz richtiger Version nicht mehr ging. Ist leider etwas unbefriedigend, dass im Jahr 2022 ein so namhafter Hersteller wie Panasonic Smarthome Besitzer völlig ignoriert und stattdessen alleine eine APP anbietet die alles andere als komfortabel zu nutzen ist (meine Meinung).

Zumindest ist das hier jetzt die einzig funktionierende Implementation. Lösungen für FHEM Pendants funktionieren derzeit alle nicht, soweit ich das sehe.

marboj

Zitat von: Guybrush am 13 Juli 2022, 21:49:31
Ich habe soeben eine neue Version hinterlegt, da Panasonic die API verändert hatte, wodurch das Modul nicht mehr funktionierte.  In dem Zuge habe ich auch weitere Anpassungsmöglichkeiten integriert.

  • Attribut version
    Man kann jetzt über das Attribut "version" im PanasonicAC Device selbst die Versionsnummer modifizieren. Die API meldete nämlich direkt ein 403 (blocked) bei dem hier zuvor verwendeten Header X-APP-VERSION: 1.20.0. Die Version kann man daher nun selbst anpassen, falls es wieder zu einer Änderung kommen sollte
  • Attribut delayAfterWrite
    Nachdem per set Werte verändert wurden, werden diese an die API übertragen. Bislang wurde der Read zum aktualisieren des Status hard coded 2 Sekunden nach Rückmeldung des Writes durchgeführt. Das hat aber nicht immer funktioniert. Daher ist der Wert nun anpassbar (default bleibt 2s).


Woran kann es liegen, dass die Attribute bei mir nicht auftauchen?
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

EinEinfach

ZitatLösungen für FHEM Pendants funktionieren derzeit alle nicht, soweit ich das sehe.

Meine HTTPMOD Lösung geht auch seit heute oder gestern nicht mehr, egal was ich an der X-APP-Version eintrage. Was macht dein Modul anders?
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

Guybrush

Zitat von: marboj am 14 Juli 2022, 18:36:30

Woran kann es liegen, dass die Attribute bei mir nicht auftauchen?

ganz blöd gefragt - hast du ein "reload 50_panasonicac" gemacht oder fhem neu gestartet, nachdem du die dateien aktualisiert hast?

Guybrush

Zitat von: EinEinfach am 14 Juli 2022, 21:12:28
Meine HTTPMOD Lösung geht auch seit heute oder gestern nicht mehr, egal was ich an der X-APP-Version eintrage. Was macht dein Modul anders?

Panasonic scheint aktiv daran zu arbeiten, dass nur noch die App selbst auf die Schnittstelle zugreifen können soll und alle anderen ausgesperrt werden. Wenn das so weiter geht, wirst du  das mit HTTPMOD demnächst nicht mehr umsetzen können. Wenn du mal den HTTPS Stream sniffst, dann wirst du schnell feststellen, dass da viel mehr passiert als nur der Login selbst. Hier mal ein Auszug von dem, was nur beim Login zwischen der App und der API passiert:

HTTPS POST       accsmart.panasonic.com /auth/login                                                                                                      200  application/json  130b 1.39s
HTTPS GET        accsmart.panasonic.com /auth/agreement/status/1                                                                                 200  application/json   21b 775ms
HTTPS GET        accsmart.panasonic.com /auth/agreement/status/2                                                                                 200  application/json   21b 1.47s
HTTPS GET        accsmart.panasonic.com /auth/agreement/status/3                                                                                 200  application/json   21b 547ms
HTTPS POST       accsmart.panasonic.com /auth/token/deviceToken                                                                                  200  application/json   12b 2.03s
HTTPS GET        accsmart.panasonic.com /device/group                                                                                                   200  application/json 4.98k 1.03s
HTTPS GET        accsmart.panasonic.com /message                                                                                                         200  application/json   49b 491ms

Vor der API ist eine Firewall geschaltet, welche die Header prüft. Versuch mal UTF-8 encodings in accept-language und content-type aufzunehmen. Das ist aber nicht bei allen Abfragen gesetzt. Das war/ist schon etwas Mehraufwand das buggy Verhalten der App 1:1 zu emulieren, damit der Login funktioniert ;D