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!
TYPE=ModulName
Gruß
Dan
hmm
Wenn ich meinem Define
$hash->{NOTIFYDEF} = "TYPE=CUL_HM";
benutze, wird meine NotifyFn trotzdem fuer alle Events die es insgesamt gibt aufgerufen.
Allerdings, wenn ich
$hash->{NOTIFYDEF} = "global";
probiere, dann auch. Also muss ich irgendwas grundsaetzliches uebersehen.
Danke!
$hash->{NOTIFYDEF}
Das ist sicher falsch!
Sollte wohl so sein:
$hash->{NOTIFYDEV}
Liegt es daran?
Kenne mich ansonsten leider (noch) nicht mit zweistufigen Modulen aus.
Gruß
Dan
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
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
Danke fuer das Feedback. Offenbar ist mein Wunsch untypisch, ich werde mir einen anderen Weg überlegen. Danke!
Ich habe einen entsprechenden Patch vorgeschlagen: https://forum.fhem.de/index.php/topic,59300.0.html
Gruß
Markus
Zitat von: Markus Bloch am 19 Oktober 2016, 21:48:27
Ich habe einen entsprechenden Patch vorgeschlagen: https://forum.fhem.de/index.php/topic,59300.0.html
Gruß
Markus
Da ist aber einer auf Zack! 8)
Gruß
Dan
Watt Mutt datt Mutt ;)
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 (http://www.fhemwiki.de/w/index.php?title=DevelopmentModuleIntro&curid=1599&diff=16677&oldid=16638#Zweistufiges_Modell_f.C3.BCr_Module)
gruss
andre
Patch von Markus ist drin (weil so "richtiger" ist), sonst sehe ich es wie andre.
Bin aber fuer (begruendete) Alternativen offen.
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?
# 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;
}
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
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.
Ja und die fronthem Version da bitte nur mit Vorsicht als Vorlage nehmen.
Bei rename, reload etc bricht die Verbindung weg weil Prüfungen fehlen.
vg
joerg
danke für den Hinweis. Ist mir dort auch aufgefallen.