NEWS
[Neuer Adapter] mitsubishi-local-control
-
Freut mich, dass es bisher so problemlos läuft.
@darkblu sagte in [Neuer Adapter] mitsubishi-local-control:
Ich hab zwar eine kleine unstimmigkeit bei "fanSpeed", aber das wird wohl an meinem Modell liegen.
Der Adapter hat 0 bis 6, mein Gerät hat aber nur 0, 2, 3, 5 und 6 was in der ios App "auto, 1, 2, 3 und 4" heisst.Die Anzahl der möglichen Lüfterstufen ist einfach fest im Adapter vorgegeben. Welche Stufen vom jeweiligen Gerät unterstützt werden, lässt sich leider über diese Schnittstelle nicht raus finden.
Noch eine Frage, warum gibt es drei mal (verschiedene) Innentemperatur DP ?
Soweit mir bekannt ist es so:
- insideTemperature1Coarse -> Innentemperatur abgerundet auf ganze Zahl
- insideTemperature1Fine -> Innentemperatur auf 0.5°C genau
- insideTemperature2 -> Evtl. gibt es Geräte, die einen zweiten Temperatursensor haben? Bei mir steht da auch der gleiche Wert wie in insideTemperature1Fine drin
Also eigentlich ist in den meisten Fällen insideTemperature1Fine der interessante Wert.
Was zeigt "powerMode" an ? Zeigt bei mir "0" an aktuell.
Hab ich bisher auch nicht raus gefunden. Bei mir zeigt es im ausgeschalteten Zustand "0", im aktivierten "2" an.
"powerWatt" zeigt aktuell "1" an, die 3,2 W im screenshot sind von einem Shelly 1PM.
"energyHectoWattHour" kommt mir ein wenig hoch vor (Faktor 5), woher stammt der Wert ? Wahrscheinlich aus dem Gerät.Da hast du Recht, das stimmt nicht so ganz. Ich hab gerade nochmal in der Referenz-Implementierung nachgeguckt und da scheint die Einheit für die Leistung, die vom Gerät gemeldet wird, "100 Wh" zu sein und nicht "kWh" wie ich dachte.
Das habe ich angepasst und die beiden States umbenannt.- "energyHectoWattHour" -> "energyConsumed" (jetzt korrekt in kWh umgerechnet)
- "powerWatt" -> "powerConsumed" (weiterhin W)
Grundsätzlich kommen alle Werte so vom jeweiligen Gerät. Bei manchen war mir klar, was sie aussagen. Bei den genannten weiß ich es auch nicht 100% - wie du schon gemerkt hast 😅
Bitte nochmal mit v1.0.1-alpha.0 testen, ob es jetzt besser passt. Glaube dazu musst du aber im Dialog nicht über "von npm", sondern über "Benutzerdefiniert" gehen und folgenden Link verwenden: https://registry.npmjs.org/iobroker.mitsubishi-local-control/-/iobroker.mitsubishi-local-control-1.0.1-alpha.0.tgz
@mcm1957 Wenn ich wie du vorgeschlagen hattest, Alpha-Releases erstelle, werden die ja auf npm beim Standard Workflow mit "next" getaggt. In der Admin-UI muss der User diese dann wie oben beschrieben über die URL des Tarballs installieren oder gibt es eine andere Möglichkeit? Über den npm-Reiter scheint immer nur der "latest"-Tag angezogen zu werden.
-
Freut mich, dass es bisher so problemlos läuft.
@darkblu sagte in [Neuer Adapter] mitsubishi-local-control:
Ich hab zwar eine kleine unstimmigkeit bei "fanSpeed", aber das wird wohl an meinem Modell liegen.
Der Adapter hat 0 bis 6, mein Gerät hat aber nur 0, 2, 3, 5 und 6 was in der ios App "auto, 1, 2, 3 und 4" heisst.Die Anzahl der möglichen Lüfterstufen ist einfach fest im Adapter vorgegeben. Welche Stufen vom jeweiligen Gerät unterstützt werden, lässt sich leider über diese Schnittstelle nicht raus finden.
Noch eine Frage, warum gibt es drei mal (verschiedene) Innentemperatur DP ?
Soweit mir bekannt ist es so:
- insideTemperature1Coarse -> Innentemperatur abgerundet auf ganze Zahl
- insideTemperature1Fine -> Innentemperatur auf 0.5°C genau
- insideTemperature2 -> Evtl. gibt es Geräte, die einen zweiten Temperatursensor haben? Bei mir steht da auch der gleiche Wert wie in insideTemperature1Fine drin
Also eigentlich ist in den meisten Fällen insideTemperature1Fine der interessante Wert.
Was zeigt "powerMode" an ? Zeigt bei mir "0" an aktuell.
Hab ich bisher auch nicht raus gefunden. Bei mir zeigt es im ausgeschalteten Zustand "0", im aktivierten "2" an.
"powerWatt" zeigt aktuell "1" an, die 3,2 W im screenshot sind von einem Shelly 1PM.
"energyHectoWattHour" kommt mir ein wenig hoch vor (Faktor 5), woher stammt der Wert ? Wahrscheinlich aus dem Gerät.Da hast du Recht, das stimmt nicht so ganz. Ich hab gerade nochmal in der Referenz-Implementierung nachgeguckt und da scheint die Einheit für die Leistung, die vom Gerät gemeldet wird, "100 Wh" zu sein und nicht "kWh" wie ich dachte.
Das habe ich angepasst und die beiden States umbenannt.- "energyHectoWattHour" -> "energyConsumed" (jetzt korrekt in kWh umgerechnet)
- "powerWatt" -> "powerConsumed" (weiterhin W)
Grundsätzlich kommen alle Werte so vom jeweiligen Gerät. Bei manchen war mir klar, was sie aussagen. Bei den genannten weiß ich es auch nicht 100% - wie du schon gemerkt hast 😅
Bitte nochmal mit v1.0.1-alpha.0 testen, ob es jetzt besser passt. Glaube dazu musst du aber im Dialog nicht über "von npm", sondern über "Benutzerdefiniert" gehen und folgenden Link verwenden: https://registry.npmjs.org/iobroker.mitsubishi-local-control/-/iobroker.mitsubishi-local-control-1.0.1-alpha.0.tgz
@mcm1957 Wenn ich wie du vorgeschlagen hattest, Alpha-Releases erstelle, werden die ja auf npm beim Standard Workflow mit "next" getaggt. In der Admin-UI muss der User diese dann wie oben beschrieben über die URL des Tarballs installieren oder gibt es eine andere Möglichkeit? Über den npm-Reiter scheint immer nur der "latest"-Tag angezogen zu werden.
Bitte nochmal mit v1.0.1-alpha.0 testen, ob es jetzt besser passt. Glaube dazu musst du aber im Dialog nicht über "von npm", sondern über "Benutzerdefiniert" gehen und folgenden Link verwenden: https://registry.npmjs.org/iobroker.mitsubishi-local-control/-/iobroker.mitsubishi-local-control-1.0.1-alpha.0.tgz
.muss ich dann die 1.0.0 Instanz (also den Adapter) erst wieder löschen ?

Bei von NPM und von GITHUB finde ich den Adapter, aber keine Ahnung ob das der 1.0.0 ist.
Demnach müsste ich dann bei BENUTZERDEFINIERT den Link eingeben um an die 1.0.1 zu kommen ?
Ich bin mir nur nicht sicher, ob ich den 1.0.0 vorher wieder löschen soll/muss. -
Bitte nochmal mit v1.0.1-alpha.0 testen, ob es jetzt besser passt. Glaube dazu musst du aber im Dialog nicht über "von npm", sondern über "Benutzerdefiniert" gehen und folgenden Link verwenden: https://registry.npmjs.org/iobroker.mitsubishi-local-control/-/iobroker.mitsubishi-local-control-1.0.1-alpha.0.tgz
.muss ich dann die 1.0.0 Instanz (also den Adapter) erst wieder löschen ?

Bei von NPM und von GITHUB finde ich den Adapter, aber keine Ahnung ob das der 1.0.0 ist.
Demnach müsste ich dann bei BENUTZERDEFINIERT den Link eingeben um an die 1.0.1 zu kommen ?
Ich bin mir nur nicht sicher, ob ich den 1.0.0 vorher wieder löschen soll/muss.@darkblu Genau, du musst über Benutzerdefiniert gehen und den obigen Link verwenden. Du kannst die Version direkt über 1.0.0 installieren ohne sie vorher zu deinstallieren. Empfehlenswert ist es einmal den gesamten "devices"-Objektbaum zu löschen. Danach wird er wieder sauber angelegt.
-
Die alpha.0 ist sauber auf npm deployed worden. Danke @black-thunder
Damit bruachts du eigentlich nicht via tar file gehen sondern kanns ganz normal via (nicht von) npm installieren.
Anleitung folgt gleich - muss nur was suchen ... -
Wie kann ich eine ALPHA Version installieren?
Alpha-Releases können direkt von npm durch Eingabe der url 'iobroker.mitsubishi-local-control@next' (im Expertenmode oder auf der Commandline) installiert werden.mittels GUI
- Expert Mode aktivieren
- 'Katze' (install from custom url) anklicken
- als url iobroker.mitsubishi-local-control@next eingeben

Hinweis: Das bild vist vom shelly, bitte Adapoternamen in Gedanken ersetzen)auf der Commandline
iobroker url iobroker.mitsubishi-local-control@next
als Befehl eingeben
Um eine bestimmte Release zu installieren kann man auch als url iobroker.shelly@1.2.3-alpha.4 eingeben
Bei Verwendung des standardisierten Deploys werden Versionen fürs LATEST Repo (1.2.3) immer mit @latest getagged, alphas werden mit @next getagged.
-
ok, ich melde Vollzug.
Update wie von @mcm1957 erklärt, durchgeführt.
Objektbaum hat sich von alleine aktualisiert.
Alles funktioniert noch.
Die Energiewerte sind allerdings nach wie vor fragwürdig, egal, dafür habe ich ja den Shelly PM dran hängen.Ich bin soweit zufrieden und vermisse nix.
Nochmals besten Dank für deine Arbeit und Zeit. -
gerade noch beobachtet:
insideTemperature2 und insideTemperature1Fine können Nachkommastellen anzeigen, zumindest ,5.
Wobei mir insideTemperature2 realistischer vorkommt, deckt sich besser mit meinem Thermometer.
Power consumption scheint ziemlich genau zu sein, bei dem 60 sek. polling aber träge. Da bleibe ich bei meinem Shelly.
Energy consumption zählt auch brav hoch, aber keine Ahnung was er da misst. -
gerade noch beobachtet:
insideTemperature2 und insideTemperature1Fine können Nachkommastellen anzeigen, zumindest ,5.
Wobei mir insideTemperature2 realistischer vorkommt, deckt sich besser mit meinem Thermometer.
Power consumption scheint ziemlich genau zu sein, bei dem 60 sek. polling aber träge. Da bleibe ich bei meinem Shelly.
Energy consumption zählt auch brav hoch, aber keine Ahnung was er da misst.@darkblu Wunderbar, danke fürs schnelle Feedback.
Objektbaum hat sich von alleine aktualisiert.
Da dann am besten die beiden alten States "energyHectoWattHour" und "powerWatt" händisch löschen. Das sind sonst nur ungenutzte Leichen.
Power consumption scheint ziemlich genau zu sein, bei dem 60 sek. polling aber träge. Da bleibe ich bei meinem Shelly.
Energy consumption zählt auch brav hoch, aber keine Ahnung was er da misst.Das Polling könntest du auch bis 15 Sekunden runtersetzen. Aber die Messung über den Shelly wird so oder so genauer und zeitnaher erfolgen als es die gemeldeten Werte vom Gerät selbst zulassen, ja.
-
Bei mir funktioniert der Adapter auch wunderbar an einer MXZ2F-42VF3. Danke dafür!
Auch "powerWatt" ist immer zu hoch, das sind aber sicherlich die Werte die Mitsubishi liefert. In der MELCloud ist der Energieverbrauch in den Reports (z.B. 1 Jahr) auch immer höher als der mit einem Stromzähler (TOMZN DDS238-2, ursprünglich mit Tuya, auf Tasmota geflasht) ermittelte Wert. Am krassesten ist das im Standby wo "powerWatt" 16 W angibt, während es in Realität 4 W sind.
Die el. Leistung/Arbeit ist aber auch nicht primär das, was ich mit dem Adapter erreichen möchte :)
-
Bei mir funktioniert der Adapter auch wunderbar an einer MXZ2F-42VF3. Danke dafür!
Auch "powerWatt" ist immer zu hoch, das sind aber sicherlich die Werte die Mitsubishi liefert. In der MELCloud ist der Energieverbrauch in den Reports (z.B. 1 Jahr) auch immer höher als der mit einem Stromzähler (TOMZN DDS238-2, ursprünglich mit Tuya, auf Tasmota geflasht) ermittelte Wert. Am krassesten ist das im Standby wo "powerWatt" 16 W angibt, während es in Realität 4 W sind.
Die el. Leistung/Arbeit ist aber auch nicht primär das, was ich mit dem Adapter erreichen möchte :)
@Lokverführer sagte in [Neuer Adapter] mitsubishi-local-control:
Am krassesten ist das im Standby wo "powerWatt" 16 W angibt, während es in Realität 4 W sind.
ist der
@Lokverführer sagte in [Neuer Adapter] mitsubishi-local-control:
TOMZN DDS238-2
so exakt, dass du diesem mehr glaubst?
in dem Bereich ist Genauigkeit schon ein Problem.
(Gilt natürlich auch für Mitsubishi) -
Ja tatächlich glaube ich dem mehr als dem Mitsubishi-Schätzeisen, u.a. auch weil in den Eurovent-Daten der Mitsubishi ein Standby-Verbrauch von 4 Watt angegeben ist. Im Labor werden die da sicherlich genau gemessen haben.
-
Also bei dem Stromverbrauch ist irgendwie noch ein kleiner Wurm drin.
Ich habe an zwei meiner Geräte einen Shelly dran und erhalte folgende Ergebnisse:Gerät A (Single):
Shelly -> 688W
powerConsumed -> 167W
powerMode -> 4Gerät B (1 Inneneinheit an Multisplit):
Shelly -> 359W
powerConsumed -> 370W
powerMode -> 1Nur mal so in's Blaue getippt: Wenn ich bei Gerät A powerConsumed mit powerMode multipliziere, dann käme das Ergebnis schon sehr gut hin (668W). Und bei Gerät B wäre es ja so, wie es jetzt ist, auch schon okay.
Was denkt ihr?
Nutze derzeit v1.0.2
-
Also bei dem Stromverbrauch ist irgendwie noch ein kleiner Wurm drin.
Ich habe an zwei meiner Geräte einen Shelly dran und erhalte folgende Ergebnisse:Gerät A (Single):
Shelly -> 688W
powerConsumed -> 167W
powerMode -> 4Gerät B (1 Inneneinheit an Multisplit):
Shelly -> 359W
powerConsumed -> 370W
powerMode -> 1Nur mal so in's Blaue getippt: Wenn ich bei Gerät A powerConsumed mit powerMode multipliziere, dann käme das Ergebnis schon sehr gut hin (668W). Und bei Gerät B wäre es ja so, wie es jetzt ist, auch schon okay.
Was denkt ihr?
Nutze derzeit v1.0.2
@oxident Es könnte durchaus sein, dass "powerMode" eine Art Skalierungsfaktor für den zurückgegebenen Verbrauch ist. Aber dokumentiert ist das leider nirgends, da ja auch nie als offizielle Schnittstelle vorgesehen. In der Python-Implementierung, an der ich mich orientiere, stehen dazu auch nur Vermutungen:
# This seems demand-related. # It's 0 when off, and goes up to 6 (?) # On but not pumping is 1 (operating in Energy turns to 0 in this case) # Higher seems to indicate higher demandVon daher würde ich es gerne einfach so belassen wie es und die Werte 1:1 vom Gerät anzeigen. Im Einzelfall kann man sich wenn gewünscht natürlich eine einfache Logik schreiben, um den Verbrauch gewichtet mit dem Faktor in einen eigenen State zu schreiben.
-
Ich habe den Adapter Alpha 1.0.1 installiert für meine Multisplitanlage mit 4 Innengeräten. Für das erste IG-Gerät werden alle Daten angezeigt, für die anderen nicht. Es kommt: Polling error for Bad: Error: connect ECONNREFUSED 192.168.178.95:80. Wo liegt der Fehler?
-
Ich habe den Adapter Alpha 1.0.1 installiert für meine Multisplitanlage mit 4 Innengeräten. Für das erste IG-Gerät werden alle Daten angezeigt, für die anderen nicht. Es kommt: Polling error for Bad: Error: connect ECONNREFUSED 192.168.178.95:80. Wo liegt der Fehler?
@norfer Spontan würde ich sagen, dass die IP-Adressen der anderen 3 Geräte vermutlich nicht korrekt konfiguriert sind. Prüfe das bitte nochmal.
Welche WiFi-Adapter sind denn in den jeweiligen Geräten verbaut?Ansonsten bitte auf die v1.0.2 updaten und ein vollständiges Debug-Log anhängen.
-
Ich habe den Adapter Alpha 1.0.1 installiert für meine Multisplitanlage mit 4 Innengeräten. Für das erste IG-Gerät werden alle Daten angezeigt, für die anderen nicht. Es kommt: Polling error for Bad: Error: connect ECONNREFUSED 192.168.178.95:80. Wo liegt der Fehler?
@norfer Ich hatte ein ähnliches Problem und konnte aber auch die interne Webseite des Controllers selbst nicht erreichen. Melcloud hatte jedoch einwandfrei funktioniert.
Letzten Endes lag der Fehler bei mir an der Firmware des APs (Ubiquiti). Vielleicht liegt es bei Dir ja auch an "iobroker-fremden" Ursachen.
Ping geht?
-
@black-thunder
Die IPs sind korrekt und einzustellen gibt es nichts - oder?
Die WiFi-Adapter sind die original von Mitsu gelieferten. Alle IG sind über Melcloudhome zu bedienen.
Jetzt habe ich in der Instanz versucht, das Wohnzimmer-IG zu ersetzen durch das Bad-IG. Ergebnis: das Wohnzimmer-IG erscheint immer noch in den Objekten, das Bad immer noch nicht.
Jetzt alle IG gelöscht: Das Wohnzimmer ist immer noch da mit seiner korrekten IP und lässt sich nicht löschen.
Per Wlan kann ich alle IG über die MelcloudHome bedienen.
Ich werde morgen versuchen, die Version 1.0.2 zu installieren und dannn berichten. -
@black-thunder
Die IPs sind korrekt und einzustellen gibt es nichts - oder?
Die WiFi-Adapter sind die original von Mitsu gelieferten. Alle IG sind über Melcloudhome zu bedienen.
Jetzt habe ich in der Instanz versucht, das Wohnzimmer-IG zu ersetzen durch das Bad-IG. Ergebnis: das Wohnzimmer-IG erscheint immer noch in den Objekten, das Bad immer noch nicht.
Jetzt alle IG gelöscht: Das Wohnzimmer ist immer noch da mit seiner korrekten IP und lässt sich nicht löschen.
Per Wlan kann ich alle IG über die MelcloudHome bedienen.
Ich werde morgen versuchen, die Version 1.0.2 zu installieren und dannn berichten.@norfer Die Frage nach den WiFi-Adaptern war eher auf die konkrete Modellbezeichnung aller verbauten Adapter bezogen.
Stell bitte sicher, dass all deine Geräte vom ioBroker aus erreichbar sind (siehe auch den Hinweis von @oxident).
Was passiert,wenn du http://192.168.178.95:80/ im Browser aufrufst? Kommt dort ein Login-Screen? Kannst du dich dort mit "admin" / "me1debug@0567" anmelden?
Falls das geht, öffne mal http://192.168.178.95:80/unitinfo. Die Infos dort bitte hier zum Abgleich posten.Falls das obere schon scheitert und du noch tiefer einsteigen möchtest, kannst du auch einen Port-Scan auf die nicht funktionierenden IPs machen, z.B. mit nmap
nmap -sS -p- -vv 192.168.178.95Da muss Port 80 als "open" deklariert sein, z.B. so:
Starting Nmap 7.95 ( https://nmap.org ) at 2025-12-28 20:54 CET Initiating ARP Ping Scan at 20:54 Scanning 192.168.2.10 [1 port] Completed ARP Ping Scan at 20:54, 0.14s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 20:54 Completed Parallel DNS resolution of 1 host. at 20:54, 0.00s elapsed Initiating SYN Stealth Scan at 20:54 Scanning 192.168.2.10 [65535 ports] Discovered open port 80/tcp on 192.168.2.10 SYN Stealth Scan Timing: About 15.37% done; ETC: 20:58 (0:02:51 remaining) SYN Stealth Scan Timing: About 38.69% done; ETC: 20:57 (0:01:37 remaining) SYN Stealth Scan Timing: About 68.89% done; ETC: 20:57 (0:00:41 remaining) Completed SYN Stealth Scan at 20:56, 117.00s elapsed (65535 total ports) Nmap scan report for 192.168.2.10 Host is up, received arp-response (0.0031s latency). Scanned at 2025-12-28 20:54:58 CET for 117s Not shown: 65534 filtered tcp ports (no-response) PORT STATE SERVICE REASON 80/tcp open http syn-ack ttl 255 MAC Address: XXX (Murata Manufacturing) Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 117.31 seconds Raw packets sent: 131162 (5.771MB) | Rcvd: 133 (6.824KB)Wenn dort keine offenen Ports gelistet sind, hat Mitsubishi wohl die Lücke bei deinen WiFi-Adaptern schon gepatcht (siehe auch hier). Von Updates sollte man daher grundsätzlich Abstand nehmen, wenn man den lokalen Zugang nicht verlieren will.