NEWS
Test Adapter melcloud v3.0.x Latest
-
@black-thunder ich setze derzeit volle Integer als Wert, also 21.
setState('melcloud.0.devices.101371856.control.targetTemp',getState('0_userdata.0.uFactory.KlimaTempTargetUp').val,false);Das sieht dann auch okay aus, wenn ich in die Objekte schaue. Das Log von dem melcloud Adapter ist immer recht schnell wieder weg, obwohl es auf debug steht.
Was ich aber eben gesehen habe ist, dass er z.B. den Wert auf 25 setzt und dann kommt ein Update von der Cloud und setzt den Wert auf 23 und dann kommt das ganze leicht aus dem Tritt, weil mit einiger Verzögerung dann doch der Wert aus der Cloud kommt und dann wieder auf 25 setzt, weil der Befehl durchgegangen ist.
Das kann sich dann also wild überlagern, wenn ich zu oft abhole oder zu schnell sende.
Wenn ich die Abholung deaktiviere .. wird dann nie abgeholt und immer nur gesendet?
@mchott said in Test Adapter melcloud v1.4.x Latest:
@black-thunder ich setze derzeit volle Integer als Wert, also 21.
setState('melcloud.0.devices.101371856.control.targetTemp',getState('0_userdata.0.uFactory.KlimaTempTargetUp').val,false);Das sieht dann auch okay aus, wenn ich in die Objekte schaue. Das Log von dem melcloud Adapter ist immer recht schnell wieder weg, obwohl es auf debug steht.
Das Log kannst du immer auch im Nachhinein auslesen. Z.B. direkt im Admin -> Protokolle -> Log herunterladen
Wenn ich die Abholung deaktiviere .. wird dann nie abgeholt und immer nur gesendet?
Es wird dann nicht regelmäßig nach aktualisierten Daten gefragt. Allerdings wird unabhängig davon nach jedem Sendevorgang die Rückmeldung aus der Cloud abgeglichen und ggf. die Werte aktualisiert.
@mchott said in Test Adapter melcloud v1.4.x Latest:
@mchott gibt es ein "forceSend"? Wenn ich jetzt nicht mehr abholen würde, dann würde er ja erst etwas senden, wenn es sich nach seiner Erinnerung geändert hat, was ja auch nicht richtig ist. Er sendet ja nichts, wie ich es sehe, wenn sich der Wert nicht geändert hat.
Ah ja, das könnte natürlich das Problem sein. Im Moment ist es so, dass nur ein Sendevorgang ausgelöst wird, wenn sich der lokale Wert in ioBroker geändert hat. Das führt natürlich jetzt zu dem Problem, dass man nicht mehr denselben Wert senden kann, obwohl in der Zwischenzeit dieser Wert potentiell längst veraltet ist.
Sprich bei "melcloud.0.devices.101371856.control.targetTemp" steht z.B. 21, in der Cloud/Realität hat sich der Wert aber (extern ausgelöst, z.B. durch Fernbedienung) geändert und du möchtest nun wieder 21 per ioBroker senden? Dann hast du Recht, das funktioniert im Moment so nicht. Könnte ich aber ändern, wenn gewünscht.
-
@mchott said in Test Adapter melcloud v1.4.x Latest:
@black-thunder ich setze derzeit volle Integer als Wert, also 21.
setState('melcloud.0.devices.101371856.control.targetTemp',getState('0_userdata.0.uFactory.KlimaTempTargetUp').val,false);Das sieht dann auch okay aus, wenn ich in die Objekte schaue. Das Log von dem melcloud Adapter ist immer recht schnell wieder weg, obwohl es auf debug steht.
Das Log kannst du immer auch im Nachhinein auslesen. Z.B. direkt im Admin -> Protokolle -> Log herunterladen
Wenn ich die Abholung deaktiviere .. wird dann nie abgeholt und immer nur gesendet?
Es wird dann nicht regelmäßig nach aktualisierten Daten gefragt. Allerdings wird unabhängig davon nach jedem Sendevorgang die Rückmeldung aus der Cloud abgeglichen und ggf. die Werte aktualisiert.
@mchott said in Test Adapter melcloud v1.4.x Latest:
@mchott gibt es ein "forceSend"? Wenn ich jetzt nicht mehr abholen würde, dann würde er ja erst etwas senden, wenn es sich nach seiner Erinnerung geändert hat, was ja auch nicht richtig ist. Er sendet ja nichts, wie ich es sehe, wenn sich der Wert nicht geändert hat.
Ah ja, das könnte natürlich das Problem sein. Im Moment ist es so, dass nur ein Sendevorgang ausgelöst wird, wenn sich der lokale Wert in ioBroker geändert hat. Das führt natürlich jetzt zu dem Problem, dass man nicht mehr denselben Wert senden kann, obwohl in der Zwischenzeit dieser Wert potentiell längst veraltet ist.
Sprich bei "melcloud.0.devices.101371856.control.targetTemp" steht z.B. 21, in der Cloud/Realität hat sich der Wert aber (extern ausgelöst, z.B. durch Fernbedienung) geändert und du möchtest nun wieder 21 per ioBroker senden? Dann hast du Recht, das funktioniert im Moment so nicht. Könnte ich aber ändern, wenn gewünscht.
@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?
Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker
Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.
Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.
Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.
Option D Du hast eine sehr viel bessere Idee.
-
@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?
Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker
Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.
Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.
Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.
Option D Du hast eine sehr viel bessere Idee.
@mchott said in Test Adapter melcloud v1.4.x Latest:
@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?
Nein, es wird immer nur pro Request der geänderte Wert gesendet.
Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker
Da sollte es keine Missverständnisse geben, da das Senden in Echtzeit passiert. So kann ein Konflikt mit den Werten aus der Cloud eigentlich nicht vorkommen, da der Wert dann dort mit dem gesendeten Wert überschrieben wird.
Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.
Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.
Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.
Option D Du hast eine sehr viel bessere Idee.
Bitte beschreib nochmal genau deinen Use-Case bzw. wie das Problem genau auftritt. Also welche Werte du wann sendest und wann es zu Diskrepanzen kommt. Am besten mit Debug-Log dazu.
So ganz kann ich das noch nicht nachvollziehen. :wink: -
@black-thunder
Danke. Der Adapter ist lokal erreichbar im Netzwerk und ich kann auch keinen Verlust der Internetverbindung feststellen. IP-Adresse und Gateway bleiben konstant. Der Router ist nur 5m Luftlinie entfernt. Was mich wundert ist, dass es gut ein halbes Jahr ohne Probleme lief und erst mit dem Update des Melcloud Adapters in Iobroker fällt es immer zu festen Zeiten aus. Es ist als würde der Adapter beim Sendeprozess von irgendwas blockiert.@galdreth
Ich hatte ein ähnliches Problem mit dem melcloud Adapter und der Fritzbox.
Bei mir lag es an der Fritzbox. Dort hatte ich sehr vielen Geräten eine feste IP Adresse gegeben weil ich in der Vergangenheit Probleme mit dem internen DHCP Server der Fritzbox hatte.
Ich habe zum Test bei allen Geräten "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen" ausgeschaltet und siehe da, keine Verbindungsprobleme mehr mit dem melcloud Adapter. -
@mchott said in Test Adapter melcloud v1.4.x Latest:
@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?
Nein, es wird immer nur pro Request der geänderte Wert gesendet.
Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker
Da sollte es keine Missverständnisse geben, da das Senden in Echtzeit passiert. So kann ein Konflikt mit den Werten aus der Cloud eigentlich nicht vorkommen, da der Wert dann dort mit dem gesendeten Wert überschrieben wird.
Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.
Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.
Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.
Option D Du hast eine sehr viel bessere Idee.
Bitte beschreib nochmal genau deinen Use-Case bzw. wie das Problem genau auftritt. Also welche Werte du wann sendest und wann es zu Diskrepanzen kommt. Am besten mit Debug-Log dazu.
So ganz kann ich das noch nicht nachvollziehen. :wink:@black-thunder hallo .. entschuldige die Wartezeit .. die hatte familiäre Gründe
Also .. derzeit habe ich die Abholung von der melcloud quasi deaktiviert (nur noch alle 12h) und es scheint sehr viel zuverlässiger zu funktionieren .. eventuell war es ein Timingproblem, also die Daten von der melcloud und meine Steuerung sind sich eventuell irgendwie in die Quere gekommen.
Ich habe am Code nichts geändert, sondern lediglich die Häufigkeit meiner Steuerung etwas gedrosselt, was ja auch Sinn macht bei der Trägheit des Systems und die Daten hole ich nur noch alle 12h ab, weil die Steuerung ja funktioniert muss ich jetzt eh nicht mehr ans Bedienpanel.
-
@mchott said in Test Adapter melcloud v1.4.x Latest:
@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?
Nein, es wird immer nur pro Request der geänderte Wert gesendet.
Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker
Da sollte es keine Missverständnisse geben, da das Senden in Echtzeit passiert. So kann ein Konflikt mit den Werten aus der Cloud eigentlich nicht vorkommen, da der Wert dann dort mit dem gesendeten Wert überschrieben wird.
Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.
Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.
Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.
Option D Du hast eine sehr viel bessere Idee.
Bitte beschreib nochmal genau deinen Use-Case bzw. wie das Problem genau auftritt. Also welche Werte du wann sendest und wann es zu Diskrepanzen kommt. Am besten mit Debug-Log dazu.
So ganz kann ich das noch nicht nachvollziehen. :wink:@black-thunder vielen Dank für Deinen Support
-
@black-thunder vielen Dank für Deinen Support
-
Hallo, habe gerade auf 1.4.0 geupdatet.
Zusammenfassend kann man sagen:
Änderungen über ioBroker (an/aus, Temperaturänderungen)
kommen sofort in der Melcloud App an und gehen auch direkt zur Klimaanlage.
Änderungen per Melcloud App / Fernbedienung gehen sofort zur Klimaanlage, kommen im ioBroker aber erst je nach eingestelltem Abfrageintervall an (bzw. wann eben wieder abgefragt wird).Demnach kann eine Bedienung über die Melcloud App / Fernbedienung zu Verwirrungen im ioBroker (Vis) führen.
Stimmt doch soweit, oder ?
-
Hallo, habe gerade auf 1.4.0 geupdatet.
Zusammenfassend kann man sagen:
Änderungen über ioBroker (an/aus, Temperaturänderungen)
kommen sofort in der Melcloud App an und gehen auch direkt zur Klimaanlage.
Änderungen per Melcloud App / Fernbedienung gehen sofort zur Klimaanlage, kommen im ioBroker aber erst je nach eingestelltem Abfrageintervall an (bzw. wann eben wieder abgefragt wird).Demnach kann eine Bedienung über die Melcloud App / Fernbedienung zu Verwirrungen im ioBroker (Vis) führen.
Stimmt doch soweit, oder ?
@darkblu Das ist korrekt, war aber schon immer so und lässt sich auch nicht verhindern.
Die Cloud schickt keine Pushnachrichten bei Änderungen, sondern der Adapter fragt regelmäßig die Daten ab (außer man deaktiviert das seit v1.4.0, dann bekommt man externe Änderungen gar nicht mit und es kommt evtl. zu Konflikten). -
@Black-Thunder kann es sein, dass sich Adresse der Außentemperatur geändert hat oder diese vom aktuellen Adapter nicht mehr erfasst wird? Laut den Objekten ist die Temperatur das letzte Mal am 26.3.2024 im iobroker geändert worden. Das war auch der Zeitraum, im dem ich auf die Version 1.4.0 gewechselt habe.
Danke schon mal für Deine Hilfe -
@Black-Thunder kann es sein, dass sich Adresse der Außentemperatur geändert hat oder diese vom aktuellen Adapter nicht mehr erfasst wird? Laut den Objekten ist die Temperatur das letzte Mal am 26.3.2024 im iobroker geändert worden. Das war auch der Zeitraum, im dem ich auf die Version 1.4.0 gewechselt habe.
Danke schon mal für Deine Hilfe -

Aktuelle Test Version 3.0.1 Veröffentlichungsdatum 13.08.2025 Github Link https://github.com/Black-Thunder/ioBroker.melcloud Hallo zusammen,
hier habt ihr die Möglichkeit, euch über alle Themen und Anliegen rund um den Adapter auszutauschen und Unstimmigkeiten zu melden.
Die aktuelle Dokumentation findet ihr unter folgenden Links:
Highlights der einzelnen Versionen:
- Ab v1.1.0 ist es möglich, die Verbrauchsberichte der Inneneinheiten abzurufen (sofern dies vom jeweiligen Gerät unterstützt wird). Informationen zu den einzelnen Datenpunkten dafür sind wie immer in der Doku zu finden (Links unten).
- Seit v1.2.0 werden auch Luft-Wasser-Wärmepumpen unterstützt. Hier gerne Feedback, ob speziell die Steuerung funktioniert, da ich selbst keine Möglichkeit habe, das zu verifizieren. Zusätzlich können seit dieser Version auch aggregierte Berichte über den Energieverbrauch abgerufen werden.
- Seit v1.2.1 sind auch die Verbrauchsberichte für Luft-Wasser-Wärmepumpen implementiert.
- Seit v1.3.0 gibt es die Möglichkeit, vorhandene Timer der Geräte ein- bzw. auszuschalten. Zusätzlich wird nun im Objekt-Baum des Admin-Adapters der jeweilige Zustand (Verbindung und Fehler) des Geräts farblich und mit Tooltips angezeigt.
- Seit v1.4.0 kann das regelmäßige Abrufen der Daten aus der Cloud komplett deaktiviert werden, falls nicht benötigt
- Seit v3.0.0 werden ERV-Geräte/Lüftungsanlagen experimentell unterstützt. Falls hier jemand testen kann und möchte, gerne Feedback geben.
Das ausführliche Changelog ist immer an dieser Stelle zu finden.
Versionshinweise
- Falls der Fehler "Error: unable to verify the first certificate" auftritt, bitte auf Version 1.4.1 oder höher updaten und die Option "SSL-Fehler ignorieren" in den Adaptereinstellungen (temporär) aktivieren.
- Ab v1.1.1 wurde die Ver-/Entschlüsselung des Passworts geändert. Daher muss einmalig das Passwort erneut in den Adapter-Einstellungen eingeben werden. Ansonsten schlägt die Anmeldung fehl und der Adapter bleibt auf rot!
- Ab v1.1.3 muss mindestens js-controller v3.1 installiert sein
- Bei einem Upgrade auf v1.2.0 (oder höher) bitte einmalig die Objektstrukturen unter "melcloud.X.devices.YYYYY.reports" komplett löschen und den Adapter neustarten, damit diese neu angelegt werden können. In der Dokumentation ist die neue Struktur beschrieben.
- Ab v1.3.6 muss mind. Node.Js 16 verwendet werden
- Ab v1.3.7 ist das minimale Abfrageintervall auf 5 Minuten begrenzt.
- Ab v2.0.0 muss mindestens Node.Js 18, Admin 6 und js-controller 5 verwendet werden.
- Ab v3.0.0 muss mindestens Node.Js 20, Admin 7.4.10 und js-controller 6 verwendet werden.
Installationshinweise
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.
Aus Github (Alpha)
Bitte von hier nur nach Aufforderung installieren, da dies u.U. ein instabiler Entwicklungsstand sein kann!- Expertenansicht des Admin-Adapters aktivieren
- Unter 'Adapter' auf das GitHub-Icon ('Installieren aus eigener URL') klicken.
- 'VON GITHUB' auswählen, nach "melcloud [Black-Thunder]" suchen 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@black-thunder ich habe das Problem entdeckt. In der Instanz war keine Abtastzeit eingetragen.
Dazu aber gleich noch eine Frage, ist die Eingabe ein Sekunden- oder Minutenwert? -
@black-thunder ich habe das Problem entdeckt. In der Instanz war keine Abtastzeit eingetragen.
Dazu aber gleich noch eine Frage, ist die Eingabe ein Sekunden- oder Minutenwert? -

Aktuelle Test Version 3.0.1 Veröffentlichungsdatum 13.08.2025 Github Link https://github.com/Black-Thunder/ioBroker.melcloud Hallo zusammen,
hier habt ihr die Möglichkeit, euch über alle Themen und Anliegen rund um den Adapter auszutauschen und Unstimmigkeiten zu melden.
Die aktuelle Dokumentation findet ihr unter folgenden Links:
Highlights der einzelnen Versionen:
- Ab v1.1.0 ist es möglich, die Verbrauchsberichte der Inneneinheiten abzurufen (sofern dies vom jeweiligen Gerät unterstützt wird). Informationen zu den einzelnen Datenpunkten dafür sind wie immer in der Doku zu finden (Links unten).
- Seit v1.2.0 werden auch Luft-Wasser-Wärmepumpen unterstützt. Hier gerne Feedback, ob speziell die Steuerung funktioniert, da ich selbst keine Möglichkeit habe, das zu verifizieren. Zusätzlich können seit dieser Version auch aggregierte Berichte über den Energieverbrauch abgerufen werden.
- Seit v1.2.1 sind auch die Verbrauchsberichte für Luft-Wasser-Wärmepumpen implementiert.
- Seit v1.3.0 gibt es die Möglichkeit, vorhandene Timer der Geräte ein- bzw. auszuschalten. Zusätzlich wird nun im Objekt-Baum des Admin-Adapters der jeweilige Zustand (Verbindung und Fehler) des Geräts farblich und mit Tooltips angezeigt.
- Seit v1.4.0 kann das regelmäßige Abrufen der Daten aus der Cloud komplett deaktiviert werden, falls nicht benötigt
- Seit v3.0.0 werden ERV-Geräte/Lüftungsanlagen experimentell unterstützt. Falls hier jemand testen kann und möchte, gerne Feedback geben.
Das ausführliche Changelog ist immer an dieser Stelle zu finden.
Versionshinweise
- Falls der Fehler "Error: unable to verify the first certificate" auftritt, bitte auf Version 1.4.1 oder höher updaten und die Option "SSL-Fehler ignorieren" in den Adaptereinstellungen (temporär) aktivieren.
- Ab v1.1.1 wurde die Ver-/Entschlüsselung des Passworts geändert. Daher muss einmalig das Passwort erneut in den Adapter-Einstellungen eingeben werden. Ansonsten schlägt die Anmeldung fehl und der Adapter bleibt auf rot!
- Ab v1.1.3 muss mindestens js-controller v3.1 installiert sein
- Bei einem Upgrade auf v1.2.0 (oder höher) bitte einmalig die Objektstrukturen unter "melcloud.X.devices.YYYYY.reports" komplett löschen und den Adapter neustarten, damit diese neu angelegt werden können. In der Dokumentation ist die neue Struktur beschrieben.
- Ab v1.3.6 muss mind. Node.Js 16 verwendet werden
- Ab v1.3.7 ist das minimale Abfrageintervall auf 5 Minuten begrenzt.
- Ab v2.0.0 muss mindestens Node.Js 18, Admin 6 und js-controller 5 verwendet werden.
- Ab v3.0.0 muss mindestens Node.Js 20, Admin 7.4.10 und js-controller 6 verwendet werden.
Installationshinweise
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.
Aus Github (Alpha)
Bitte von hier nur nach Aufforderung installieren, da dies u.U. ein instabiler Entwicklungsstand sein kann!- Expertenansicht des Admin-Adapters aktivieren
- Unter 'Adapter' auf das GitHub-Icon ('Installieren aus eigener URL') klicken.
- 'VON GITHUB' auswählen, nach "melcloud [Black-Thunder]" suchen 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@black-thunder ich danke Dir. Wer lesen kann, ist klar im Vorteil :blush:
-
Habt ihr eigentlich auch seit gestern (18.04.) Stress mit der App bzw. dem Adapter?
Bei mir werden fast alle Geräte als Offline angezeigt.
-
Bei mir ebenfalls.
Ab 19:45 Uhr sehe ich in meinem pihole dass es keine Anfragen mehr an ***.amazonaws.com gibt, sondern nur noch die Anfrage an "production.receiver.melcloud.com".Hier muss also Mitsubishi schauen was da in deren System nicht mehr läuft.
Vielleicht hat da jemand vergessen die AmazonCloud zu verlängern/bezahlen :D -
Bei mir ebenfalls.
Ab 19:45 Uhr sehe ich in meinem pihole dass es keine Anfragen mehr an ***.amazonaws.com gibt, sondern nur noch die Anfrage an "production.receiver.melcloud.com".Hier muss also Mitsubishi schauen was da in deren System nicht mehr läuft.
Vielleicht hat da jemand vergessen die AmazonCloud zu verlängern/bezahlen :D@ncicewolf @Black-Thunder @NCIceWolf
Hallo, uff! Ich habe heute früh schon bemerkt dass beide Klimaanlagen nicht mehr erreichbar sind, heute mittag alle Wifi Adapter resettet und frisch verbunden, Unifi-Settings ausprobiert und im Router alles mögliche versucht, nun merke ich euch geht es genau so.
Kann keinerlei Daten von außen über die App mehr auslesen bzw. befehle senden. Der zuletzt eingestellte Stand von irgendwann gestern abend wird dargestellt.
-
@ncicewolf @Black-Thunder @NCIceWolf
Hallo, uff! Ich habe heute früh schon bemerkt dass beide Klimaanlagen nicht mehr erreichbar sind, heute mittag alle Wifi Adapter resettet und frisch verbunden, Unifi-Settings ausprobiert und im Router alles mögliche versucht, nun merke ich euch geht es genau so.
Kann keinerlei Daten von außen über die App mehr auslesen bzw. befehle senden. Der zuletzt eingestellte Stand von irgendwann gestern abend wird dargestellt.
-
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.
Wieso spendiert man dem Wifi-Modul nicht irgendeine Art von API?
Kennt jemand eine gute "out of the box"-Alternative zum Nachrüsten?

