95_Alarm.pm: Performance bei dynamisch erzeugten at-Devices

[Flachzange]

Hallo pah,

ich mache hier einen neuen Thread auf, da der bisherige Hauptthread zum Alarm-Modul geschlossen ist.

Bei einer Performance-Analyse ist mir aufgefallen, dass die vom Alarm-Modul dynamisch erzeugten at bei größeren Aktionsketten erhebliche Laufzeit verursachen.

Zur Größenordnung: Das Alarm-Modul verwaltet bei mir 41 (bereits gruppierte) Sensoren und 9 Aktoren über 8 Alarmlevel; Level 2 allein umfasst 12 Sensoren und 8 Aktoren.

Bei Level 2 lag alarm2.on.N dadurch bei rund 10 s. Da die Verarbeitung synchron im FHEM-Mainloop erfolgt, ist das auch praktisch deutlich spürbar und ich konnte mir das teilweise "merkwürdige" Verhalten meiner EnOcean-Geräte nach dem Raised oder Disarmed nie erklären. Nun ist es nachvollziehbar.

Ich habe jetzt zunächst die erzeugten at auf define -temporary umgestellt. Das reduziert die Laufzeit bereits deutlich; 9 solcher Definitionen benötigen bei mir aber immer noch ca. 1,7 s.

Testweise habe ich deshalb die verzögerten Aktionen auf named sleep umgestellt. Der Start einer vergleichbaren Kette benötigt damit nur noch < 1 ms. Dasselbe habe ich für arm.dly, autocancel und disarm.T umgesetzt. Bisher funktioniert das einschließlich Abbruch der Aktionen problemlos.

Spricht aus Deiner Sicht etwas dagegen, die dynamischen at im Modul generell durch named sleep zu ersetzen? Keine Ahnung, ob du überhaupt noch Anpassungen machst / machen möchtest.

Falls interessant, kann ich die Änderungen gerne zur Verfügung stellen.

Grüße
Chris

[rudolfkoenig]

Ich habe jetzt zunächst die erzeugten at auf define -temporary umgestellt. Das reduziert die Laufzeit bereits deutlich; 9 solcher Definitionen benötigen bei mir aber immer noch ca. 1,7 s.

Soweit ich sehe, bewirkt -temporary fuer dieses Problem nur, dass kein "global DEFINED" Event generiert wird.
Ich wuerde (auch?) untersuchen, wer fuer die Verzoegerung bei diesem Event verantwortlich ist.

[Flachzange]

Soweit ich sehe, bewirkt -temporary fuer dieses Problem nur, dass kein "global DEFINED" Event generiert wird.

Richtig und dieses global DEFINED ist bei mir nicht trivial. Einen unmittelbaren Verursacher konnte ich zunächst nicht ausmachen und habe es auf meine vergleichsweise umfangreiche Installation geschoben, daher habe ich geschaut, wie man das Anlegen der ats optimieren kann. Durch die Vielzahl der (temporären) ats in meinem Alarm Device blockiert da eben immer ziemlich viel. Aber du hast natürlich Recht, dass man sich eigentlich auch global DEFINED anschauen muss.

Ich habe deine Antwort aber jetzt nochmal zum Anlass genommen, um es mit der KI zu analysieren. Das Ergebnis ist interessant.

Bei einem normalen define wird der Notify-Hash ungültig und beim anschließenden global DEFINED neu aufgebaut. Dabei haben sich bei mir zwei größere Ursachen gezeigt:

330 EnOcean-Devices hatten kein NOTIFYDEV und werden damit allen Event-Quellen zugordnet. Dadurch ist createNtfyHash() vermutlich unnötig teuer. Nach Einschränkung von 311 Devices auf global sank dessen Laufzeit von ca. 208 auf 108 ms. Nachhaltig sollte EnOcean vermutlich sein NOTIFYDEV selbst aus global und den tatsächlich benötigten Referenz-/Self-Devices aufbauen.

Bei readingsProxy lag das Problem darin, dass auf jedes DEFINED <device> mit einem Neuaufbau reagiert wurde, sobald das neu definierte Device nicht bereits in PROXIES enthalten war. Dadurch wurden bei jedem neu angelegten at alle meine 14 readingsProxy neu aufgebaut, obwohl das neue at mit ihnen nichts zu tun hatte. Nachhaltig sollte readingsProxy bei DEFINED deshalb nur dann readingsProxy_updateDevices() aufrufen, wenn das neu definierte Device tatsächlich in der eigenen DEF referenziert ist und bisher noch nicht verfügbar war. Nach dieser Änderung sank mein "global DEFINED"-Test von ca. 479 auf 74 ms.

Hoffe das ist so nachvollziehbar...