Auf Notify mit .* reagieren

[delMar]

Hallo,

ich arbeite an einem Modul, welches auf Events reagieren soll. Soweit kein Problem.
zB, wenn jemand an der Tür klingelt, dann ist das entsprechende devspec dafür FS20_Doorbell_.* (weil die Klingel 2 Tasten hat und die Obere _1 und die Untere _2 heißt).

Das Event kommt nun zB von FS20_Doorbell_1, im NOTIFYDEV hab ich aber FS20_Doorbell_.* angegeben.

Muss ich nun das .* selber so ersetzen, dass ich in einer Regex 1 oder 2 daraus machen kann, oder gibt es einen Befehl, der mir auf Booleanisch sagt, dass FS20_Doorbell_1 eh FS20_Doorbell_.* entspricht?

Vielen Dank
schöne Grüße
Martin

[rudolfkoenig]

Ich habe das jetzt mehrmals durchgelesen, und verstehe nicht, worum es geht.
Eigentlich setzt man NOTIFYDEV nicht direkt, sondern ueber notifyRegexpChanged($hash, $regexp).

[delMar]

Ok, vielleicht liegt darin ja mein Problem:

Wenn ich FS20_Doorbell_.*:on in notifiyRegexpChanged reinschreibe, reagiert Notify nicht.

Darf ich nur FS20_Doorbell_.* ohne :on reinschreiben?
Laut DevelopmentModuleInto sollte ja <Definitionsname>:<Event> funktionieren.
Ist das .* mittendrin das Problem?


Danke!

[CoolTux]

Das Event für state on off dürfte eher so ausschauen "FS20_Doorbell_1 on"
Eine passende RegEx könnte dann so auschauen

Code Auswählen Erweitern

FS20_Doorbell_[0-9].on

[rudolfkoenig]

Ob ein Regexp nach NOTIFYDEV umgewandelt werden kann (und damit die Events optimiert verteilt werden koennen) kann man mit notifyRegexpCheck pruefen:

Code Auswählen Erweitern

fhem> define FS20_Doorbell_1 dummy
fhem> define FS20_Doorbell_2 dummy
fhem> { notifyRegexpCheck("FS20_Doorbell_.*:.*") }
FS20_Doorbell_.*:.*: devspec FS20_Doorbell_1,FS20_Doorbell_2 (OK)
fhem> { notifyRegexpCheck("FS20_DoorbellX.*:.*") }
FS20_DoorbellX.*:.*: unknown (ignored)
fhem>


[rudolfkoenig]

Wenn ich FS20_Doorbell_.*:on in notifiyRegexpChanged reinschreibe, reagiert Notify nicht.

Das Problem ist dann woanders. notifiyRegexpChanged bewirkt nur, dass Events optimiert verteilt werden. Es sollte keine Auswirkung darauf haben, ob die Events geliefert werden. Wenn was Gegenteiliges bekannt ist, bitte mir mit Beispiel zeigen.
Wer NOTIFYDEV selber setzt, der handelt natuerlich auf eigene Gefahr.

[delMar]

Danke für eure Antworten, ich weiß jetzt, wie's funktionieren sollte und auch, wie ich das gut ausprobieren kann.

Wenn das Wetter am Wochenende so schlecht wird, wie befürchtet, werd ich viel Zeit haben, mich damit zu beschäftigen.
Ich werde berichten.

[betateilchen]

ich arbeite an einem Modul, welches auf Events reagieren soll

gibts schon: 91_notify.pm 

[delMar]

gibts schon: 91_notify.pm 

Danke, made my day 

[delMar]

Ok, notifiyRegexpChanged funktioniert so, wie es soll.
Ein Rätsel, was da mein Problem war.

Danke dafür.

Gibt es einen Weg, von notifyRegexpCheck nur die Liste von devspecs zu kriegen, ohne den Text vorher und nachher?
Also nur FS20_Doorbell_1,FS20_Doorbell_2

Das wäre nämlich sogar die eigentliche Frage in diesem Thread gewesen 
(alle Wege führen nach Rom)

Ergänzung:
in dem Modul, das ich baue, gebe ich im Define zwei verschiedene Eventquellen an, auf die unterschiedlich reagiert werden muss.

Dh ich muss das FS20_Doorbell_1 aus dem Event mit der Angabe im Define vergleichen. Und da steht ja nur FS20_Doorbell_.* drin.
Wenn ich von notifyRegexpCheck direkt diese Kommagetrennte Liste aller zutreffenden Devices kriegen würde, dann wär dieser Vergleich sehr einfach.
Ich kann den unnützen Teil des Strings natürlich abschneiden. Aber wenns noch einfacher geht, spar ich mir das auch gern.


Danke!

[delMar]

Die Frage mit dem String abschneiden ist eigentlich egal. Ich prüfe einfach mit index, ob der substring enthalten ist.

Viel schlimmer: ich beginne an meinem Verstand zu zweifeln.

Mein Problem:
deviceEvents wird mit Parameter 1 am Ende ausgeführt.
Trotzdem taucht im Event-String kein state: on auf, sondern nur on.


In der Define Methode folgende Zeile

Code Auswählen Erweitern


notifyRegexpChanged($hash, "FS20_Doorbell_.*:on,ipcam_north:snapshot1");


Notify wird richtig ausgelöst.
Aber: der folgende Code führt zum darunterliegenden Log-Output, wenn ich trigger FS20_Doorbell_1 on mache

Code Auswählen Erweitern


sub Notify($$) {
  my ($hash, $nSrcDevHash) = @_;
  my $name = $hash->{NAME};
  my $nSrcName = $nSrcDevHash->{NAME}; # Device that created the events

  Log3 $name, 5, "DoorMan ($name) - Notify from $nSrcName";

  my $events = deviceEvents($nSrcDevHash, 1);
  return if( !$events );

  Log3 $name, 5, "DoorMan ($name) -   Events from $nSrcName: ".join(' ', @{$events});

  foreach my $event (@{$events}) {
    next if(!defined($event));

    Log3 $name, 5, "DoorMan ($name) -   event: $event";
...


Code Auswählen Erweitern


2021.03.19 21:20:18 5: DoorMan (frontdoor) - Notify from FS20_Doorbell_1
2021.03.19 21:20:18 5: DoorMan (frontdoor) -   Events from FS20_Doorbell_1: on
2021.03.19 21:20:18 5: DoorMan (frontdoor) -   event: on


Das hatte aber schon mal funktioniert.

Für Input, wo mein Fehler liegt, wär ich - wieder mal - sehr dankbar.

schöne Grüße
Martin

[rudolfkoenig]

Trigger baut leider nicht die fuer "addStateEvent" notwendigen Strukturen auf.
Das ist ein Bug, und ich zoegere es zu Fixen, da ich nicht weiss, ob es Nebeneffekte hervorruft.
set funktioniert aber:

Code Auswählen Erweitern


fhem> define d1 dummy
fhem> define n notify d1 { Log 1, "E: $EVENT" }
fhem> attr n addStateEvent 1
fhem> info log
fhem> set d1 on
2021.03.19 22:39:29 1 : E: state: on
fhem> trigger d1 on
2021.03.19 22:39:32 1 : E: on


[delMar]

Ok, danke. Das ist gut für mein Gemüt.

Gibt es für solche Fixes mit Nebeneffekten nicht die Featurelevels, wo die Änderung ja dann dokumentiert ist, und jedem User erlaubt, das alte Verhalten beizubehalten?

[rudolfkoenig]

Gibt es für solche Fixes mit Nebeneffekten nicht die Featurelevels, wo die Änderung ja dann dokumentiert ist, und jedem User erlaubt, das alte Verhalten beizubehalten?

Doch, erzeugt aber trotzdem Aufwand auf beiden Seiten (Entwickler und Benutzer).
Und das alles, um bei "trigger FS20_Doorbell_1 state: on" das state: sparen zu koennen.
Vermutlich uebersehe ich etwas.

[delMar]

Doch, erzeugt aber trotzdem Aufwand auf beiden Seiten (Entwickler und Benutzer).
Und das alles, um bei "trigger FS20_Doorbell_1 state: on" das state: sparen zu koennen.
Vermutlich uebersehe ich etwas.

War nur eine Frage. Ich wollte nicht passiv-aggressiv einen Fix einfordern.

Man muss es ja nicht Bug nennen, Set und Trigger können sich ja auch per Definition unterschiedlich verhalten. 

Danke