Autor Thema: Problem mit NOTIFYDEV-Filter  (Gelesen 540 mal)

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Problem mit NOTIFYDEV-Filter
« am: 22 September 2019, 11:40:45 »
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:

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:

Zitat
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.
« Letzte Änderung: 22 September 2019, 11:43:00 von Damian »
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20983
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #1 am: 22 September 2019, 12:09:38 »
Zitat
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.

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #2 am: 22 September 2019, 12:14:17 »
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.
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #3 am: 22 September 2019, 13:25:40 »
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:


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

Meine Anpassung:

  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
« Letzte Änderung: 22 September 2019, 13:40:45 von Damian »
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #4 am: 22 September 2019, 17:20:33 »
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.
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20983
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #5 am: 22 September 2019, 17:41:57 »
$re in notifyRegexpChanged ist nicht das, was danach in NOTIFYDEV landet, sondern ein (beschraenkter) Regexp, wie z.Bsp.
dev1|dev2:event2|(dev3)|(dev4:event4)wobei devX .* oder .+ am Ende enthalten darf, und eventX bis auf | alles an Regexp Sonderzeichen enthalten kann.


Zitat
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,....


Zitat
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.

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #6 am: 22 September 2019, 18:01:39 »
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.

Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #7 am: 23 September 2019, 17:43:27 »
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?

Zitat
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.

Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20983
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #8 am: 23 September 2019, 17:53:35 »
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.

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #9 am: 23 September 2019, 18:03:15 »
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.
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6635
Antw:Problem mit NOTIFYDEV-Filter
« Antwort #10 am: 25 September 2019, 22:56:57 »
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.
« Letzte Änderung: 25 September 2019, 22:58:29 von Damian »
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

 

decade-submarginal