@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
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
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
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
Das Hinzufügen einer Wärmeschublade (Dish Warmer) führte zum Anlegen der Datenpunkte, die laut API-Dokumentation verfügbar sind. Der Swagger liefert jedoch sinnvolle Daten für sechs weitere Datenpunkte:
ProgramID, programPhase, remainingTime, targetTemperature, temperature, signalDoor.

Wäre es möglich, diese States auch im Adapter zur Verfügung zu stellen? Mit dem für den Spüler undokumentierten Datenpunkt „Light“ hatte Vergleichbares damals problemlos geklappt.

Zudem sollte sich die targetTemperature der Schublade anscheinend als Action setzen lassen.

PS: Diesmal dürfte das Anliegen etwas greifbarer sein als die Problematik der ausbleibenden Aktualisierungen - kurzes Update dazu: Das Ganze scheint phasenweise aufzutreten, seit einigen Wochen läuft es wieder stabil (allerdings habe ich den täglichem Neustart per Skript noch nicht deaktiviert).

@Grizzelbee

Das Problem mit SignalDoor ist in der 5.0.3 behoben.

Danke, scheint geklappt zu haben, der Fehler ist in den letzten Wochen nicht wieder aufgetaucht.

Hinsichtlich der ausbleibenden Aktualisierungen gibt es bisher keine Besserung. Auch der Workaround mit einem Neustartintervall von 24 h führt bei mir zu keinem verlässlichen Betrieb. Ich könnte nun auf z.B. stündlichen Neustart eskalieren, das erscheint mir aber wenig zielführend.

Außer den Neustart-Meldungen gibt es keine Log-Einträge (Info) des Adapters, d.h. die von Dir erwähnten Reconnect-Warnings habe ich bisher noch nicht gesehen. Für die Unterscheidung „Gerät aus“ vs. „Events kommen nicht mehr an“ ist mir kein Kriterium bekannt. Zeitstempel helfen nur bei laufendem Gerät - gibt es Miele-seitig irgendwelche Optionen hinsichtlich Heartbeat/Watchdog etc.? Könnte ein periodisches Lebenszeichen des Adapters (SSE-Anforderung) an den Server helfen?

@Grizzelbee
Selbstverständlich unterstütze ich Dich gerne bei der Fehlereingrenzung.
Den http-error 400 von @jupzup sehe ich beim Neustart ebenfalls, danach läuft es dann ja zunächst. Ansonsten gibt es im Info-Log nur einen Eintrag (tauchte in den letzten 24 h zweimal auf):

2021-12-26 03:15:12.365 - info: mielecloudservice.0 (21091) undefined is not a valid state value for id "mielecloudservice.0.XXX.signalDoor"

Hast Du konkrete Input-Wünsche an uns?

@jupzup @Grizzelbee
Kann ich für V5.0.2 so bestätigen – seit dem Update auf die push/event-basierte Version werden die Datenpunkte ab einem gewissen Zeitpunkt nicht mehr aktualisiert. D.h. der Adapter ist grün, der DP „connected“ bleibt auf true aber es kommen keine Events mehr. Passiert sowohl wenn das Gerät (hier: Geschirrspüler) ausgeschaltet ist als auch mitten im Betrieb. Als Workaround hilft mir momentan ebenfalls ein Adapterneustart (danach kommen unverzüglich die aktuellen Daten/Events). @Gargano bezog sich hier wahrscheinlich auf das gleiche Verhalten.

Bisher kann ich keinen Auslöser bzw. kein Muster erkennen. Anfangs bin ich von einem Phänomen ausgegangen, das nach ein paar Tagen Laufzeit auftritt (timeout event subscription etc.). Nach dem aktuellen Bauchgefühl würde ich eher auf die Anzahl der Events tippen, d.h. je öfter die Maschine läuft, desto schneller werden die Datenpunkte nicht mehr aktualisiert. Kann aber eine statistische Fehlinterpretation sein, d.h. es fällt mir bei mehr Läufen einfach schneller auf. Momentan passiert es eher 1x am Tag (Weihnachten sei Dank ), es gab bereits den Fall des Adapterneustarts am Vormittag und des „Einfrierens“ der Datenpunkte noch am selben Abend.

@oliverio @Ritschy2000 Neuer, erfreulicher Stand: Habe das nach dem Update von 0.0.30 auf 1.0.0 aufgetretene Problem wahrscheinlich lösen können. Nach einer rssfeed-Deinstallation (Instanz/Adapter/Widget) und anschließender Neuinstallation (1.0.0) läuft es bisher stabil und unauffällig - warum auch immer.

Über eins bin ich allerdings bei der Neukonfiguration gestolpert:
Die Aktualisierung wird dem README folgend noch immer in Minuten konfiguriert, richtig? Oder gibt es eine Änderung auf Sekunden (s. Post #437)? Vielleicht wäre ein Hinweis auf die Einheit am Eingabefeld hilfreich.
Mein System lässt jetzt anscheinend nur noch 60 min als minimales Refresh-Intervall zu. Welche Gründe sprechen für diese Begrenzung? 60 s kämen mir plausibler vor, da z.B. ein Intervall von 1 h für die Anzeige von Eilmeldungen dem „Eil“ nicht wirklich gerecht wird. Bei mir lief v0.0.30 mit einem 5 min Intervall absolut stabil. Die Balance zwischen Aktualität und Ressourcennutzung/Traffic etc. könnte ja jeder für sich selbst austarieren.

@oliverio @Ritschy2000
Server:

• Pi 4 Model B Rev 1.1 (4 GB)
• Raspberry Pi OS Buster
• Js-Controller 3.3.18
• Node.JS 12.22.6
• NPM 6.14.15
• VIS 1.4.5
• Web 3.4.9

Clients:

• Pi 3 Model B Rev 1.2
• Raspberry Pi OS Buster
• Chromium 92.0.4515.98

Allerdings glaube ich nicht, dass es an den Pi-Clients liegt, sie dürften nach aktuellen Beobachtungen lediglich das schwächste Glied sein. Auch ein Versuch mit Firefox auf einem Win10-PC (32 GB) zeigte vergleichbare Probleme, wenn der rss-Adapter aktiv war: Als die Pi-Clients den Effekt nach ca. 1,5 h zeigten, kam es beim Versuch eines View-Wechsels am PC zu der Meldung "Diese Seite verlangsamt Firefox. Halten Sie die Seite an, um den Browser zu beschleunigen" und einem Hängen des VIS-Tabs für ca. 1 min. (danach lief es wieder für einige Minuten bis zum nächsten Hänger). Die Konsole hat leider nichts hergegeben, z.B. hing auch die Laufzeitanalyse. Während des Hängens sorgte Firefox für eine 99%-Auslastung des PC-Arbeitsspeichers (& ca. 13% CPU). Der einzige Konsolenfehler, den ich generieren kann (egal ob rssfeed-Adapter aktiv/inaktiv), ist unabhängig vom Einfrieren und ein 404er für „…/vis/adapter/rssfeed/words.js“.

Auf den Pi-Clients ist ebenfalls ein stetiger Anstieg der Speicherbelegung und der CPU-Auslastung zu beobachten, bis der Effekt auftritt. Zudem zeigt auch der Server eine Auffälligkeit: Während der Firefox- & Chromium-Hänger wurde der Swap-Speicher genutzt, was im Normalbetrieb nicht vorkommt (habe keine Prozessinfos, da ich es erst im Nachhinein über die Swap-Zeitspur gesehen habe).

Mit deaktiviertem rssfeed-Adapter kam es die Woche über zu keinerlei Aussetzern.

Hoffe, die Infos helfen beim Eingrenzen – danke für den hilfreichen Adapter!