MieleCloudService Adapter

[MarkA]

@grizzelbee

Hab die Instanz auch gestoppt und den Objektbaum gelöscht

Hier mal ein Screenshot:

[Grizzelbee]

@marka

Okay. Das Ausschlaggebende hier ist die Rolle also "Button". Wenn du den Expertenmodus verlässt siehst du das aus dem true so ein rotes Hütchen wird. Das soll (glaube ich) einen Taster darstellen - jedenfalls funktioniert es genau wie ein Taster. Im Gegensatz dazu der Power-Switch direkt darüber. Der wird tatsächlich zwischen true und false hin- und hergeschaltet.

[rekorboi]

@Grizzelbee
Bin jetzt auch auf der 6.1.5. Die Datenpunkte zur Wärmeschublade werden befüllt, vielen Dank für die prompte Umsetzung!

Eine Warnung gibt es diesbezüglich jedoch:

2022-05-10 19:29:38.124 - warn: mielecloudservice.0 (3324) Object XXXXXXXXXXXX.ACTIONS.programId is invalid: obj.common.type has an invalid value (integer) but has to be one of number, string, boolean, array, object, mixed, file, json
2022-05-10 19:29:38.125 - warn: mielecloudservice.0 (3324) This object will not be created in future versions. Please report this to the developer.
2022-05-10 19:29:38.735 - info: mielecloudservice.0 (3324) State value to set for "mielecloudservice. XXXXXXXXXXXX.ACTIONS.programId" has to be type "integer" but received type "number"

Anfangs kamen diese Meldungen nur beim Neustart des Adapters, dann allerdings öfters und momentan sekündlich.

Dazu kommen des Öfteren Reconnect-Versuche:

2022-05-10 00:34:54.349 - info: mielecloudservice.0 (889) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to reconnect.
2022-05-10 00:39:54.350 - info: mielecloudservice.0 (889) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to reconnect.
2022-05-10 00:44:54.350 - info: mielecloudservice.0 (889) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to reconnect.
2022-05-10 00:49:54.350 - info: mielecloudservice.0 (889) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to reconnect.
2022-05-10 00:54:54.351 - info: mielecloudservice.0 (889) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to reconnect.
2022-05-10 00:59:54.351 - info: mielecloudservice.0 (889) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to reconnect.

Als mir zufällig die fehlende Aktualisierung der Datenpunkte auffiel, zeigte das Log aktuelle „Trying to reconnect“ Meldungen, jedoch hat in diesem Fall nur ein manueller Neustart der Instanz geholfen.

[Grizzelbee]

@rekorboi und alle:

Bezüglich der Crashes und reconnect Versuche: Das Thema ist vertrackt. Der Code der 6.1.5 ist noch nicht perfekt - da arbeite ich gerade dran. Das Hauptproblem ist aber, dass die API (also die Miele-Server) nach vollkommen willkürlichen Zeiträumen Fehler melden und der Adapter sich dann nicht einfach so automatisch reconnecten lässt.
Aus diesem Grunde werde ich mich mal an Miele wenden und baue gerade als Backup das Polling wieder ein.

@rekorboi Bezüglich der Wärmeschublade:
Lass bitte mal ein Debug-Log schreiben; vom Start des Adapters, das Gerät einmal ein- und wieder ausschalten und den Adapter wieder stoppen. Dann schickst Du mir das. Das Problem ist, das manche Geräte aufwändigere Programminfos haben und die kann der Adapter noch nicht. Das muss ich nach und nach implementieren.

[Gargano]

@grizzelbee Habe jetzt auch diese Fehlermeldung mit Einfrieren des Adapters
Version 6.1.5

2022-05-13 12:22:18.517 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error"}
2022-05-13 12:22:38.457 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error","message":"socket hang up"}
2022-05-13 12:23:18.520 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error"}
2022-05-13 12:23:38.412 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error"}
2022-05-13 12:25:38.535 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error"}
2022-05-13 12:26:09.437 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error"}
2022-05-13 12:29:38.546 - warn: mielecloudservice.0 (1854860) Received error message by SSE: {"type":"error"}

[Grizzelbee]

@gargano Ja - ich weiß.
Ich habe die gleichen Probleme. Sehr unerfreulich das alles.
Ich habe aber die V6.2.0 seit gestern bei mir im Langzeittest und hoffe die in Kürze veröffentlichen zu können. Da habe ich primär versucht die SSEs stabiler zu bekommen, aber auch das Data-Polling als Notlösung wieder eingebaut. Bisher sieht es aber ganz gut aus. Ich habe zwar nach wie vor Fehler bezüglich der Connection im Log, aber die haben sich alle selbst geheilt. Ich scheine eine Art Gleichgewicht gefunden zu haben.
Mal weiter abwarten wie es sich entwickelt...

[MarkA]

Hallo,

auch wenn ich mit meinem Deckenlüfter nerve, leider ein Problem mit dem DP der Lüfterstufe:

State value to set for "mielecloudservice.0.mac-SERIALNUMBER.ACTIONS.VentilationStep" has to be type "boolean" but received type "number"

Gruß Mark

[Grizzelbee]

@marka

Hallo Mark,

schreib doch bitte mal ein Debug-Log des Adapters und schicke es mir (entweder per mail oder hier als zip anhängen müsste auch klappen - ansonsten Issue auf github öffnen und dort als zip anhängen).

[MarkA]

@grizzelbee

Anbei das Log...

MieleCloudServiceAdapter-Mark-DEBUG-2022-05-16.zip

[Grizzelbee]

@marka

V6.2.1 (2022-05-16) (Black Wings)

• (grizzelbee) Fix: 242 VentilationStep needs to be type number but was boolean
• (grizzelbee) Fix: ACTIONS.programId is invalid: obj.common.type has an invalid value (integer) ...

https://github.com/Grizzelbee/ioBroker.mielecloudservice/issues/242

Grizzelbee created this issue in Grizzelbee/ioBroker.mielecloudservice

closed ACTIONS.VentilationStep" has to be type "boolean" but received type "number" #242

[rekorboi]

@Grizzelbee
Danke für den Fix, die Warnung „ACTIONS.programId is invalid: obj.common.type has an invalid value (integer)...” ist verschwunden.

Bin jetzt auf der 6.3.1, hinsichtlich des zeitbasierten Pollings sind mir zwei Punkte aufgefallen:

1. Die Abfrageintervalleinheit-Dropdown-Liste bietet nicht die Optionen Sekunden/Minuten sondern Sekunden/Protokoll.
2. Das zeitbasierte Polling füllt das Info-Log mit Unmengen an Einträgen. Bei jeder einzelnen Abfrage kommen hier 5 Einträge (5 Geräte):

2022-05-26 14:26:26.748 - info: mielecloudservice.0 (5119) Actions: {"XXXXXXXXXXX2":{"processAction":[],"light":[],"ambientLight":[],"startTime":[],"ventilationStep":[],"programId":[],"targetTemperature":[],"deviceName":false,"powerOn":true,"powerOff":false,"colors":[],"modes":[]}}
2022-05-26 14:26:26.882 - info: mielecloudservice.0 (5119) Actions: {"XXXXXXXXXXX3":{"processAction":[],"light":[],"ambientLight":[],"startTime":[],"ventilationStep":[],"programId":[],"targetTemperature":[],"deviceName":false,"powerOn":true,"powerOff":false,"colors":[],"modes":[]}}
2022-05-26 14:26:27.020 - info: mielecloudservice.0 (5119) Actions: {"XXXXXXXXXXX4":{"processAction":[],"light":[],"ambientLight":[],"startTime":[],"ventilationStep":[],"programId":[1,2,3,4],"targetTemperature":[],"deviceName":false,"powerOn":true,"powerOff":false,"colors":[],"modes":[]}}
2022-05-26 14:26:27.239 - info: mielecloudservice.0 (5119) Actions: {"XXXXXXXXXXX1":{"processAction":[2,3],"light":[1],"ambientLight":[],"startTime":[],"ventilationStep":[],"programId":[],"targetTemperature":[],"deviceName":true,"powerOn":false,"powerOff":true,"colors":[],"modes":[]}}
2022-05-26 14:26:27.411 - info: mielecloudservice.0 (5119) Actions: {"XXXXXXXXXXX5":{"processAction":[],"light":[1],"ambientLight":[],"startTime":[],"ventilationStep":[],"programId":[],"targetTemperature":[],"deviceName":false,"powerOn":true,"powerOff":false,"colors":[],"modes":[]}}

Auf das zeitbasierte Polling war ich gewechselt, da die SSE-Variante auf einmal sehr ressourcenhungrig erschien und den Pi in der bestehenden Konfiguration deutlich ausbremste. Momentan fehlt mir allerdings die Zeit für eine detailliertere Analyse, daher zunächst das definierte Abfrageintervall. Alle genannten Punkte sind mir mit Version 6.2.1 aufgefallen, 6.3.1 brachte anscheinend keine diesbezügliche Änderung.

[Grizzelbee]

@rekorboi
Viele Dank für die Infos! Da ich selbst das polling nicht einsetze, ist mir nicht allers davon bewusst.

1. Die Abfrageintervalleinheit-Dropdown-Liste bietet nicht die Optionen Sekunden/Minuten sondern Sekunden/Protokoll.

Jaaaa - das ist ein Problem von Google translate - und ich bin es leid immer und immer wieder dagegen anzukämpfen. Zumal ich es nur im Deutschen beurteilen und fixen könnte. Die anderen Sprachen blieben im Zweifel falsch übersetzt. Das zugrunde liegende Problem ist das "Minutes" im englischen sowohl "Minuten" als auch "Protokoll/Mitschrift" bedeutet (wer auch immer sich DAS ausgedacht haben mag ...). Ich weiß das das Kacke ist, aber ich werde es so lassen. Zumindest bis mich jemand eines besseren belehrt oder für alle Sprachen einen Fix einreicht - jedes mal auf Neue, wenn das wieder kaputt gegangen ist.

Das zeitbasierte Polling füllt das Info-Log mit Unmengen an Einträgen. Bei jeder einzelnen Abfrage kommen hier 5 Einträge (5 Geräte):

Da habe ich wohl noch einen als debug-log gemeintein Eintrag fälschlicherweise auf info stehen. Das fixe ich gerne in der nächsten Version - bringe dafür aber keine eigene Version raus.

Auf das zeitbasierte Polling war ich gewechselt, da die SSE-Variante auf einmal sehr ressourcenhungrig erschien und den Pi in der bestehenden Konfiguration deutlich ausbremste

Das kann ich mir ehrlich gesagt nicht vorstellen. Es ist zwar so, dass bei SSE tatsächlich alle 5 Sekunden eine PING Nachricht vom Server reinkommt, die aktualisiert aber nur eine timestamp Variable im Adapter und fertig. Mehr macht die nicht. Und alle 5 Minuten prüft der Watchdog ob dieser Timestamp aktuell ist. Die komplette Anforderung und Verarbeitung der Gerätedaten (Status und verfügbare Aktionen) beim Polling verbraucht (je nach Intervall) sicherlich mehr Resourcen.

Alle genannten Punkte sind mir mit Version 6.2.1 aufgefallen, 6.3.1 brachte anscheinend keine diesbezügliche Änderung.

Das kann gut sein. Das Polling ist ganz klar eine Notlösung und ein Stiefkind. Mein Fokus liegt klar auf SSE - weil es die bessere Techniologie ist. Nichts desto Trotz vielen Dank für dein Feedback.

[rekorboi]

@Grizzelbee
Vielen Dank für Deine schnelle und ausführliche Antwort!

Jaaaa - das ist ein Problem von Google translate

Schöne neue Welt. Evtl. könnte die Kontextsensitivität einen Workaround ermöglichen (Google übersetzt „minutes“ -> „Protokoll“, „unit: minutes“ -> „Einheit: Minuten“), aber in der Thematik stecke ich in keiner Weise drin. Und Du hast an dieser Stelle anscheinend schon genug gelitten…

Das kann ich mir ehrlich gesagt nicht vorstellen. Es ist zwar so, dass bei SSE tatsächlich alle 5 Sekunden eine PING Nachricht vom Server reinkommt, die aktualisiert aber nur eine timestamp Variable im Adapter und fertig.

Auch ich favorisiere SSE, aber mir war aufgefallen, dass VIS auf allen Clients auf einmal quasi unbedienbar wurde (absolut ungewöhnlich), als zwei Miele-Geräte liefen. Die Pi-Auslastung und damit die VIS-Probleme konnte ich mit dem Aktivieren/Deaktivieren der Instanz reproduzierbar entscheidend beeinflussen.

Ich bin der Sache nun noch einmal nachgegangen und denke, dass ich die Ursache einkreisen konnte. Die Last durch den Adapter korreliert im SSE-Modus mit dem Zustand des Gerätes: Ist die Solltemperatur erreicht, so gibt es keine Auffälligkeiten. Befindet sich das Gerät in einer Aufheiz- oder Abkühlphase, so steigt die Last deutlich an. Das Loggen der Solltemperatur zeigt in diesem Fall die kontinuierliche Änderung der Werte mit sehr hoher Frequenz (Beispiel Wärmschublade: Werte mit 2 Nachkommastellen und Änderungen im Abstand von teilweise < 500 ms). Je mehr Geräte gleichzeitig aufheizen etc., desto massiver steigt der Traffic. Potenziert wird das Ganze ggf. über Skripte, die auf Änderung der Datenpunkte triggern (ist aber kein Skript-Effekt, der starke Lastanstieg zeigt sich auch ohne jegliches aktives Skript).

Hat sich an der SSE-Aktualisierungsfrequenz bei laufenden Geräten etwas geändert? Bisher hatte ich auch mit SSE nie Auffälligkeiten (bis auf die ausbleibenden Aktualisierungen). Allerdings hat sich die Anzahl der Geräte vor einigen Wochen erhöht, was ebenso ein Rolle spielen mag.

Vielleicht wäre eine weitere Konfigurationsoption ein Ausweg: Ein minimaler Zeitabstand, nach dem neu eintreffende Werte prozessiert, d.h. in die Datenpunkte überführt werden (z.B. in ms bzw. s mit 0 als Minimum, vergl. beispielsweise influxdb-Adapter „minimale Differenz“/„Aufzeichnung zeitlich blockieren“ vs. „Debounce“). Innerhalb der „Totzeit“ werden Aktualisierungen ignoriert, wobei Aktualisierungsintervalle im Sekundenbereich für mich mehr als ausreichend wären. Allerdings könnte ein zu einfaches Vorgehen mit dem SSE-Konzept kollidieren (da stecke ich ebenfalls nicht tief genug drin) und zwar mit der Folge, dass nur einmalig/wenige Male gesendete Änderungen verloren gehen könnten (z.B. Gerät wird innerhalb der Totzeit ausgeschaltet), d.h. die jeweils letzten Werte müssten innerhalb der Totzeit ressourcenschonend gepuffert werden – Du wirst es besser beurteilen können. Evtl. müsste man sogar selektiv filtern, was es natürlich schnell komplexer werden ließe. Oder die Miele-API bietet nativ einen einfachen Ausweg? Aber wahrscheinlich hast Du ja noch ganz andere Ideen.

[Grizzelbee]

@rekorboi sagte in MieleCloudService Adapter:

unit: minutes“ -> „Einheit:

Ich gucke mir das mal an. Vielleicht ist das ein gangbarer Weg. danke für den Tipp.

Je mehr Geräte gleichzeitig aufheizen etc., desto massiver steigt der Traffic.

Okay. Das klingt nachvollziehbar und vor allem doof. Mein Server ist leistungsstark genug um das abzufedern. Deshalb wirkt sich das bei mir nicht aus und ich merke das nicht. Eine Art "Entprellen" ergibt da sicher Sinn. Ist aber eine Sache über die ich bisschen nachdenken und brüten muss. Es wäre ja doof, wenn ich deswegen immer ausgerechnet die letzte Nachricht mit dem finalen Status verwerfen würde. Das schreit nach einer Art "Newtons Wiege" für die Nachrichten. Die API selbst hilft da leider nicht. Die schickt plump was sie hat, weil sie davon ausgeht das die Clients das verarbeiten können.

[Grizzelbee]

@rekorboi

Ich habe gerade etwas gemacht, was ich sonst nie mache: Der git Master-Branch entspricht gerade dem aktuellen Entwicklungsstand und nicht der letzten Version. Warum ich das schreibe? Weil:

• (grizzelbee) New: Added new config option "delayed processing" to prevent overload on less powerful hardware
• (grizzelbee) Fix: changed actions info message during polling to log level debug
• (grizzelbee) Fix: Fixed german translation bug "minutes" -> "protokoll" (thanks to rekorboi)

Ich dort gerade mal die Dinge, die dir aufgefallen waren eingebaut/gefixed.
Wäre schön, wenn Du mal diese Verison von git installierst und testest ob das so funktioniert wie gedacht und gewünscht.

[rekorboi]

@Grizzelbee
Kurz getestet, auf die Schnelle:

New: Added new config option "delayed processing" to prevent overload on less powerful hardware

Scheint zu funktionieren, Aktualisierungsintervall passt und deutlich reduzierte Last (bisher sind mir keine verlorenen „finalen“ Zustände aufgefallen, werde es beobachten).

Fix: changed actions info message during polling to log level debug

Die Meldungen tauchen nicht mehr auf.

Fix: Fixed german translation bug "minutes" -> "protokoll" (thanks to rekorboi)

Sieht gut aus.

[Grizzelbee]

@rekorboi sagte in MieleCloudService Adapter:

New: Added new config option "delayed processing" to prevent overload on less powerful hardware

Scheint zu funktionieren, Aktualisierungsintervall passt und deutlich reduzierte Last (bisher sind mir keine verlorenen „finalen“ Zustände aufgefallen, werde es beobachten).

Verlorene finale Zustände sollte es auch nicht geben. Ich verwerfe nur das was innerhalb des Intervalls - also in zu kurzer Zeit ankommt. Die letzte Nachricht wird dabei aber immer gepuffert und spätestens nach Ablauf des Intervalls verarbeitet.
Beispiel: Wenn in einer Sekunde 5 Nachrichten reinkommen, wird die erste verarbeitet, die Nachrichten 2-4 verworfen und die fünfte gepuffert bis das eingestelle Intervall abgelaufen ist und dann verarbeitet. Damit wird nur noch eine Nachricht pro eingestelltem Intervall verarbeitet.

Ich mache das dann in Kürze mal als Version fertig.

[michael 1975]

@grizzelbee ist es möglich das miele gestern was an der API gemacht stand in der App und jetzt will mein Adapter nicht mehr. Kann leider auch nicht viel probieren da ich im Urlaub bin

[oxident]

@Grizzelbee Bei mir gleiches Problem wie bei @michael-1975: Seit Mitternacht kommt nur noch

host.iobroker
2022-06-11 08:45:19.413	error	instance system.adapter.mielecloudservice.0 terminated by request of the instance itself and will not be restarted, before user restarts it.

mielecloudservice.0
2022-06-11 08:45:18.748	error	IMPORTANT!! Mask/Delete your credentials when posting your log online!

mielecloudservice.0
2022-06-11 08:45:18.748	warn	options country: [de-DE]

mielecloudservice.0
2022-06-11 08:45:18.747	warn	options Client_Secret: [2c5PYEiWKdB7fNeIywnWyO1uiHDLBQoW]

mielecloudservice.0
2022-06-11 08:45:18.747	warn	options Client_ID: [8f1b196b-c342-4140-b0c8-153c257e8119]

mielecloudservice.0
2022-06-11 08:45:18.746	warn	options Miele_Password: [XXX]

mielecloudservice.0
2022-06-11 08:45:18.746	warn	options Miele_account: [XXX]

mielecloudservice.0
2022-06-11 08:45:18.745	warn	Credentials used for login:

mielecloudservice.0
2022-06-11 08:45:18.741	error	Error: Unable to authenticate user! Your credentials seem to be invalid. Please double check and fix them.

Habe sämtliche Zugangsdaten im Adapter neu eingetragen ... bringt aber nix.

[Grizzelbee]

@oxident , @michael-1975

Hmmm. Das kann ich nicht bestätigen. Bei mir läuft alles. In der App und auf der Homepage finde ich keine Hinweise auf irgend etwas.

Habe zum Test auch den Adapter mal neu gestartet.
Der loggt sich sofort problemlos wieder ein. Keine Ahnung was da los sein könnte.
Welche Version des Adapters habt ihr laufen?