Miele@Home XKM 3100W Protokollanalyse

Nachdem mich unser Forenmitglied „Brovning“ angesprochen hatte und fragte, ob sein Miele WLAN-Modul XKM 3100W sich direkt per IPS ansteuern ließe, hat mir das eine Ruhe gelassen. „Brovning“ war so freundlich, mir sein Modul zu zusenden. Danke dafür nochmal!

In diesem Thema soll es darum gehen, wie das Modul XKM 3100W kommuniziert und ob man es mit IPS direkt ohne Miele Gateway (XGW 3000) ansteuern kann.

Das Modul ist eingebaut - Nun kanns los gehen!

Als erstes habe ich das Modul erstmal auf Werkseinstellungen gesetzt. Das geht entweder über die Taste auf dem Modul (10 Sekunde drücken = Werkszustand) oder über das Miele@Home Menü der Waschmaschine.

Danach habe ich über mein Handy das Gerät ins WLAN eingebunden. Das Modul spannt ein eigenes Miele-WLAN auf, wo man sich mit dem Handy einbuchen muss. Das Passwort die die SerienNr der Maschine ohne führende Nullen. Dann kann man über die Miele@Mobile App das Netzwerk konfigurieren.

Nachdem man dann das WLAN auf dem Handy zurück auf das eigene gesetzt hat, sollte das Modul (Waschmaschine) gefunden werden.

Um die Kommunikation analysieren zu können, habe ich das Modul an einen Bintec Accesspoint angemeldet. Dieser Accespoint lässt es zu, die Kommunikation mit Wireshark zu analysieren.

Mich interessierte als erstes, wie die Anmeldung des Moduls mit der App funktioniert. Voraussetzung ist dabei, dass das Modul bereits im WLAN eingebunden ist.

1. Broadcast Frames

Jedes Miele-Gerät sendet auf dem Netzwerk regelmäßig Broadcast-Frames. Meine Waschmaschine sendet den Strings

mieleathome.tcp.local         W   Miele WMR860

.

Damit kann z.B. die Miele@Mobile App das Gerät finden.
Vermutung: Das „W“ bei der Gerätekennung besagt, dass das Gerät ein Waschautomat ist. „T“ würde für Trockner stehen.

2. Hinzufügen des Gerätes zur Miele@Mobile App

Nachdem die App das Gerät via Broadcast gefunden hat, kann man das Gerät auswählen und hinzufügen.
Nun passiert folgendes:

Die App sendet via HTTP-PUT folgendes ans Modul:


PUT /Security/Commissioning/ HTTP/1.1
Host: Miele-001D63FFFE049B4F.local.
Connection: keep-alive
Date: Sun, 12 Mar 2017 12:42:04 GMT
Accept: application/vnd.miele.v1+json
User-Agent: Miele@mobile 2.3.3 iOS
Content-Length: 172
Accept-Language: de-de
Accept-Encoding: gzip, deflate

{"GroupID":"0025DC69F3CE9FA4","GroupKey":"9F944A76F46AAAC11B818439BA53735A869BF1E1ACE6C3FCBAE898BFA87FE2CE595CB27BB23F3F6C1921D94D28FA0EB048537A2ADEC666B05F7BE4CDD5D46BDB"}

Das Modul antwortet mit:


HTTP/1.1 200 OK
Content-Type: application/vnd.miele.v1+json; charset=utf-8
access-control-allow-origin:*
access-control-allow-headers:Authorization
Date: Sun, 12 Mar 2017 12:42:03 GMT
Content-Length:205

[
	{"Success":{"GroupID":"0025DC69F3CE9FA4"}},
	{"Success":{"GroupKey":"9F944A76F46AAAC11B818439BA53735A869BF1E1ACE6C3FCBAE898BFA87FE2CE595CB27BB23F3F6C1921D94D28FA0EB048537A2ADEC666B05F7BE4CDD5D46BDB"}}
]

Was jetzt hier genau gemacht wird, kann ich nicht 100%ig sagen. Es scheint so, dass eine Verschlüsselung initialisiert wird. Die GroupID scheint eine Art einmalige Kennung des Gerätes zu sein. Der GroupKey wird eine Art Verschlüsselungszertifikat sein, womit die weitere Kommunikation verschlüsselt wird.

3. Gerätedaten abfragen
Die weitere Kommunikation erfolgt über HTTP-GET Aufrufe.
Die App fragt die allgemeinen Gerätedaten ab:


GET /Devices/ HTTP/1.1
Host: Miele-001D63FFFE049B4F.local.
Connection: keep-alive
Date: Sun, 12 Mar 2017 12:42:09 GMT
Accept: application/vnd.miele.v1+json
User-Agent: Miele@mobile 2.3.3 iOS
Authorization: MieleH256 0025DC69F3CE9FA4:733979F4F79A0E4D638E040DF0C218D355A85E7DA9D4BCE43F6A85A5D9FE1684
Accept-Language: de-de
Accept-Encoding: gzip, deflate

Das Modul antwortet mit:


HTTP/1.1 200 OK
Content-Type: application/vnd.miele.v1+json; charset=utf-8
access-control-allow-origin:*
access-control-allow-headers:Authorization
Date: Sun, 12 Mar 2017 12:42:08 GMT
Content-Length:112
X-Signature: MieleH256 0025DC69F3CE9FA4:DC65CAE29ABFF0D0E8836FBD1123AEB439591D360F2A976A4816F3B903EDD8DC

..>....u....@Z?.....p.1LE.T...V.z.[..m..L.b. ..iDm...iZ..F..@..O..T....V.....A.-.I!.p....K...=.m.@...~.u.U......

Bei der Anfrage wird als Authentication „MieleH256“ gesendet. Danach die GroupID und ein 32Byte lange Zeichenfolge, Hex-kodiert. Was das genau ist, kann ich nicht sagen.
Die eigentlichen Daten sind nicht lesbar, da verschlüsselt. Da bei Content-Type oben was von „json“ steht, kann man wohl von verschlüselten JSON-Daten ausgehen.

Soweit erstmal der aktuelle stand.

Fazit:

[ul]
[li]Die Kommunikation erfolgt über einfache HTTP-Nachrichten
[/li][li]Die eigentlichen Daten sind verschlüsselt mittels eines eigenen Verfahrens, was Miele „MieleH256“ nennt
[/li][li]Eine Kommunikation wäre grundsätzlich möglich, wenn wir die Verschlüsselung verstehen würden
[/li][/ul]

weiteres folgt in Kürze.

So, habe mich weiter mit der Verschlüsselung beschäftigt.

Die Verschlüsselte Nachricht wird gebildet aus folgenden drei Teilen:

[ol]
[li]Die unverschlüsselten Nachricht (JSON)
[/li][li]Der 64Byte lange GroupKey, der beim Paring ausgetauscht wird (Jedes Gerät hat seinen eigenen)
[/li][li]Die 32Byte Folge, die im jedem Header einer Verschlüsselten Nachricht steht (MieleH256 [GroupID]:[MessageKey])
[/li][li]
[/li][/ol]

Ich vermute, die Verschlüsselung ist symmetrisch. Es könnte AES sein (wegen der Kennung „MieleH256“ und dem 64 Byte GroupKey => 256bit).

Interessant dabei ist, das die selbe Nachricht (z.B. die 1. Nachricht beim Start eines Gerätes) verschlüsselt immer anders ist.
Der Grund könnte der MessageKey sein. Dieser wird vermutlich zufallsgeneriert und sorgt für immer andere Ergebnisse bei der Verschlüsselung.

Fragen über Fragen…

Hast Du schonmal versucht per Miele@Home App unter Geräteeinstellungen „SmartHome Integration“ ein Passwort zu vergeben? Evtl ist ja dann damit auch ein Kommunikationsaufbau möglich.

H256 bedeutet HMAC SHA256, der hintere Teil der Nachricht ist nur eine Signatur (vermutlich erzeugt mit dem initial festgelegten Key)

Hello!

Firstly, my apologies for not being able to communicate in German without the aid of my wife or Google Translate, however I have just installed an XKM 3100W in a H 6860 BP oven and would also like to understand the protocol. When I get the chance I will attempt to also use tcpdump and follow what is being sent. In the meantime this document might be of interest:

https://www.iana.org/assignments/media-types/application/vnd.miele+json

I’m be happy to help if there is anything I can do.

Best wishes,

James

Google Translate:

Hallo!

Zuerst entschuldige ich mich, dass ich nicht in der Lage bin, auf Deutsch ohne die Hilfe meiner Frau oder Google Translate zu kommunizieren, aber ich habe gerade ein XKM 3100W in einem H 6860 BP Ofen installiert und möchte auch das Protokoll verstehen. Wenn ich die Chance bekomme, werde ich versuchen, auch tcpdump zu benutzen und dem zu folgen, was gesendet wird. In der Zwischenzeit könnte dieses Dokument von Interesse sein:

https://www.iana.org/assignments/media-types/application/vnd.miele+json

Ich würde mich freuen, wenn es etwas gibt, was ich tun kann.

Mit freundlichen Grüßen,

James

The description of the document is interesting, but it just confirms what has been written above. In posting #2 you can also see the output of a tcpdump.
The hashing doesn’t seem to be the problem, generating the initial trust level is. However, so far I have not seen any secret pieces, i.e. an own script should be able to do the same thing the Miele@Home App is doing, register with a key and then use it so hash subsequent requests.

Gibt es hier Neuigkeiten?

Hallo,

Idee: Die Android App kann eine Verbindung herstellen, also muss das im Source ersichtlich sein. Ergo: Android App auseinandernehmen (mit APKTOOL) und schauen, was diese genau sendet bzw. empfängt…

Interessant könnte z.B. diese Klasse sein:

.class public Lde/miele/infocontrol/networking/http/interceptor/GroupModeAuthInterceptor; (enthält Konstante „MieleH256“, die sich auch per Wireshark finden lässt) sowie
.class public Lde/miele/infocontrol/networking/auth/PayloadEncryptor; (enthält u.a. :
.field private static final ALGORYTHM:Ljava/lang/String; = „AES“
.field private static final CIPHER_TYPE:Ljava/lang/String; = „AES/CBC/NoPadding“)

sowie die Methoden „encrypt“ und „decrypt“.

Ich glaube nicht, dass ich in den nächsten Wochen dazu komme… aber vielleicht hat ja jemand anders Lust, sich ein wenig da durch zu debuggen? :slight_smile:

Viele Grüße

phenx

Ich nochmal… nach ein wenig Decompilen und Smali in Java zurückverwandeln gibt es erste Ansätze, zumindest schonmal zum Entschlüsseln der empfangen Daten. Das habe ich testweise zusammengeschrieben hierfür:


public class Test {
    private static final String ALGORYTHM = "AES";
    private static final String CIPHER_TYPE = "AES/CBC/NoPadding";
    
	public static void main(String[] args) throws GeneralSecurityException {
		byte[] mGroupKey = javax.xml.bind.DatatypeConverter.parseHexBinary("<<<GROUP_KEY>>>");
		byte[] payload = javax.xml.bind.DatatypeConverter.parseHexBinary("<<<PAYLOAD>>>");
		String requestSignature = "<<<SIGNATURE>>>";
		
		// Die ersten 50 Prozent der "requestSignature" bilden den initVectorString
        String initVectorString = requestSignature.substring(0x0, (requestSignature.length() / 0x2));
        byte[] initVector = javax.xml.bind.DatatypeConverter.parseHexBinary(initVectorString);
        IvParameterSpec ivParameterSpec = new IvParameterSpec(initVector);
		
		// Die ersten 50 Prozent des "key" aus dem Konstruktor bilden den secretKey
		byte[] secretKey = Arrays.copyOf(mGroupKey, (mGroupKey.length / 0x2));
        SecretKeySpec secretKeySpec = new SecretKeySpec(secretKey, ALGORYTHM);

		// Java Standardklassen für die tatsächliche Entschlüsselung
		Cipher cipher = Cipher.getInstance(CIPHER_TYPE);
        cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec);
		byte[] decryptedPayload = cipher.doFinal(payload);
		
		System.out.print(new String(decryptedPayload, StandardCharsets.UTF_8));
	}

}

Mit:
<<<GROUP_KEY>>> als hexadezimalem Groupkey, der sich in der DB der Android App findet.
<<>> Dem per Wireshark mitgeschnittenen Inhalt, der von der Miele gesendet wurde
<<>> Dem Teil nach dem Doppelpunkt in der X-Signatur der Miele Response

Output (auf die GET /Devices/<<<DEVIDE_ID>>>/State/ HTTP/1.1) Anfrage:

{
	"Status":3,
	"InternalState":3,
	"ProgramType":0,
	"ProgramID":1,
	"ProgramPhase":256,
	"RemainingTime":[2,59],
	"StartTime":[0,0],
	"TargetTemperature":[4000],
	"Temperature":[-32768,-32768,-32768],
	"SignalInfo":false,
	"SignalFailure":false,
	"SignalDoor":true,
	"RemoteEnable":[15,0,0],
	"ProcessAction":0,
	"Light":0,
	"ElapsedTime":[0,0],
	"ExtendedState":"00180104000006400102010116013A98025801C2025801C200000000000000000000000100000000000000000000000000000000000000005514000000FF0200000102"
         }

Fehlt natürlich noch die andere Richtung, das Senden von Befehlen. Das scheint aber auch gar nicht allzu kompliziert zu sein…

Senden von Befehlen geht ohne Probleme wenn man sich die Signatur generiert… wie folgt (anhand der Daten aus dem ersten Post:


        SignatureBuilder signatureBuilder = new SignatureBuilder(<<<GroupKey>>>);
        String httpMethod = "GET";
        String resourcePath = "/Devices/";
        String date = "Sun, 12 Mar 2017 12:42:09 GMT";
        String accept = "application/vnd.miele.v1+json";
		signatureBuilder
			.httpMethod(httpMethod)
			.host(ip)
			.resourcePath(resourcePath)
			.date(date)
			.acceptHeader(accept)
			.contentTypeHeader(null)
			.requestBody(null);
        String signature = signatureBuilder.build();

Ergibt die im Eröffnungspost genannte Zeichenfolge „733979F4F79A0E4D638E040DF0C218D355A85E7DA9D4BCE43F6A85A5D9FE1684“. :smiley:


package de.phenx.mieletest;

import java.nio.charset.Charset;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class SignatureBuilder {
	    private String mAcceptHeader;
	    private String mContentTypeHeader;
	    private String mDate;
	    private String mHost;
	    private String mHttpMethod;
	    private byte[] mKey;
	    private String mRequestBody;
	    private String mResourcePath;
	    private String mSignature;
	    private static final Charset CHARSET_ASCII = Charset.forName("US-ASCII");
	    private static final String SIGNATURE_TYPE = "HmacSHA256";
	    
	    public SignatureBuilder(byte[] p1) {
	        mKey = p1;
	    }
	    
	    public SignatureBuilder acceptHeader(String p1) {
	        mAcceptHeader = p1;
	        return this;
	    }
	    
	    public String build() throws IllegalStateException {
	        String sourceString = buildSignatureString();
	        byte[] sourceStringASCII = sourceString.getBytes(CHARSET_ASCII);
	        byte[] signatureBytes;
	        try {
	            signatureBytes = sign(sourceStringASCII);
	        } catch(Exception e) {
	            return sourceString;
	        }
	        mSignature = javax.xml.bind.DatatypeConverter.printHexBinary(signatureBytes).toUpperCase();
	        return mSignature;
	    }
	    
	    public SignatureBuilder contentTypeHeader(String p1) {
	        mContentTypeHeader = p1;
	        return this;
	    }
	    
	    public SignatureBuilder date(String p1) {
	        mDate = p1;
	        return this;
	    }
	    
	    public SignatureBuilder host(String p1) {
	        mHost = p1;
	        return this;
	    }
	    
	    public SignatureBuilder httpMethod(String p1) {
	        mHttpMethod = p1;
	        return this;
	    }
	    
	    public SignatureBuilder requestBody(String p1) {
	        mRequestBody = p1;
	        return this;
	    }
	    
	    public SignatureBuilder resourcePath(String p1) {
	        mResourcePath = p1;
	        return this;
	    }
	    
	    private String buildSignatureString() throws IllegalStateException {
	        if(mHttpMethod == null) {
	            throw new IllegalStateException("HTTP Method is not set");
	        }
	        if(mHost == null) {
	            throw new IllegalStateException("Host is not set");
	        }
	        if(mDate == null) {
	            throw new IllegalStateException("Date is not set");
	        }
	        StringBuilder sb = new StringBuilder(mHttpMethod);
	        sb.append("
");
	        sb.append(mHost);
	        if(mResourcePath != null) {
	            sb.append(mResourcePath);
	        }
	        sb.append("
");
	        if(mContentTypeHeader != null) {
	            sb.append(mContentTypeHeader);
	        }
	        sb.append("
");
	        if(mAcceptHeader != null) {
	            sb.append(mAcceptHeader);
	        }
	        sb.append("
");
	        sb.append(mDate);
	        sb.append("
");
	        if(mRequestBody != null) {
	            sb.append(mRequestBody);
	        }
	        return sb.toString();
	    }
	    
	    private byte[] sign(byte[] p1) throws NoSuchAlgorithmException, InvalidKeyException {
	        Mac mac = Mac.getInstance(SIGNATURE_TYPE);
	        if(mKey != null) {
	            SecretKeySpec secretKey = new SecretKeySpec(mKey, SIGNATURE_TYPE);
	            mac.init(secretKey);
	        }
	        return mac.doFinal(p1);
	    }
}

Damit ist es möglich, mit dem Gerät zu kommunizieren.

Mich würde interessieren, ob jemand eine Übersicht der möglichen Befehle und Antworten hat?

Wer selbst ein wenig damit spielen will und Befehle an sein Miele Gerät senden möchte (auf eigene Gefahr!):

[ul]
[li] Eclipse herunterladen
[/li][li] jce_policy-8.zip (bei Java 8) in das Java Verzeichnis entpacken (google gibt Details) damit die Verschlüsselungsstärke unterstützt wird
[/li][li] Neues Projekt anlegen
[/li][li] http://dl.phenx.de/miele_xkm3100w.zip enthält den Source
[/li][li] In die Config.java Hostnamen, GroupId und Groupkey eintragen (z.B. per Wireshark mitgelesen oder aus der SQLite Datenbank der Android App extrahiert, Verzeichnis /data/data/de.miele…/databases/mieleathome.db auf dem Handy)
[/li][li] Test.java ausführen
[/li][/ul]

In der Test.java kann dann je nach Bedarf herumgespielt werden… der interessanteste Parameter war für mich erst einmal request.setResourcePath. Hier noch ein paar Beispiele:

„/“:

Response Status: 200
Decrypted:
{
	"Devices":{"href":"Devices/"},
	"Subscriptions":{"href":"Subscriptions/"},
	"Host":"Miele-000000000000000.local.",
	"Info":"",
	"Diagnose":{"href":"Diagnose/"},
	"WLAN":{"href":"WLAN/"},
	"Homebus":{"href":"Homebus/"},
	"Update":{"href":"Update/"}
   }

Im Prinzip kann über alles wo „href“ steht navigiert werden, z.B.

„/Devices/“:

Response Status: 200
Decrypted:
{
	"000000000000":
	{
		"href":"00000000000000000/",
		"Group":"000000000000000000",
		"Pairing":"false"
	}
          }

„/Devices/000000000000/“:

Response Status: 200
Decrypted:
{
	"Ident":{"href":"Ident/"},
	"State":{"href":"State/"},
	"DOP":{"href":"DOP/"},
	"Settings":{"href":"Settings/"}
            }
}

„/Devices/000000000000/State/“:

Response Status: 200
Decrypted:
{
	"Status":5,
	"InternalState":3,
	"ProgramType":0,
	"ProgramID":1,
	"ProgramPhase":514,
	"RemainingTime":[0,37],
	"StartTime":[0,0],
	"TargetTemperature":[4000],
	"Temperature":[-32768,-32768,-32768],
	"SignalInfo":false,
	"SignalFailure":false,
	"SignalDoor":false,
	"RemoteEnable":[15,0,0],
	"ProcessAction":0,
	"Light":0,
	"ElapsedTime":[3,5],
	"ExtendedState":"0018010203A006400102010111003A98025801C2025801C2019000A30000000000000003000000000000000000000008000000000000000056B8000002010300000102"
        }

„/Update/“:

Response Status: 200
Decrypted:
{
	"NewerAvailable":false,
	"CurrentVersion":"2.10",
	"AvailableVersion":"",
	"Type":"XKM3100W",
	"ReleaseNotes":"",
	"UpdateInProgress":false
}

Viel Spaß damit.

Wow sehr gut!!! :smiley:

Nächster Schritt wäre hierfür eine IPS Integration zum erst einmal Rumspielen zu entwickeln.

Hallo Symcon-Community,

zunächst einmal Glückwunsch und unsere Anerkennung für Eure bisherige Leistung bei der Analyse unseres Kommunikationsprotokolls. Wir lesen schon eine ganze Zeit lang mit und sind bisher bewusst nicht eingeschritten, da wir schauen wollten wie weit Ihr kommt :slight_smile:

Wir haben uns schon gefragt, wann der oder die Erste auf die Idee kommt sich die Android APP genauer anzusehen. Auch an dieser Stelle nochmal unsere Anerkennung an Phenx, dem ohne entsprechende Dokumentation gelungen ist die Logik zu verstehen.

Wer sind wir? Wir sind das Miele@home Entwicklungsteam aus Gütersloh, also diejenigen die sich die Protokolle ausgedacht, sowie die zugehörigen Kommunikationsmodule (XKM, etc.) implementiert haben.

Da Ihr ja nun die meisten Details herausgefunden habt, haben wir uns entschieden Euch ein paar Hintergrundinformationen zu geben und Euch natürlich dabei auch ein paar Tips zu geben. Das Kommunikationsprotokoll, das im Heimbereich genutzt wird ist eine klassische REST-API mit JSON-Payload. Unser Hauptanwendungsfall ist die Kommunikation zwischen den Geräten, also zum Beispiel für die Anwendung SuperVision. Aktuell nutzt auch unsere APP teilweise die direkte Kommunikation mit den Geräten, sofern sich diese im gleichen Netzwerk befinden. Die Kommunikation selbst ist mit AES-256 und HMAC-SHA256 gegen unbefugten Zugriff im Heimbereich geschützt. Für die Kommunikation über das Internet nutzen wir Standard TLS 1.2.

Die Schnittstelle selbst haben wir bewusst nicht selbst veröffentlicht, obwohl sie vermutlich sehr einfach zu implementieren ist, wie User Phenx gezeigt hat. Grund ist, dass wir an den REST-Ressourcen häufig Änderungen durchführen und dabei nur die Kompatibilität mit unseren Anwendungen (SuperVision, Miele@mobile, usw.) sicherstellen können. Warum ist das so? Das liegt daran, dass wir auf dem Kommunikationsmodul im optimierten Embedded-Bereich unterwegs sind und nicht wirklich ein dafür erforderliches API-Management realisieren können. Aber es wird dafür sehr bald eine offizielle Lösung von Miele geben (im Rahmen einer API).

So, jetzt aber zurück zum eigentlichen Thema. Natürlich alles unter dem offiziellen Disclaimer, das wir uns Änderungen an der Schnittstelle jederzeit vorbehalten. Für Eure geplante Integration sind die beiden Ressourcen Ident und State interessant. Wie man daran kommt hat der User Phenx ja bereits beschrieben :slight_smile:

Bisher habt Ihr GET Operationen ausgeführt. Es sind auch einige (nicht alle) Felder mit einem PUT schreibbar. Jetzt gibt es daher ein paar Hintergrundinformationen, die in der APP (noch) nicht implementiert sind.

  1. Unter /Ident/ könnt Ihr dem Feld „DeviceName“ einen individuellen Namen geben. Dieser taucht dann auch in der Miele@mobile APP, sowie im Display mancher Haushaltsgeräte auf (die Gen6000 Einbaugeräte).

  2. Unter /State/ findet Ihr das Feld „StartTime“, damit kann die Startzeit verschoben werden. Natürlich nur dann wenn eine Startvorwahl läuft.

  3. Unter /State/ gibt es noch das Feld „Light“, dort bedeutet NULL=Funktion unterstützt aber Zustand nicht bekannt, 0=Aus, 1=An, 2=Funktion nicht unterstützt

Viel Erfolg beim Ausprobieren. Wir freuen uns natürlich auch über jede Art von Feedback oder Verbesserungsvorschläge, vielleicht ist ja auch Lob dabei :wink:

Viele Grüße aus Gütersloh

Euer Miele@home Enwicklungsteam

PS
Wir schauen von Zeit zu Zeit hier vorbei, Ihr könnt uns auch gerne eine PN schicken. Bitte habt Verständnis dafür, wenn wir nicht sofort antworten sondern das etwas Zeit in Anspruch nimmt. Wir machen das auch aus privatem Interesse „nebenbei“.

Hallo Miele@home Entwicklungsteam,

danke für eure Rückmeldung. Finde ich sehr schön von euch, dass ihr euch hier so positiv zu dem Thema einklingt. Hut ab dafür, da kann sich so mancher Hersteller eine Scheibe abschneiden. Ich freue mich jedenfalls sehr über euren Kommentar von offizieller Seite :slight_smile:

Es ist verständlich, dass ihr eine proprietäre Schnittstelle nicht veröffentlicht, so lange sie nicht stabil ist und jederzeit Änderungen auftreten können. Da entstehen dann natürlich zahlreiche zusätzliche Verpflichtungen hinsichtlich Abwärtskompatibilität etc.

Umso interessanter ist die angesprochene offizielle API. Dürft ihr da schon Details zu verraten? Es wäre ja sehr schade, wenn jetzt einige Manntage in das „reverse Engineering“ der inoffiziellen Schnittstelle fließen, wenn die offizielle Lösung schon vor der Tür steht. Insbesondere der zeitliche Horizont und eine grobe Abschätzung des Funktionsumfanges wären interessant. Und ob die Lösung frei nutzbar sein wird oder an Auflagen (finanziell oder lizenztechnisch) gebunden sein wird :wink:

Es juckt mich ja schon in den Fingern, die in der APP noch nicht dokumentierten Befehle auszuprobieren… mal schauen wann ich dafür ein wenig freie Zeit finde. Abgesehen davon bin ich an dieser Stelle erst einmal heraus mit der weiteren Entwicklung, da bei mir zunächst die weitere Renovierung der mit Smart Home Komponenten zu versorgenden Wohnung ansteht, danach geht es dann ans Eingemachte mit der Steuerung und Einbindung der Systeme. IP Symcon werde ich mir bei der Gelegenheit dann auch einmal anschauen, ggf. wird es aber auch eine andere Lösung (homematic, openHAB). Je nachdem welche Lösung es wird, werde ich dann schauen, wie sich mein Miele Waschtrockner am schönsten ingetrieren lässt.

Was mich tatsächlich noch interessieren würde: Ich habe neulich in der Anleitung meines neuen Miele Kochfeldes die Möglichkeit der Smart Home Integration entdeckt. Allerdings waren keine Details angegeben, wie diese technsich herzustellen ist. Auf meine Nachfragen beim Miele Support hat sich dann herausgestellt, dass sämtliche Kochfelder, auch gerade neu erschienene, zur Anbindung das Miele Gateway benötigen, also noch auf Zigbee setzen. Im Gegensatz zu den anderen Geräten, die mittlerweile auf WLAN umgestellt sind. Was ist der Grund hierfür? Ich hätte vermutet, dass Zigbee durch WLAN komplett abgelöst wird, aber das scheint nicht der Fall zu sein. Gibt es noch eine andere Kommunikationsmöglichkeit mit den Kochfeldern, ohne das ~300€ Gateway hierfür extra anschaffen zu müssen?

Viele Grüße

Hallo phenx,

vielen Dank für Deine Rückmeldung und Dein Verständnis. Im ersten Schritt wird auf unserer offiziellen API eine Teilmenge von /Ident/ und /State/ mit zusätzlichen Lokalisierungsinformationen (=Übersetzungen und Einheiten) verfügbar sein. Damit wird man den aktuellen Gerätezustand von seinen Geräten anzeigen können. Das werden wir dann nach und nach ausbauen. Die API wird offen und frei verfügbar sein.

Wenn Du Interesse hast, können wir Dich auch gerne informieren sobald wir eine Version verfügbar haben. Wir posten das auf jeden Fall in diesem Forum. Eventuell möchtest Du auch schon etwas mit einer Vorab-Version machen? Die Ideen von einem openHAB Binding oder einer Symcon Integration klingen spannend.

Jetzt hätten wir aber auch eine Frage an Dich und alle anderen hier. Welche Informationen würdet Ihr Euch denn auf solch einer API wünschen? Wir würden dann jetzt mal schauen, was wir davon vielleicht direkt ergänzen können.

Viele Grüße aus Gütersloh

Euer Miele@home Enwicklungsteam

PS
Zu Deiner Frage mit dem Kochfeld: Die Möglichkeit das Kochfeld mit ZigBee aktuell einzubinden ist über das XGW3000. Alternativ geht das natürlich auch über ZigBee :slight_smile: Am XGW3000 haben wir aber noch eine weitere API, die schon jetzt offen und frei verfügbar ist. Das ist die sog. Homebus-Schnittstelle. Das ist eine XML-RPC API auf der neben den ZigBee Geräten auch die IP-Geräte abgefragt werden können.

Hallo MieleDevelopmentTeam.
Für mich wären das Auslesen der verbrauchswerte (Strom, Wasser) und Füllstände am wichtigsten.
Und wenn ich noch einen wusch frei hätte das neu anlegen/editieren von Favoriten Programmen!

Aktuell setzte ich folgende Miele Produkte ein:
Miele XGW 3000 Gateway
Wäschetrockner TMV840WP ZigBee
Waschmaschine WMV960WPS ZigBee
Geschirrspüler G 6895 SCVi XXL K2O Wlan

Viele Grüße, Raul.

  • Da ich eine PV-Anlage mit höherer Förderung der Eigenverbrauchsleistung habe, würde ich gerne Geräte wie Spül- und Waschmaschine bei bestimmten Zuständen starten lassen.

  • Da ich einen Holzofen habe, möchte ich gerne die Dunstabzugshaube sperren/drosseln.

Hallo luar und integrator,

vielen Dank für Eure Ideen. Der Wunsch nach den Verbrauchswerten und Füllständen ist notiert. Wir schauen, wann und für welche Geräte das möglich ist.

@luar: Du nutzt ja ein XGW3000. Hast Du Dir dabei schonmal die Homebus Schnittstelle angesehen? Da bekommst Du eine erste Prognose für den Verbrauch. Die Schnittstelle ist im Handbuch vom XGW3000 vollständig dokumentiert. Da sind auch jetzt schon Funktionen enthalten, um Geräte zu starten/stoppen.

@integrator: Die Idee klingt spannend. Dafür müsste man bei einem Gerät „SmartGrid“ aktivieren und könnte es dann vor dem geplanten Zeitpunkt starten. Die Funktion SmartGrid wird aktuell bei einigen Geräten für Wäschepflege (z.B. Waschmaschine, Trockner) und Geschirrspülern unterstützt. Wir sehen Du hast eine Dunstabzugshaube. Dann hast Du vermutlich ein XGW3000, um die Einbindung in das IP Netzwerk zu realisieren? Wenn dem so ist, kannst Du auch heute schon über die Homebus Schnittstelle sowohl ZigBee Geräte als auch WLAN Geräte Starten (wenn SmartGrid aktiviert ist). Schau Dir die Schnittstelle einfach mal an.

Viele Grüße aus Gütersloh

Euer Miele@home Enwicklungsteam

Danke … ich schaue mir „SmartGrid“ mal näher an. Wo gibt es Infomaterial darüber?

Eine XGW 3000 habe ich, der Dunstabzug ist aber noch konventionell.

:rolleyes:Ich möchte ehrlich sein, ich beobachte den Bereich „Smarte Küchengeräte“ schon seit 2002 und eine weitere Investition mache ich nur wenn die Hersteller endlich ihre Versprechen und Ideen in die Tat umsetzen. In der Vergangenheit fühlte man sich schon sehr verar****. Hierfür ist mir sehr wichtig/unabdingbar …

  • offene Schnittstelle:loveips:
  • kein Cloudzwang
  • Investitionsschutz
  • Kompatibilität