ja, ist schon Mist, die API ist schon ok, aber die Stabilität der Server eher nicht …
Ich hatte ja schon was im Splitter eingebaut? das er bei Fehler nach einer einstellbaren Zeit den Aufruf (ohne Meldung) wiederholt, aber da ist auch irgendwann Schluss.
Ich hoffe nur, das die das irgendwann wieder den Griff bekommen.
Jetzt ist bei mir ganz vorbei:
14.10.2025, 13:11:04 | MieleAtHomeSplitter | url=https://api.mcs3.miele.com/thirdparty/token?client_id=XXXX&client_secret=XXX&grant_type=password&username=XXXX&password=XXXXX&state=token&redirect_uri=%2Fv1%2Fdevices&vg=de-DE => statuscode=210, err=got http-code 401 (unauthorized)
Hab es erst mal deaktiviert.
Hallo Leute,
erstmal herzlichen Dank an jeden, der hier Protokollmitschnitte gepostet hat. Ich lese hier seit mehreren Monaten mit, mit dem Ziel, die Miele@home API rein lokal (d.h. ohne Cloud), und quelloffen zu implementieren (nicht für Symcon, sondern allgemein).
Dies ist mittlerweile weitestgehend gelungen, u.A. eben aufgrund Eurer Mitschnitte und Codes. 
Wenn ihr von der Cloud-Anbindung ebenso genervt seit, wie ich es war, gebt doch einmal dieser lokalen Implementation eine Chance. Ich weiß nicht, ob sie mit dem hier häufig diskutierten XKM3000 auch funktioniert, sehe aber keinen Grund, warum dies nicht der Fall sein sollte. Entsprechendes Feedback würde ich sehr zu schätzen wissen. Den Code gibt es hier: GitHub - akappner/MieleRESTServer: Unofficial implementation of the Miele@Home protocol, allowing local connectivity without cloud connection.
Herzliche Grüße
– Alexander
Könntest du hier mal kurz umschneiden um was es geht, also was muss man installieren. Machst du ein Modul draus, usw…
Vielen Dank und lg
Das habe ich ehrlich gesagt auch nicht verstanden, was jetzt genau mit dem Modul zu machen ist und welche Einträge wie geändert werden müssen?
Guten Morgen,
ich habe gerade das PYROLYSE Programm gestartet. Das scheint nicht im Modul abgefangen zu werden:
02.11.2025, 10:57:46 | MieleAtHomeDevice | programType2text: unknown value 4
dump.txt (95,1 KB)
Die Umsetzung im Modul ist vermutlich gar nicht mehr erforderlich, war zu Anfangszeiten mal eher so. Damsl kamen auch im Feld “localised_value” eher kryptische Codes oder nichts, daher hatte ich den “key” selbst dekodiert.
Du könntest mal testhalber die 3 Schalter auf AUS stellen?
unabhängig davon übernehme ich natürlich diese Text ins Modul.
Nachtrag
in der Übertragung steht
(
[ProgramID] => Array
(
[value_raw] => 323
[value_localized] => Pyrolyse
[key_localized] => Programmbezeichnung
)
[programType] => Array
(
[value_raw] => 4
[value_localized] => Reinigungs-/ Pflegeprogramm
[key_localized] => Programmart
)
[programPhase] => Array
(
[value_raw] => 0
[value_localized] =>
[key_localized] => Programmphase
)
Moniert wird programType mit dem Wert 4. Als übersetzter Wert steht da Reinigungs- / Pflegeprogramm, Pyrolyse steht im Programm.
ABER: in der Miele-API steht, das für programType nur die Werte 0..3 zulässig sind - die Übertragung durch das Gerät widerspricht also der API-Dokumentation und wird eventuell wieder korrigiert.
Ein Grund mehr, die Übersetzung zu übernehmen und nicht selbst zu machen
Guten Morgen,
das Miele Modul macht heute schon wieder Probleme. Der Verbindungsaufbau per Website funktioniert und wird bestätigt.
Es erscheint bei der Prüfung in Symcon jedoch der Fehler
Auch werden alle Positionen in Symcon mit einem roten Ausrufezeichen versehen dargestellt.
Debug Protokolle
dump Splitter.txt (23,2 KB)
dump Konfigurator.txt (1,3 KB)
Gruß
Thimo
Ja, ich habe auch das Problem. Tut mir ja leid, aber da sind meine Möglichkeiten erschöpft, die Schnittstelle (Client-SSO) meldet (bei mir) laufend ein HTTP-Error 504 (Gateway-Timeout).
Die haben die Event-basierte Kommunikation nicht mehr im Griff.
Hallo demel42,
mach dir da keinen Kopf, was Miele hier macht ist schleierhaft. Es funktioniert 2-3 Tage ohne Probleme und dann kommt es immer wieder zu den Fehlern.
Selbst in der Miele App auf dem Handy habe ich immer wieder Probleme 
Gruß Thimo
bei mir ebenfalls
Moin in die Runde,
momentan scheint es bei (mir) eine kleines API Problem zu geben.
Gerne würde ich ja auch die Instanz ausschalten, doch das geht leider nicht …
Miele-dump.txt (34,5 KB)
Danke,
Grüße
Thomas
Aktualisier bitte mal auf die aktuelle Beta des Moduls ( v2.9#3 ), da sollte bei deaktiviertem MieleSplitter der SSO-Client ruhig sein..
Moin,
habe ich gerade gemacht …
Leider gleiches Verhalten … IPS habe ich schon mal neu gestartet …
Grüße
Thomas
Hi Thomas,
nach jetzt ca. 2-3 Stunden funktioniert die Schnittstelle zu Miele wieder 
Es handelt sich also eindeutig um ein Problem welches durch deren Seite verursacht wird, wenn man sich das so ansieht.
Gruß Thimo
Ah, da habe ich nicht richtig geschaut bzw. erstanden was du meinst.
Wenn Du den Splitter deaktivierst, wird die SSO auch deaktiviert.
Den SSO-Client kann man nicht alleine deaktivieren, dann ist der Splitter auch “tot”, da ein Child immer gestört ist, wenn der Parent nicht i.O. ist.
Ich hatte das schon probiert zu implementieren, aber wenn die IO inaktiviert wird (egal wie ich das mache), geht der Splitter auch in einen gestörten Zustand. Ich habe auch versucht, dem IO keine URL unterzujubeln etc - geht nicht.
@Dr.Niels : gibt es eine Möglichkeit, per Property den Weg zu einem IO zu kappen (dann könnte ich die Verbindung zu dem SSO-Client bei Bedarf stilllegen)? Das RequireParent() muss ja nach meiner Kenntnis bereits im Create() durchgeführt und nicht erst im ApplyChanges().
Das der “Aktiv”-Schalter in dem IO nicht bedienbar ist liegt daran, das der von dem Splitter parametriert wird,
Ja - nun ist die Schnittstelle auch wieder “online” bei mir …
Nur weil ein Parameter in der UI blockiert ist, schützt ihn das nicht vor Anpassung per Skript. Da sollte man aber natürlich wissen was man tut. Ansonsten können Verbindungen natürlich per IPS_DisconnectInstance gekappt werden.
sicher, aber das wird von dem MieleSplitter direkt wieder per GetConfigurationForParent() korrigiert, da der auf Änderungen des IO-Status reagiert. Grund hierfür: ich muss ja mitbekommen, wenn der IO ein Problem hat, um den AccessToken neu zu setzen.
Nur, wenn man Aktiv auf **Nein* setzt, ist das Child (also der Splitter) ja auch fehlerhaft (“Übergeordnetes Instanz ist fehlerhaft”).
Dh. bei jeder Initialisierung des Moduls (also zB bei Systemstart oder Aktualisierung) wird wieder ein IO angelegt (weil RequireParent() im Create() aufgerufen wird) … hmm, auch nicht wirklich doll. Blödes Problem wegen der instabilen API-Server
