"structure" und erzeugte events - Probleme

[gandy]

Der Patch bezieht sich auf das Problem mit roßen structures (siehe etwas weiter oben, Beitrag http://forum.fhem.de/index.php/topic,28623.msg221222.html#msg221222), das mit dem Einbau des helpCache zwar schon deutlich entschärft, aber immer noch präsent ist.

Der Patch erlaubt, eine von zwei Alternativen zu wählen:

• Das bisherige Verhalten, hier wird unmittelbar mit Aufruf des "set <structureName>" für alle enthaltenen Clients die set Funktion aufgerufen. Je nach Größe der structure und Menge der pro Client ausgelösten Events kann das einige Sekunden in Anspruch nehmen, während der der FHEM Kern blockiert ist - und folglich alle anderen Devices. Bei schneller Abarbeitung mag das kein Problem sein, bei mir beobachte ich hier allerdings bei den größeren structures nach wie vor Zeiten von 6-8 Sekunden, die ich für kritisch erachte.
• Das neue Verhalten erlaubt, die set-Kommandos in den Clients nicht unmittelbar mit Aufruf des "set <structureName>" auszuführen, sondern jeden davon einzeln aus der Timerbehandlung heraus. Für N derart behandelte Kommandos sind also N Aufrufe der Timerfunktion erforderlich. Zwischen diesen Aufrufen hat der FHEM Kern die Möglichkeit, IOdevs, anstehende Timer und Events zu behandeln, was insgesamt die Ausführung aller set-Kommandos zwar nicht beschleunigt, aber für das System einen responsiveren Gesamteindruck beim Benutzer hinterlässt. Mir ist bewusst, dass FHEM kein Echtzeitsystem ist, und ich erhebe auch keinen Anspruch in dieser Richtung. Dennoch bin ich der Meinung, dass die Interaktion mit einem Heimautomationssystem ein wesentlicher Bestandteil desselben ist und finde, dass diese Interaktion auch während aufwenidgerer Aktionen "fluffig" bleiben sollte. Non-blocking Mechanismen ermöglichen das während potentiell langwieriger Geräte-Operationen, mit meinem Patch versuche ich, das für die structure zu ermöglichen.

Gibt das für Dich Sinn? Oder gibt es mit Bordmitteln elegantere Möglichkeiten, für mehr Responsivität bei großen structures zu sorgen? Ich hatte auch kurz mal darüber nachgedacht ob es Sinn hätte so eine Art "deferrer"-Modul zu schreiben, das ein set-Kommando ähnlich verzögert ausführen kann. Aber irgendwie scheue ich mich davor, Performance-Problemen mit noch mehr Resourcenbedarf zu begegnen.

Beste Grüße,
Andy.

[rudolfkoenig]

Ich habe dein Patch etwas modifiziert, getestet und eingecheckt. Haupt Unterschied (mAn) ist, dass bei einem structure-set evtl. noch im Puffer befindliche Befehle nicht geloescht werden. Waere aber gut, wenn Du es auch testen koenntest.

[gandy]

Hallo Rudi,

vielen Dank für Übernehmen und Überarbeiten des Patches! Testen kann ich erst heute abend, aber durchgesehen habe ich mir die eingecheckte Version. Deine Änderungen finde ich gut, nur eine Sache ist mir dabei aufgefallen: Die Queue darf m.E. nicht verwendet werden, wenn man auf den Rückgabe-Wert des set-Befehls angewiesen ist, wie das z.B. bei "set ?" der Fall ist. Siehe auch beigefügten Patchvorschlag zur aktuellen SVN Version. Ansonsten erwarte ich beim Testen keine Überaschungen, werde aber auf jeden Fall berichten.

Beste Grüße,
Andy.

[rudolfkoenig]

Danke fuer den Hinweis, habs gefixt und eingecheckt.

[gandy]

Hallo Rudi,

nach einigen Tagen Betrieb und diversen Tests kann ich sagen, die aktuelle Version von structure funktioniert zu meiner vollsten Zufriedenheit. Nochmals recht vielen Dank für deine Unterstützung!

Beste Grüße,
Andy.