Soeben hat Mitsubishi das Zertifikatsproblem behoben und der Adapter läuft wieder ohne Fehlermeldungen.

Nichtsdestotrotz baue ich in den Adaptereinstellungen als Workaround für künftige Zertifikatsfehler die Möglichkeit ein, das Ignorieren von SSL-Fehlern zu aktivieren:

Im Log erscheint beim Start des Adapters dann ein zusätzlicher Eintrag "SSL errors are ignored when communicating with the cloud. This is potentially insecure!". Damit können dann solche Probleme zukünftig adapterseitig vom Anwender selbst vorübergehend umgangen werden, auch wenn es dieses Mal sehr schnell behoben wurde.

Hallo zusammen,

da ja schon seit Längerem der Wunsch bestand, einen Adapter zur Integration/Steuerung von Mitsubishi Klimaanlagen zu haben und ich seit kurzem Besitzer einer solchen Anlage bin, habe ich mich mal an die Entwicklung eines Adapters gesetzt. Zwischenzeitlich hat sich ein relativ stabiler Stand ergeben und im dortigen GitHub-Issue eine recht umfangreiche Diskussion entwickelt, so dass es jetzt sinnvoller ist, hier im Forum weiter zu machen.

Daher an dieser Stelle der Aufruf an weitere Tester, die die entsprechende Hardware haben, den Adapter bei sich auszuprobieren und hier Feedback zu geben, was klappt bzw. wo es noch hakt.
Der Adapter ist zwischenzeitlich im latest ioBroker-Repository, d.h. eine Installation von GitHub ist nur nach Aufforderung nötig.

Die aktuelle Dokumentation findet ihr unter folgenden Links:

• Deutsche Beschreibung
• English Description

Das Changelog ist immer an dieser Stelle zu finden.

Installation (aus Latest, Beta)

• 'Aktiver Verwahrungsort' in den iobroker.admin-Einstellungen muss auf 'Beta (latest)' stehen
• Unter 'Adapter' nach 'melcloud' filtern und ganz rechts auf das '+'-Symbol ('Instanz hinzufügen') klicken.
• Unter 'Instanzen' die entsprechenden Adapter-Einstellungen eintragen.

Installation (via Github, Alpha)
Bitte von hier nur nach Aufforderung installieren, da dies u.U. ein instabiler Entwicklungsstand sein kann!

• Unter 'Adapter' auf das GitHub-Icon ('Installieren aus eigener URL') klicken.
• 'Beliebig' auswählen, die URL 'https://github.com/Black-Thunder/ioBroker.melcloud' einfügen und auf 'Installieren' klicken.
• Dann unter 'Adapter' den melcloud-Adapter filtern und ganz rechts auf das '+'-Symbol ('Instanz hinzufügen') klicken.
• Unter 'Instanzen' die entsprechenden Adapter-Einstellungen eintragen.

Viele Grüße
Dominik

Eine kleine Info an alle Nutzer des melcloud-Adapters: Seit gestern hat Mitsubishi anscheinend die Daumenschrauben etwas angezogen und den Zugriff auf die MELCloud limitiert. Mit meinem bisherigen Intervall von einer Minute laufe ich schnell in die Begrenzung (zu sehen im Log als "AxiosError: Request failed with status code 429"). Danach ist auch der Webzugriff via https://app.melcloud.com/ temporär blockiert. Im Moment bleibt daher nur als Lösung den Adapter zu stoppen, die Sperre auszusitzen und danach das Intervall im Adapter höher zu stellen. Auch Home-Assistant (Issue auf GitHub) und andere Projekte sind betroffen.

Es bleibt also abzuwarten, ob sich dazu noch weitere Erkenntnisse ergeben bzw. die Einschränkung aufgehoben oder zumindest näher spezifiziert wird.

Ich habe gerade ein paar Änderungen auf GitHub hochgeladen, um das Anfrageverhalten an die MELCloud-Server hoffentlich zu optimieren bzw. an die offizielle App anzugleichen. Damit läuft es momentan bei mir wieder mit einem Abfrageintervall von einer Minute. Auch mehrfaches Neustarten hat bisher keine Limitierung ausgelöst.

Wer mag, kann sich gerne mal den aktuellen Stand von GitHub installieren und Rückmeldung geben, ob die Limitierung damit wieder auftritt oder nicht.

EDIT: Also mit 1min Intervall wurde ich dann doch ziemlich schnell wieder geblockt. Teste jetzt 5min, das soll bei Home Assistant auch funktionieren.

@oxident Hab ich schon so in der Art eingebaut. Ich vermute aber eher, dass es ein Kontingent pro Stunde/Tag/was auch immer gibt, das bei zu schnellen Abfragen einfach aufgebracht wird.

Ist jetzt auch als v1.3.7 zusammen mit den Änderungen am Login-Prozess im latest veröffentlicht (bzw. sollte bald dort ankommen).
Mit 5min Intervall läuft es so bei mir seit ca. 24h ohne Sperre durch.

Als weitere denkbare Möglichkeit möchte ich noch Klimaanlagen von Mitsubishi in den Raum werfen, die mittels entsprechendem WiFi-Modul per MELCloud steuerbar sind. Zufälligerweise habe ich erst vor Kurzem dafür einen passenden Adapter für ioBroker entwickelt.

@meicker
Im Moment ist es so, dass jede Änderung eines States einen Sendevorgang mit dem geänderten Wert auslöst. Eventuell macht es Sinn, hier eine kurze Warteschleife einzubauen und Änderungen gesammelt zu senden.
Bisher bin ich noch nicht dazu gekommen, mir das anzuschauen. Steht aber auf der Agenda.

Also im Moment ist es so, dass für jede Änderung eine Anfrage abgesendet wird. Anscheinend kommt es da dann bei mehreren Änderungen gleichzeitig (z.B. via Skripte oder Szenen) zu Konflikten, die dann dazu führen können, dass die Änderungen wieder überschrieben werden.
Ich versuch mal da eine Art Sammelpool einzubauen und meld mich wieder, wenn's was neues zum Testen gibt.

@meicker
Ich berechne und setze auch die Solltemperatur mittels Javascript und konnte da bisher keine Probleme feststellen. Allerdings runde ich immer auf 0.5 genau, da ich nicht weiß, ob andere "krumme" Werte auch akzeptiert werden. Ich orientier mich da immer an den offiziellen Einstellmöglichkeiten (dort gibt's nur 0.5-Schritte).
Die Frage, ob "." oder "," stellt sich eigentlich nicht, da der state den Typ "number" hat und keine Zeichenkette erwartet.

Wie sieht denn dein Skript für die Berechnung der Temperatur aus?

@oxident Ja, das ist bei mir auch seit mind. 2 Tagen so. Da scheint es ein Problem bei der Melcloud zu geben. Hilft wohl nur warten, ob sie das wieder hinkriegen

Ich habe gerade den Versionssprung gewagt, von daher auch von mir ein kurzes Feedback. Bisher läuft alles problemlos (Coordinator SMLIGHT SLZB-06M mit knapp 70 verbundenen Zigbee-Geräten). Ein paar wenige States haben sich wie beschrieben geändert, die zugehörigen Aliase waren aber fix angepasst. Ansonsten laufen alle Zigbee-Geräte wie auch zuvor schon butterweich und reagieren zügig auf Befehle.

Danke für die tolle Arbeit und Pflege des Adapters!

@uncleb Also grundsätzlich sollte der Adapter ohne Probleme laufen, ich verwende den hier auch seit Jahren zuverlässig zur Steuerung meiner Yeelights.
Die Einträge im Log deuten stark darauf hin, dass es sich wie von @mcm1957 vermutet um Netzwerkprobleme handelt. Kannst du denn die betroffenen Lichter in der offiziellen Yeelight-App steuern? Stimmen die IP-Adressen im Yeelight-Adapter mit denen aus der App überein? "LAN-Steuerung" ist für die betroffenen Lichter auch weiterhin aktiv? Firmware-Updates vor Kurzem bei den Lichtern durchgeführt?

Ansonsten gerne mal ein Debug-Log hier posten, evtl. sieht man da noch eine genauere Ursache.

@darkblu Zu VIS bzw. dem speziellen Widget kann ich dir nichts sagen. Allerdings musst du als Wert nicht "DRY(2)", sondern nur "2" übergeben. Daher vermutlich auch die Fehlermeldung im Log.

@ralf_62 Hallo Ralf, ist diese Funktion denn auch mittels App/Cloud explizit zuschaltbar? Falls nicht, kann ich das mit dem Adapter auch nicht ermöglichen, da nur die Funktionen der Cloud nachgeahmt werden.
VG Dominik

Soeben hat Mitsubishi das Zertifikatsproblem behoben und der Adapter läuft wieder ohne Fehlermeldungen.

Nichtsdestotrotz baue ich in den Adaptereinstellungen als Workaround für künftige Zertifikatsfehler die Möglichkeit ein, das Ignorieren von SSL-Fehlern zu aktivieren:

Im Log erscheint beim Start des Adapters dann ein zusätzlicher Eintrag "SSL errors are ignored when communicating with the cloud. This is potentially insecure!". Damit können dann solche Probleme zukünftig adapterseitig vom Anwender selbst vorübergehend umgangen werden, auch wenn es dieses Mal sehr schnell behoben wurde.

Nur als kleine Info an alle: Mitsubishi hat gerade wieder mal an den Zertifikaten geschraubt und dabei wie schon Mitte letzten Jahres eine Fehlkonfiguration bzw. unvollständige Zertifikatskette zustande gebracht:

Daher läuft auch der Adapter auf den bekannten Fehler "Error: unable to verify the first certificate". Hier hilft leider nur wieder Aussitzen, bis Mitsubishi das wieder korrigiert.

@oxident @green @NCIceWolf und alle anderen Betroffenen

Nur eine kleine Info an alle, die in ihrem Netzwerk einen eigenen DNS-Server (z.B. Pi-hole) betreiben oder der Router lokale DNS-Einträge zulässt: Wenn ihr die URL "production.receiver.melcloud.com" auf die IP "52.215.226.151" auflösen lasst, dann funktioniert sowohl der Zugriff über MelCloud als auch über meinen Adapter wieder. Sieht in Pi-hole dann so aus (Local DNS -> DNS Records):

Damit läuft es bei mir zumindest für den Moment wieder problemlos.

Immerhin gibt's jetzt ne Info beim Anmelden:

@oxident said in Test Adapter melcloud v1.4.x Latest:

Irgendwie erschreckend, dass es dann doch so lange dauert, bis etwas unternommen wird. Das zeigt mal wieder erschreckend, wie schlimm solche cloud-only Lösungen sind.

Am traurigsten ist, dass es immer noch keine einheitliche flächendeckende Kommunikation über einen Ausfall und dessen voraussichtliche Dauer gibt.

Wieso spendiert man dem Wifi-Modul nicht irgendeine Art von API?

Anscheinend gibt's da potentiell schon Möglichkeiten, bisher scheitert es aber an fehlenden Zugangsdaten für das Modul und der verschlüsselten Kommunikation. Hier gibt's ein paar mehr Infos dazu, aber leider keine Lösung: klick

Kennt jemand eine gute "out of the box"-Alternative zum Nachrüsten?

Was fertiges/plug&play hab ich da leider auch noch nicht gefunden. Nur das übliche Spielchen mit Wemos D1, CN105-Adapter und mitsubishi2MQTT.

@oxident Ja, hier ebenso. Seit ca. 18:30 Uhr sind alle Geräte offline und auch die App kann seitdem keine Befehle mehr erfolgreich rausschicken. Da hilft wohl nur warten, bis Mitsubishi das wieder zum Laufen bringt.