Modul Event bei setzen eines Attributes

[Guybrush]

vorweg - das gehört wohl eher ins Development Board, aber da kann ich leider nichts posten

gibt es eine Möglichkeit beim setzen eines Attributes innerhalb eines Moduls eine Funktion aufzurufen? Konkret möchte ich beim setzen eines bestimmten Attributes eine Funktion mit dem $hash des Moduls aufrufen können. Ich finde dazu nur leider nichts im Wiki.

[Beta-User]

Evtl. hilft https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Attr weiter?

[DS_Starter]

Du meinst bestimmt das Setzen eines Attr in einem Device ... ja gibt es. Im Eventmonitor findest du ja z.B. beim Setzen des Attr flowGraphicConsumerDistance  folgendes:

Code Auswählen Erweitern


2022-07-03 17:44:55.121 Global global ATTR SolCast5 flowGraphicConsumerDistance 150


Ein notify-Device liefert dir mit der Variablen $NAME das auslösende Device -> hier "SolCast5".

Den Hash des Devs SolCast5 holst du dir mit:

Code Auswählen Erweitern


my $hash = $defs{$NAME};


und kannst $hash dann verwenden.

Vllt. hilft dir das weiter oder der Hinweis von Beta-User.

[Guybrush]

AttrFn würde helfen, wenn dort $hash des aufrufenden Moduls referenziert wäre, was es ja nicht ist. Soweit ich das verstehe ist das eine reine Feedback/Prüffunktion bevor Attribute geschrieben werden. Ich versuche aber mal das was DS_Starter meinte. In $defs sind entsprechend die $hash(es) aller devices enthalten?

Danke aber schonmal

[Beta-User]

Man kann AttrFn() mMn. durchaus etwas weiter verstehen, man kann da durchaus noch mehr machen wie nur die Zulässigkeit eines Attributs/Attributwerts zu prüfen.

Wenn es um Attribute an Instanzen des zu entwickelnden Moduls selbst geht, ist das m.E. der richtige/effizienteste Weg, um "alles mögliche" an Code auszuführen, man kann da ja auch %defs verwenden, um auf den eigenen Hash zu kommen (siehe auch https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Wichtige_globale_Variablen_aus_fhem.pl).

Wenn es um Attribute an "fremden" Devices geht, funktioniert afaik nur der NotifyFn()-Weg, wobei es da einige Punkte "drumrum" gibt, die man optimalerweise berücksichtigen sollte (angefangen damit, dass man NOTIFYDEV entsprechend eng (auf "global") setzt). Wenn du etwas mehr "Futter" lieferst, ist es einfacher, zielführende Hinweise zu geben.

[Guybrush]

ich muss das Thema hier nochmal aufmachen

Das mit dem Zugriff auf den Hash hat sich soweit erstmal erledigt. Was ich jetzt aber konkret brauche ist ansich genau das, was die AttrFn Funktion macht - nur eben nicht VOR sondern NACH dem Schreiben des Wertes in %attr. Also konkret möchte ich einen Event ausgelöst bekommen, wenn jemand ein attribut gesetzt hat. Beispielsweise um einen Login vorzunehmen, nachdem der username gesetzt wurde.

Sicherlich könnte man das auch über die attrFn Funktion reinfuschen, indem man selbst %attr beschreibt und dann da weiter macht. Das ist aber so nicht vorgesehen und soll daher auch nicht passieren. 

[Beta-User]

Was ich jetzt aber konkret brauche ist ansich genau das, was die AttrFn Funktion macht - nur eben nicht VOR sondern NACH dem Schreiben des Wertes in %attr. Also konkret möchte ich einen Event ausgelöst bekommen, wenn jemand ein attribut gesetzt hat. Beispielsweise um einen Login vorzunehmen, nachdem der username gesetzt wurde.

Wenn es an einem dritten Device von einem anderen TYPE ist, müßte ein NotifyFn() auf "global" gesetzt werden (also optimalerweise NOTFYDEF auch gleich entsprechend eng eingegrenzt).

Sicherlich könnte man das auch über die attrFn Funktion reinfuschen, indem man selbst %attr beschreibt und dann da weiter macht. Das ist aber so nicht vorgesehen und soll daher auch nicht passieren.

Ich verstehe aber immer noch nicht, wieso es "Pfusch" sein soll, ggf. weitere Funktionalität in die AttrFn() mit aufzunehmen?
Du kennst doch den Wert, den der User (bzw. fhem.cfg) setzen will (der wird mit übergeben und soll ja gerade auf "gültig" geprüft werden) und kannst den dann auch verwenden. Am Ende gibst du halt "undef" zurück (konkret: du machst ein einfaches "return;"), und gut ist.
Wenn dir das auf direktem Weg nicht geheuer ist, kannst du das auch ggf.  nachgelagert über einen Timer asynchron verwerten...

Vielleicht zeigst du Code, dann ist es vermutlich einfacher.

[Guybrush]

Wenn es an einem dritten Device von einem anderen TYPE ist, müßte ein NotifyFn() auf "global" gesetzt werden (also optimalerweise NOTFYDEF auch gleich entsprechend eng eingegrenzt).

es wäre hier konkret das selbe modul.

Ich verstehe aber immer noch nicht, wieso es "Pfusch" sein soll, ggf. weitere Funktionalität in die AttrFn() mit aufzunehmen?

das wäre unsauber an einer einzigen stelle Attribute anders zu behandeln als es sonst über AttrVal zu ermitteln. Theoretisch dürfte beim Schreiben ja nichts schief gehen, aber ich bin großer Freund davon Sachen nur auf eine Art umzusetzen und nicht mal so und mal so.

Du kennst doch den Wert, den der User (bzw. fhem.cfg) setzen will (der wird mit übergeben und soll ja gerade auf "gültig" geprüft werden) und kannst den dann auch verwenden. Am Ende gibst du halt "undef" zurück (konkret: du machst ein einfaches "return;"), und gut ist.

ja, das ist richtig. Ich kenn den Wert. Nur könnte ich so nicht einfach die connect Funktion aufrufen, da die den Wert per AttrVal ausliest.

Wenn dir das auf direktem Weg nicht geheuer ist, kannst du das auch ggf.  nachgelagert über einen Timer asynchron verwerten...

das über internaltimer zu machen war auch eine Idee. Das könnte man in der AttrFn setzen in der Annahme, dass es 1s nach beenden der AttrFn schon in %attr gesetzt ist. Aber ob das 100% in jedem Usecase funktioniert, weiß ich nicht. Besser wäre es definitiv hier eine Synchronität zu haben. Code gibts noch keinen, da ich grad erst gucke, wie ich es machen kann 

[/quote]

[Beta-User]

das über internaltimer zu machen war auch eine Idee. Das könnte man in der AttrFn setzen in der Annahme, dass es 1s nach beenden der AttrFn schon in %attr gesetzt ist. Aber ob das 100% in jedem Usecase funktioniert, weiß ich nicht. Besser wäre es definitiv hier eine Synchronität zu haben. Code gibts noch keinen, da ich grad erst gucke, wie ich es machen kann 

Du kannst ja mal in fhem.pl schauen...

Ich behaupte: Es funktioniert stressfrei - es sei denn, irgendwas löscht das Attribut zwischendurch wieder und der Modulautor vergißt, den Timer in diesem Fall auch wieder zu löschen.

PS: in RHASSPY gibt es dazu Code, wenn ich das richtig im Kopf habe (zur Aktualisierung des zugehörigen entfernten Dienstes per "training" (das dann dauern kann)). Sowohl in der "Fremd-NotifyFn()"-Variante wie auch aus AttrFn() heraus...