NotifyDev auf bestimmte Module beschränken ohne Kenntnis der Define-Namen

[unimatrix]

Hallo,

ich arbeite an 2 Modulen für ein Multiroom Audiosystem, ein Server und Client Modul. In einem Setup wird es dann einen Server und mehrere Clients geben. Der Server soll dabei die Clients "kennen" und die Events der clients mitbekommen.

Ich habe mich in die Modulentwicklung eingelesen und bin hier über die NotifyFn gestolpert und auch über die Filterung über NOTIFYDEV.

Meine Frage ist nun, kann ich das irgendwie so hinbekommen, dass ich nur die Events von bestimmten Modultypen mitbekomme, unabhängig davon, wie ein Nutzer dann diese eigentlichen Defines benennen wird?

Oder gibt es eine ganz andere Lösung für meine Sache. Ich könnte natürlich das ganze auch so machen, dass man den Clients beim Define den Namen des Servers mitgibt und die Clients diesem Servermodul dann über fhem Befehle Dinge mitteilt. Aber ist das eine gute Lösung?

Danke!

[DeeSPe]

Code Auswählen Erweitern

TYPE=ModulName

Gruß
Dan

[unimatrix]

hmm

Wenn ich meinem Define

Code Auswählen Erweitern

$hash->{NOTIFYDEF} = "TYPE=CUL_HM";

benutze, wird meine NotifyFn trotzdem fuer alle Events die es insgesamt gibt aufgerufen.

Allerdings, wenn ich

Code Auswählen Erweitern

$hash->{NOTIFYDEF} = "global";

probiere, dann auch. Also muss ich irgendwas grundsaetzliches uebersehen.

Danke!

[DeeSPe]

Code Auswählen Erweitern

$hash->{NOTIFYDEF}

Das ist sicher falsch!
Sollte wohl so sein:

Code Auswählen Erweitern

$hash->{NOTIFYDEV}

Liegt es daran?
Kenne mich ansonsten leider (noch) nicht mit zweistufigen Modulen aus.

Gruß
Dan

[Markus Bloch]

Hallo zusammen,

nein, so funktioniert das leider nicht. $hash->{NOTIFYDEV} kann lediglich eine Liste von Definitionsnamen enthalten (siehe: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#X_Notify Abschnitt: "Begrenzung der Aufrufe auf bestimmte Geräte").

Man könnte das ganze auf eine devspec umstellen. Da bisher keine Anforderung da war, ist das aber noch nicht passiert.

Gruß
Markus

[Markus Bloch]

Man könnte aktuell in der NotifyFn auf global:INITIALIZED, global:REREADCFG usw. hören und dort via devspec2array() (siehe: http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#devspec2array) die entsprechenden Definitionen ermitteln und dann als kommaseparierte Liste in $hash->{NOTIFYDEV} setzen. Dabei sollte es aber bei einer überschaubaren Anzahl an Definitionen bleiben, da die Detailseite sonst unnötig aufgebläht wird.

Gruß
Markus

[unimatrix]

Danke fuer das Feedback. Offenbar ist mein Wunsch untypisch, ich werde mir einen anderen Weg überlegen. Danke!

[Markus Bloch]

Ich habe einen entsprechenden Patch vorgeschlagen: https://forum.fhem.de/index.php/topic,59300.0.html

Gruß
Markus

[DeeSPe]

Ich habe einen entsprechenden Patch vorgeschlagen: https://forum.fhem.de/index.php/topic,59300.0.html

Gruß
Markus

Da ist aber einer auf Zack!

Gruß
Dan

[Markus Bloch]

Watt Mutt datt Mutt

[justme1968]

mal unabhängig von markus erweiterung: in welchem verhältnis stehen client und server zueinander?

ist es nicht nicht normalerweise umgekehrt und die clients kennen den server?

es gibt diverse mechanismen in fhem mit deinen mehrstufige module kommunizieren können. events sind in der regel nicht ideal dafür. unter anderem weil das schief geht wenn es keine 1:n beziehung mehr ist. events sind für statusänderungen gedacht die einen anwender unmittelbar interessieren. deshalb kann er das erzeugen von events auch über diverse attribute beeinflussen. bis hin zum unterdrücken. eine zweite anwendung für events ist das lose koppeln von nicht 'verwandten' modulen. also eher das gegenteil von deinen beiden. auch ist bei events drauf zu achten das sie potentiell durch jedes/viele notify und ähnliches laufen und für unnötig systemlast sorgen können.

statt dessen gibt Parse/dispatchFn, clients und matchList, read/write/readyFn, DevIo, autocreate/autoload, ...

die dokumentation (außer dem quelltext ) ist in diesem bereich zur zeit noch sehr unvollständig. einen anfang gibt es hier: http://www.fhemwiki.de/w/index.php?title=DevelopmentModuleIntro&curid=1599&diff=16677&oldid=16638#Zweistufiges_Modell_f.C3.BCr_Module

gruss
  andre

[rudolfkoenig]

Patch von Markus ist drin (weil so "richtiger" ist), sonst sehe ich es wie andre.
Bin aber fuer (begruendete) Alternativen offen.

[unimatrix]

Hallo,

ich hatte inzwischen noch den Quelletext diverser anderer Module studiert und bin auf die Kombination 01_fronthem.pm und 31_fronthemDevice.pm gestoßen. Diese haben auch eine Art 1:n Beziehung. Ein fronthemDevice benötigt ein fronthem. Dabei wird in 31_fronthemDevice einfach das komplette %defs durchsucht und dann direkt eine Funktion in dem gefundenen Device  aufgerufen um sich dort zu registrieren (siehe unten fronthemRegisterClient, wird von 31_ aufgerufen, aber in 01_ definiert). Somit kennen sich dann die Module gegenseitig und kommunizieren über Funktionsaufrufe unabhängig von den FHEM Mechanismen.

Ist das eine bessere Implementierung? Das könnte ich bei mir auch so nutzen und wäre vll. resourcenschonender als eine NotifyFn?

Code Auswählen Erweitern


# register this client at fronthem instance
sub
fronthemDevice_Register(@)
{
  my ($hash) = @_;
  #TODO add attrib for manual assignment of fronthem
  foreach my $key (keys %defs)
  {
    if ($defs{$key}{TYPE} eq 'fronthem')
    {
      $hash->{helper}->{gateway} = $key;
      fronthem_RegisterClient($defs{$key}, $hash->{NAME});
      readingsSingleUpdate($hash, 'gateway', $key, 0);
      last;
    }   
  }
  return undef;
}


[justme1968]

das ist besser als events. aber das braust du nich von hand zu machen. DevIo macht das für dich wenn du AssignIoPort verwendest.

gruss
  andre

[unimatrix]

ah genial darauf war ich noch gar nicht gekommen. Also das ganze so nutzen wie ein physikalisches und ein logisches Modul. Dann fuchs ich mich mal rein. Danke fuer die Hilfe.