MieleCloudService Adapter
-
@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:
- Die Abfrageintervalleinheit-Dropdown-Liste bietet nicht die Optionen Sekunden/Minuten sondern Sekunden/Protokoll.
- 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.
-
@rekorboi
Viele Dank für die Infos! Da ich selbst das polling nicht einsetze, ist mir nicht allers davon bewusst.- 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.
-
@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.
-
@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. -
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. -
@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.
-
@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.
-
@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
-
@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.
-
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? -
Gerade nochmal probiert jetzt ging es wieder keine Ahnung warum vielleicht ein kleiner schluckauf
-
@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.
-
@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? -
@grizzelbee bei mir auch
-
@Grizzelbee Hmm, hier nach Neustart auch wieder ok. Ebenfalls 6.3.2 mit SSE. Betraf vielleicht nur manche Nutzerkonten.
-
6.2.2 mit SSE
-
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.2host.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 -
Hat niemand eine Idee ?
Jetzt habe ich endlich eine Miele-Maschine, die das kann und jetzt tut es der Adapter bei mir nicht
-
@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.ä.?
-
@schweiger2 Seit dem letzten Update muss man das Passwort und Secret neu eingeben.
@Grizzelbee : Hast Du da die Verschlüsselung geändert ?
