MieleCloudService Adapter

[Grizzelbee]

@oxident sagte in MieleCloudService Adapter:

Müsste vielleicht noch im package.json hinterlegt werden

Stimmt! Habe ich übersehen. Danke für den Hinweis. Habe ich soeben gefixed.

[MarkA]

@grizzelbee

Hallo,

Version 6.1.0.

Bei meiner Dunstabzugshaube ist beim Licht der Status "false" wenn es AN ist, und "true", wenn es aus ist.

mielecloudservice.0.mac-000000SERIAL.ACTIONS.Light

Beim "alles Aus" Button (jetzt auch true/false) muss jetzt einmal auf false und dann true geschaltet werden, damit der Lüfter und das Licht gemeinsam ausgehen.

mielecloudservice.0.mac-000000SERIAL.ACTIONS.Stop

Gruß Mark

[Grizzelbee]

@marka sagte in MieleCloudService Adapter:

Bei meiner Dunstabzugshaube ist beim Licht der Status "false" wenn es AN ist, und "true", wenn es aus ist.

Hmm.. Komisch. Bei meiner Kaffeemaschine passt das. Gucke ich mir aber noch einmal genauer an.
Schreibst und schickst Du mir dafür bitte ein Debug-Log? Dann wird das etwas greifbarer - genau wie die zweite Sache. Hat eigentlich beides vorher funktioniert (also mit der 5er Version)?

[oxident]

@marka said in MieleCloudService Adapter:

@grizzelbee

Hallo,

Version 6.1.0.

Bei meiner Dunstabzugshaube ist beim Licht der Status "false" wenn es AN ist, und "true", wenn es aus ist.

mielecloudservice.0.mac-000000SERIAL.ACTIONS.Light

Ist bei meiner Kaffeemaschine (CVA7845) auch so. Hab dafür ein Issue geöffnet.
Bei der 5er Version lief das korrekt.

Ansonsten klappt alles prima. Danke für Deinen Einsatz @Grizzelbee !

[Grizzelbee]

@oxident sagte in MieleCloudService Adapter:

Ist bei meiner Kaffeemaschine (CVA7845) auch so. Hab dafür ein Issue geöffnet.

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

Das Problem mit dem Lichtschalter kann ich nun doch bestätigen - habe ich für V6.1.2 auch schon gefixed. Das war nur eine Kleinigkeit.

@marka sagte in MieleCloudService Adapter:

Beim "alles Aus" Button (jetzt auch true/false) muss jetzt einmal auf false und dann true geschaltet werden, damit der Lüfter und das Licht gemeinsam ausgehen.
mielecloudservice.0.mac-000000SERIAL.ACTIONS.Stop

Das hier kann ich aber noch nicht nachvollziehen. ACTIONS.Stop ist kein true/false Schalter, sondern ein Button. Die werden grundsätzlich nur im Admin geklickt bzw. in Scripten, etc mit true beschrieben. Klingt als müssten wir da noch ein bisschen forschen. Also ob da etwas defekt ist und wenn ja was.

[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

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