Problem mit NOTIFYDEV-Filter

[Damian]

Ich habe das DOIF-Modul auf NOTIFYDEV-Filter umgestellt.

Nun stellt sich das Problem dar, dass unmittelbar nach der Definition nur von global das modify-Event ankommt, aber keine anderen Events ankommen, erst wenn von anderen Modulen Events erzeugt werden, kommen auch die zum Filter passenden an.

So sieht meine Testumgebung aus:

Code Auswählen Erweitern

DOIF_Notify($$)
{
  my ($hash, $dev) = @_;
  my $pn = $hash->{NAME};
  #return "" if($attr{$pn} && $attr{$pn}{disable});
  my $device;
  my $reading;
  my $internal;
  my $ret;
  my $err;
  my $eventa;
  my $eventas;

  $eventa = deviceEvents($dev, AttrVal($pn, "addStateEvent", 0));
  $eventas = deviceEvents($dev, 1);
  Log3 ($pn,1,"---------- eventa: @{$eventa}") if ($pn eq "Licht_Garage");
...

List der Definition:

Internals:
   DEF        ([TasterLichtGarage]) (set bla on)DOELSE
   MODEL      FHEM
   NAME       Licht_Garage
   NOTIFYDEV  global,TasterLichtGarage
   NR         671
   NTFY_ORDER 50-Licht_Garage
   STATE      cmd_1
   TYPE       DOIF
...

getriggert wird zwei mal mit:

trigger TasterLichtGarage on

Eventmonitor:

2019-09-22 11:34:48.185 DOIF Licht_Garage mode: enabled
2019-09-22 11:34:48.191 Global global MODIFIED Licht_Garage
2019-09-22 11:34:51.240 DOIF S_niedriger 21.4 °C
2019-09-22 11:34:51.261 CUL_WS Aussensensor T: 21.4  H: 53.9
2019-09-22 11:34:51.261 CUL_WS Aussensensor temperature: 21.4
2019-09-22 11:34:51.261 CUL_WS Aussensensor humidity: 53.9
2019-09-22 11:34:51.261 CUL_WS Aussensensor dewpoint: 11.7
2019-09-22 11:34:52.776 dummy TasterLichtGarage on
2019-09-22 11:34:57.749 CUL_EM CUL_GZ CNT: 242 CUM: 3980.160  5MIN: 0.000  TOP: 0.000
2019-09-22 11:34:57.749 CUL_EM CUL_GZ current_cnt: 0
2019-09-22 11:34:57.749 CUL_EM CUL_GZ seqno: 242
2019-09-22 11:34:57.749 CUL_EM CUL_GZ total: 3980.16
2019-09-22 11:34:57.749 CUL_EM CUL_GZ peak: 0
2019-09-22 11:34:57.749 CUL_EM CUL_GZ peak_cnt: 1490
2019-09-22 11:34:57.749 CUL_EM CUL_GZ total_cnt: 1490
2019-09-22 11:34:57.749 CUL_EM CUL_GZ current: 0
2019-09-22 11:34:57.749 CUL_EM CUL_GZ tsecs: 1569144897.6798
2019-09-22 11:34:57.749 CUL_EM CUL_GZ RAW: CNT: 242 CUM: 1490  5MIN: 0  TOP: 1490
2019-09-22 11:35:00.279 dummy bla on
2019-09-22 11:35:00.280 DOIF Licht_Garage cmd_nr: 1
2019-09-22 11:35:00.280 DOIF Licht_Garage cmd: 1
2019-09-22 11:35:00.280 DOIF Licht_Garage cmd_event: TasterLichtGarage
2019-09-22 11:35:00.280 DOIF Licht_Garage cmd_1
2019-09-22 11:35:00.282 dummy TasterLichtGarage on


Logausgabe:


2019.09.22 11:34:48.187 1: ---------- eventa: MODIFIED Licht_Garage
2019.09.22 11:35:00.268 1: ---------- eventa: on


Der erste Trigger unmittelbar nach defmod:

2019-09-22 11:34:52.776 dummy TasterLichtGarage on

kommt im Modul nicht an.

[rudolfkoenig]

Ich habe das DOIF-Modul auf NOTIFYDEV-Filter umgestellt.

Wie genau?
Setzen der Variable NOTIFYDEV reicht nicht, weil das ein Aktualisieren der eigentlich verwendeten ntfyHash nicht ausloest.
Der dafuer vorgesehen Weg ist notifyRegexpChanged($hash, $re) aufzurufen, was NOTIFYDEV setzt, und die Aktualisierung ausloest.

[Damian]

Wie genau?
Setzen der Variable NOTIFYDEV reicht nicht, weil das ein Aktualisieren der eigentlich verwendeten ntfyHash nicht ausloest.
Der dafuer vorgesehen Weg ist notifyRegexpChanged($hash, $re) aufzurufen, was NOTIFYDEV setzt, und die Aktualisierung ausloest.

Super, Danke, Dann werde ich es gleich einbauen.

[Damian]

Jetzt muss ich doch mal fragen wie ich  notifyRegexpChanged($hash, $re); anwenden muss.

Bisher hatte ich einfach eine kommagetrennte Liste in NOTIFYDEV wie folgt abgelegt, was auch (wenn auch nur zeitversetzt) funktionierte:

Code Auswählen Erweitern

$hash->{NOTIFYDEV}.=",$regdev" if ($hash->{NOTIFYDEV}!~/,$regdev(,|$)/);


Meine Anpassung:

Code Auswählen Erweitern

  my $reg=$hash->{NOTIFYDEV};
  if ($reg!~/,$regdev(,|$)/) {
    $reg.=",$regdev";
    notifyRegexpChanged($hash, $reg);
  }


löscht offenbar den NOTIFYDEV-Eintrag

Edit: NOTIFYDEV wurde zunächst mit "global" vorbelegt

[Damian]

Ich habe mir jetzt den Sourcecode zu notifyRegexpChanged angeschaut und musste feststellen, dass die Einschränkungen für mein Modul zu stark sind.

Ich will eigentlich nur Devices per Regex einschränken und noch nicht mal Events (die behandle ich im Modul selbst)

Aber eine einfache Regex für z.B: ".*Fenster" funktioniert schon nicht. Gibt´s hierfür irgendwelche Bedenken zu Performance bei der Auswertung?

Als Hack lösche ich jetzt selbst den hash mit %ntfyHash = (); und kümmere mich weiterhin selbst um den Aufbau von NOTIFYDEV ohne notifyRegexpChanged aufzurufen.

Alternativ müsste ich auf NOTIFYDEV verzichten und wie bisher selbst filtern, aber vielleicht ist dann die Gesamtlast des Systems geringer auch wenn apptime für das jeweilige Modul dann wieder ungünstiger ausfällt.

[rudolfkoenig]

$re in notifyRegexpChanged ist nicht das, was danach in NOTIFYDEV landet, sondern ein (beschraenkter) Regexp, wie z.Bsp.

Code Auswählen Erweitern

dev1|dev2:event2|(dev3)|(dev4:event4)wobei devX .* oder .+ am Ende enthalten darf, und eventX bis auf | alles an Regexp Sonderzeichen enthalten kann.

Aber eine einfache Regex für z.B: ".*Fenster" funktioniert schon nicht. Gibt´s hierfür irgendwelche Bedenken zu Performance bei der Auswertung?

Ich meine wir waren damals nicht in der Lage, alle moeglichen Regexp-Ausdruecke abzudecken, und haben die Moeglichkeiten deswegen eingeschraenkt. Es leuchtet mir aber (noch?) nicht ein, wieso dev1|dev2|... aufwendiger zu bauen ist als dev1,dev2,....

Alternativ müsste ich auf NOTIFYDEV verzichten und wie bisher selbst filtern, aber vielleicht ist dann die Gesamtlast des Systems geringer auch wenn apptime für das jeweilige Modul dann wieder ungünstiger ausfällt.

Ohne NOTIFYDEV wird die NotifyFn jeder Instanz bei jedem Event aufgerufen, der Zusatzaufwand ist (Anzahl der Instanzen minus 1) mal Ausfuehrungsdauer im NotifyFn. Letzteres kann der Modulautor beeinflussen, Ersteres weniger.

[Damian]

Es ist ganz einfach:

$hash->{NOTIFYDEV}="dev1,.*dev2.*,dev3" kann ich selber bauen und der Filter funktioniert.

notifyRegexpChanged($hash,"dev1|.*dev2.*|dev3") funktioniert nicht.

Wenn du sagst "dev1" im $hash->{NOTIFYDEV} zu filtern ist genauso aufwändig wie z. B. ".*dev" dann bleibe ich bei meinem Hack.

[Damian]

Es häufen sich jetzt Meldungen, dass DOIF (mit NOTIFYDEV) nicht mehr auf Events von FHEM2FHEM reagieren würde. Kannst du meine Vermutung bestätigen?

Was ich jetzt verstanden habe ist, dass Events vom NOTIFYDEV-Filter geschluckt werden, wenn kein passendes Device existiert. Das sind aber Dinge außerhalb von DOIF. Dann dürfte auch ein notify damit nicht klar kommen, weil es ja auch den NOTFYDEV-Filter nutzt.

[rudolfkoenig]

Ich gehe davon aus, dass das bei Modulen, die notifyRegexpChanged verwenden (und nicht direkt NOTIFYDEV setzen), kein Problem ist.
Die Funktion setzt nur dann NOTIFYDEV, falls alle Elemente bekannte Geraete sind.

[Damian]

Ich gehe davon aus, dass das bei Modulen, die notifyRegexpChanged verwenden (und nicht direkt NOTIFYDEV setzen), kein Problem ist.
Die Funktion setzt nur dann NOTIFYDEV, falls alle Elemente bekannte Geraete sind.

OK. Danke.

[Damian]

Nur zur Info:

Ich nutze jetzt einen eigenen Filter, falls über notifyRegexpChanged  NOTIFYDEV-Filter nicht gesetzt wird.

Schade nur, dass .*dev über notifyRegexpChanged nicht funktioniert, obwohl der Filter damit klar käme.