HMCCU sparsames Notify einbauen

[martinp876]

bei einem neuerlichen Anflug von Notify-Aktionen ist mir sämtliches HMCCU negativ aufgefalle.
jede Entity in HMCCU and friends lässt sich über alle Events informieren.
in CUL_HM habe ich das vor einiger Zeit unterbunden (habe es auch nur zufällig erkannt)

Bei jeder Definition einer Entity sollte
notifyRegexpChanged($defs{$name},0,1);#disable the notification
ausgeführt werden. Dann informiert der Kernal nicht mehr.

Will man tatsächlich infomiert werden betrifft das typisch nie alle Elemente. Und man will nur von dedizierten entities informiert werden. Hier wird die Entity entName über "global" und "ent2" informiert
notifyRegexpChanged($defs{entName},"global|ent2",0);

Bei HMCCU ist das extrem störend da man viele Entites hat... wirklich negativ für die Operationelle Performance

[martinp876]

Ich habe einmal geprüft: Notifies brauchst du für global und HMCCUCHN sowie HMCCUDEV

Somit solltest du eine Funktion "updateNotifyEnrolement" erstellen in welcher du HMCCU zuweist.

Code Auswählen Erweitern

sub HMCCU_enroleNotify($){
   my $name = shift;
   my $eList = Listjoin("|",map{$_=~s/(.*): .*/$1/;$_}grep/: HMCCU/,map{"$_: ".$defs{$_}{TYPE}}keys %defs);
   $eList .= "|global";
   notifyRegexpChanged($defs{$name},$eList,0);
   }

und du musst das erneuern bei jedem rename/define/delete.
   

Code Auswählen Erweitern

foreach my $event (@{$events}) {
if ($devname eq 'global') {
# Global event
if ($event eq 'INITIALIZED') {
}
elsif ($init_done) {
     elsif ($event =~ /^(ATTR|DELETEATTR)/ ) {
     }
     elsif ($event =~ /^(RENAME|DEFINE|DELETE)/) {
                                HMCCU_enroleNotify($name);
     }
                         }





Müsste ein echter Performance-Gewin für fhem werden.

[zap]

Hast Du eine Doku-Seite, auf der es mehr Infos dazu gibt?

HMCCU registriert setzt ein Internal
"NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)"

genügt das nicht?

[Beta-User]

Die Lösung, die Martin für CUL_HM gefunden hat, ist afaik nirgends "als Muster" hinterlegt.

Vom Ergebnis her:

Code Auswählen Erweitern

list TYPE=CUL_HM NOTIFYDEV
liefert genau ein Device, das als "NotifyFn-Master" agiert und alle "globalen" Events "für alle" CUL_HM-Instanzen zentral abfängt und entsprechende Aktionen auslöst (z.B. IODev etc. aktualisieren).

Was an Coding in den einzelnen Instanzen erforderlich ist, hatte Martin ja grob umrissen. Man muss dann aber folgendes sicherstellen:
- es muss zu jedem Zeitpunkt sichergestellt werden, dass weiter ein "NotifyFn-Master" existiert (=> Übergabe, wenn er selbst gelöscht wird)
- wird die letzte Entity gelöscht, muss "global" wieder generell aktiviert werden, weil sonst rereadcfg in die Hose geht (das berücksichtigt die CUL_HM-svn-Version noch nicht).

[zap]

hmm, in einem anderen Beitrag von Rudolf habe ich gelesen, dass die Anzahl Devices in der Notify-Regexp auf 10 begrenzt ist.

ein

list TYPE=HMCCU NOTIFYDEV

liefert genau 1 (I/O) Device.

Würde es nicht genügen, in jeder Instanz von HMCCUDEV oder HMCCUCHN das Internal NOTIFYDEV entsprechend zu setzen?

[Beta-User]

Hmm, eine Begrenzung in NOTIFYDEV wäre mir neu, zumal ja auch devspec geht. (Das muss aber nichts heißen, wenn ich was nicht kenne).

Nach meinem Verständnis ging es Martin nicht um HMCCU (als IO-Device), sondern eher um die Clients, er nannte ausdrücklich

HMCCUCHN sowie HMCCUDEV

CUL_HM, das ich hier als Referenz genannt hatte, ist ja auch das Client-Device.

Würde es nicht genügen, in jeder Instanz von HMCCUDEV oder HMCCUCHN das Internal NOTIFYDEV entsprechend zu setzen?

Genau darum ging es m.E.. Der Vorschlag lief darauf hinaus, genau nur in (je?) einer Instanz überhaupt ein NOTIFYDEF zu setzen, _und_ in allen anderen NotifyFn() zu deaktivieren.

[zap]

Also aktuell ist es so: Ich setze im I/O Device (HMCCU) NOTIFYDEV auf global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)

Damit bekommt also das I/O Device alle Events des I/O Device (normalerweise genau 1) sowie die Events aller Client Devices vom Typ HMCCUDEV/CHN. Klar: Eigentlich braucht das I/O Device von den Client Devices nur einige wenige Events (konkret die ATTR Events).

Wenn ich es richtig verstanden habe, kann man in NOTIFYDEV nur auf einzelne Events filtern, wenn man den Devicename mit angibt. Eine Event-Filterangabe nur unter Angabe des TYPE ist nicht möglich. 

Hier kommt nun notifyRegexpChanged ins Spiel, das den entsprechenden String für NOTIFYDEV erzeugt und setzt. Aber das betrifft alles nur das I/O Device, denn: In HMCCUCHN und HMCCUDEV wird keine NotifyFn verwendet.

[Beta-User]

Hmm, dann hatte ich das vermutlich falsch verstanden.

Wobei es mir andererseits jetzt beim Lesen des letzten Posts etwas unklar ist, ob nicht die Reaktion auf jeweils alle DEV/CHN nicht irgendwie im Kreis herum ist, denn das Setzen von Attributen kann man ja in den Client-Devices abfangen und an das jeweilige IO weitergeben; diesen Aspekt auf Event-Basis zu lösen finde ich nicht einleuchtend/effizient, aber das muss nichts heißen.... (und wenn, sind das "global"-Events, die nicht speziell was mit den Clients zu tun haben).
Jedenfalls ist es nach meinem Verständnis nur so, dass man NOTIFYDEV auf Device (-regex)-Basis setzt und damit nur eingrenzen kann, für welche Devices man die NotifyFn() aufgerufen haben will. Alles weitere muss man modulintern lösen.

Vielleicht mag uns ja Martin noch näher erläutern, was wir jetzt ggf. übersehen haben. (In den Modulcode werde ich jetzt jedenfalls nicht schauen, ich hatte nur was geschrieben, weil ich zwischenzeitlich die Fallstricke innerhalb CUL_HM einigermaßen kenne).

[zap]

diesen Aspekt auf Event-Basis zu lösen finde ich nicht einleuchtend/effizient, aber das muss nichts heißen.... (und wenn, sind das "global"-Events, die nicht speziell was mit den Clients zu tun haben).

Ja, das ist richtig. Ich denke, so werde ich es auch lösen:
- Im I/O Device nehme ich HMCCUCHN und HMCCUDEV aus NOTIFYDEV raus. Damit bekommt das I/O Device nur noch die eigenen und die globalen Events
- Die Änderung von Attributen wird in den Client-Devices (HMCCUDEV, HMCCUCHN) direkt behandelt

So dürfte die Anzahl der Notifications drastisch nach unten gehen.

CUL_HM und HMCCU sind nur eingeschränkt vergleichbar, da bei HMCCU Client-Devices von I/O Device getrennt sind (separate Module)

Ticket: https://github.com/zapccu/HMCCU/issues/137

[Beta-User]

Hi zap,

Danke für die Rückmeldung. Ein paar Dinge habe ich allerdings in deiner Antwort nicht verstanden:

Damit bekommt das I/O Device nur noch die eigenen und die globalen Events

Wieso braucht das IO-Device die eigenen Events? Die generiert es doch selbst... (Es wäre m.E. dann effizienter, die Reaktion auch direkt in der Verarbeitung der eingehenden Daten zu vercoden).

CUL_HM und HMCCU sind nur eingeschränkt vergleichbar, da bei HMCCU Client-Devices von I/O Device getrennt sind (separate Module)

Nach meinem Verständnis ist CUL_HM "an sich" ein reines Client-Modul für die IO-Module CUL, TSCUL, HMLAN und HMUARTLGW, und damit m.E. eher mit den Modulen HMCCUDEV und HMCCUCHN vergleichbar... (Es gibt mit ACTIONDETECTOR und CCU-FHEM aber ein paar "spezielle" Varianten, die sich etwas anders verhalten als "dumme" Clients, aber das führt hier m.e. zu weit).

Aber vermutlich übersehe ich mal wieder was .

[zap]

Muss ich nochmal im Detail durchdenken. Man muss berücksichtigen, dass mehrere IOs möglich sind, wenn jemand mehrere CCUs hat (ich zB).

[Beta-User]

Muss ich nochmal im Detail durchdenken. Man muss berücksichtigen, dass mehrere IOs möglich sind, wenn jemand mehrere CCUs hat (ich zB).

Nach meinem Verständnis dürfte es völlig gleichgültig sein, wieviele CCU's vorhanden sind, falls die erste Aktion con HMCCU nach dem Verbinden die Abfrage der darauf angelernten Devices ist: Dann müßte es reichen, in allen Clients zu checken, ob IODev (Internal und ggf. Attribut) passend gesetzt sind => Korrektur falls nicht => Fisch geputzt.
Dann noch eine RenameFn() für HMCCU, die für diesen Fall das Attribut an den Clients berichtigt und dazu dann an den Clients ein Check bei Eingabe über FHEMWEB, ob "Unsinn" eingegeben wird => die Hauptlöcher sind dicht, ohne dass man (im laufenden Betrieb) überhaupt eine NotifyFn() irgendwo braucht...
Aber vermutlich übersehe ich bei dieser einfachen Denkweise irgendwas .

[zap]

Morgen gibt es ein Update im SVN. Damit bekommt dann das I/O Device keine Notifications mehr von den Client Devices.

[Beta-User]

Hmm, mir sind ein paar Dinge immer noch unklar (von sehr weit weg beobachtet):
- Warum handelst du das IODev-Update nicht von der Client-Seite her ab? Die Clients kennen doch ihr jeweiliges IO...
- das verbleibende "global"-Event ist "INITIALIZED" (REREADCFG fehlt. Mit Absicht?). Das könnte man durch einen InternalTimer direkt in DefFn() lösen
- Event auf HMCCU? Warum?
=> es ist an sich gar kein NotifyFn erforderlich, oder übersehe ich was?

[zap]

Ich aktualisiere die Readings in den Client Devices, wenn der Nutzer bestimmte Attribute ändert. Beispiel:

Der Nutzer setzt einen Readingfilter oder ändert das Format der  Readingnamen. Wenn man das Setzen der Attribute per X_Attr behandelt, ist es zu früh für ein Refresh der Readings, denn die Attribute werden erst gesetzt, wenn X_Attr undef zurückgibt.

Aber: FHEM schickt ein globales Event, wenn ein Attribut geändert wird. Und darüber löse ich dann den Refresh aus.

Und ja, HMCCU kann noch aus dem Notify Filter raus.