MieleCloudService Adapter

[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?

[michael 1975]

Gerade nochmal probiert jetzt ging es wieder keine Ahnung warum vielleicht ein kleiner schluckauf

[stan23]

@oxident sagte in MieleCloudService Adapter:

@Grizzelbee Bei mir gleiches Problem wie bei @michael-1975

Bei mir auch, und jetzt geht es nach einem weiteren Adapter-Neustart wieder.

[Grizzelbee]

@stan23 , @oxident , @michael-1975

Klingt irgendwie komisch. Lasst uns mal nach Gemeinsamkeiten suchen.
Bei mir läuft der Adapter V6.3.2 mit SSE.
Was läuft bei euch?

[michael 1975]

@grizzelbee bei mir auch

[oxident]

@Grizzelbee Hmm, hier nach Neustart auch wieder ok. Ebenfalls 6.3.2 mit SSE. Betraf vielleicht nur manche Nutzerkonten.

[stan23]

6.2.2 mit SSE

[schweiger2]

Hallo zusammen,

kleines Problemchen mit dem MieleCloudService Adapter: der Adapter bleibt rot, sowohl nach Restart als auch Neustart wie bei dem Post etwas weiter oben.

Die Fehlermeldungen deuten für mich auf ein Login-Problem hin, aber meine Login-Daten habe ich mehrfach verifiziert (ich komme mit den Daten erfolgreich über die Miele-App in einen Account). Ich habe über die Developer-Seite die Client_ID und das Client_Secret neu angefordert und eingetragen.

Zu den Status in der Instanz:

• Verbunden mit Host
• Lebenszeichen
• Verbunden mit Gerät oder Dienst

Bei einem Restart bleiben alle Punkte rot, bei einem Anhalten des Adapters mit anschließendem Start werden die ersten beiden Punkte kurz grün, springen dann aber sofort auf rot. Anders als oben hilft mir ein Neustart der Instanz leider nicht.

Auch ein Neustart des ioBroker half nicht; die Fehlermeldungen blieben gleich.

Ich würde mich freuen, wenn ich hier weitere Hinweise bekommen kann. Dankeschön.

Releases:
ioBroker admin 6.1.9 auf Proxmox VM 7.2-5
node: v16.15.1
js-controller: 4.0.23
mielecloudservice: 6.3.2

host.iobroker 2022-07-03 10:49:33.424	info	Do not restart adapter system.adapter.mielecloudservice.0 because desired by instance
host.iobroker 2022-07-03 10:49:33.424	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-07-03 10:49:32.875	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Terminating adapter due to inability to authenticate.
mielecloudservice.0 2022-07-03 10:49:32.875	info	Login attempt wasn't successful. Connection retry in 31.343 Seconds.
mielecloudservice.0 2022-07-03 10:49:32.875	error	IMPORTANT!! Mask/Delete your credentials when posting your log online!
mielecloudservice.0 2022-07-03 10:49:32.875	warn	options country: [de-DE]
mielecloudservice.0 2022-07-03 10:49:32.875	warn	options Client_Secret: [xxx]
mielecloudservice.0 2022-07-03 10:49:32.875	warn	options Client_ID: [xxx]
mielecloudservice.0 2022-07-03 10:49:32.874	warn	options Miele_Password: [xxx]
mielecloudservice.0 2022-07-03 10:49:32.874	warn	options Miele_account: [xxxx.xxxx@xxxx.de]
mielecloudservice.0 2022-07-03 10:49:32.874	warn	Credentials used for login:
mielecloudservice.0 2022-07-03 10:49:32.874	error	Error: Unable to authenticate user! Your credentials seem to be invalid. Please double check and fix them.
mielecloudservice.0 2022-07-03 10:49:32.735	info	Login attempt #1 @Miele-API
mielecloudservice.0 2022-07-03 10:49:32.724	info	starting. Version 6.3.2 in /opt/iobroker/node_modules/iobroker.mielecloudservice, node: v16.15.1, js-controller: 4.0.23
host.iobroker 2022-07-03 10:49:31.957	info	instance system.adapter.mielecloudservice.0 started with pid 29400

[schweiger2]

Hat niemand eine Idee ?

Jetzt habe ich endlich eine Miele-Maschine, die das kann und jetzt tut es der Adapter bei mir nicht

[JoergH]

@schweiger2 Steht ja eindeutig da, dass er sich nicht einwählen kann. Also wird das Problem im Bereich Username/Passwort vermutlich liegen. Vielleicht Sonderzeichen o.ä.?

[Gargano]

@schweiger2 Seit dem letzten Update muss man das Passwort und Secret neu eingeben.
@Grizzelbee : Hast Du da die Verschlüsselung geändert ?

[Grizzelbee]

@gargano sagte in MieleCloudService Adapter:

Seit dem letzten Update muss man das Passwort und Secret neu eingeben.
@Grizzelbee : Hast Du da die Verschlüsselung geändert ?

Kommt jetzt drauf an, was für dich die letzte Version ist.
Ich habe gestern die v6.3.3 ins latest gegeben und: Ja! Da ist eine Änderung drin.
https://github.com/Grizzelbee/ioBroker.mielecloudservice/issues/269

Der Punkt ist der:
Man kann in den Meta-Daten eines Adapters konfigurieren ob bestimmte Felder automatisch ver- und entschlüsselt werden. Eben für Passwörter und ähnlich sensible Daten.
Das hat bisher für den Adapter nicht funktioniert und deshalb habe ich die von Hand ver- und entschlüsselt. Das hat bisher auch gut und problemlos funktioniert.

Aufgrund des github issues habe ich mir das mal oberflächlich angeschaut und festgestellt, dass wenn der Adapter die Passwörter beim Start "entschlüsselt" - sind sie danach tatsächlich verschlüsselt und der Login geht kaputt. Also habe ich die "Entschlüsselung" entfernt und die Passwörter sind korrekt.
Leider gibt es eine handvoll mögliche Ursachen für das Problem und mir fehlt die Zeit und der Kopf das in epischer Breite zu recherchieren. Also habe ich eine schnelle Lösung implementiert - die aber wohl leider erfordert das die Passwörter neu eingegeben werden müssen. Kann sogar sein, dass da noch einmal ein Fix nachkommt, der das dann nochmal erzwingt. Also aktuell vielleicht erst einmal mit bedacht updaten oder sogar diese Version überspringen.

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

rabbit6984 created this issue in Grizzelbee/ioBroker.mielecloudservice

closed Version 6.3.2 no Login to Miele API after editing password #269

Grizzelbee created this issue in Grizzelbee/ioBroker.mielecloudservice

closed Check en-/decryption of passwords #271