Im Modul EnOcean wird auch AttrFn zur Prüfung der Attributwerte genutzt. Bisher habe ich die Prüfung auch in der Startphase von Fhem eingesetzt. Nun ist es erforderlich, dass die Attribute in Abhängigkeit des Profils (Attibut subDef) geprüft werden müssen. Das geht aber in den Fällen schief, bei denen zum Zeitpunkt der Prüfung das Attribut "subDef" noch nicht gültig ist. Im Augenblick habe ich deshalb die Prüfung während der Startphase deaktiviert (Abfrage der globalen Variablen $init_done).
Ich suche deshalb nach einer Lösung, um dennoch die Attributwerte beim Fhem Start wieder prüfen zu können.
eine NotifyFn, die auf global:INITIALIZED triggert?
Was soll es bringen, wenn geprüft wird, dass die Intitialisierungphase abgeschlossen ist? Mit dem Hinweis sehe ich keinen Lösungsweg. Schließlich sind ja die Attribute während der Initialisierungsphase zu prüfen.
fhem lädt die device aus der cfg und setzt die Attribute. Der frühest mögliche Zeitpunkt zur Prüfung ist doch, so wie betateilchen richtig vorschlägt, global:initialized. (weil vorher kannst Du nicht davon ausgehen das alle attribute geladen sind.)
Die Reihenfolge ist doch folgende:
<module>_Initialize()
<module>_Define()
<device>_AttrFn()
Wobei sich die Schritte 2 und 3 beliebig oft wiederholen können (von wenigen Ausnahmen abgesehen).
Erst im letzten Schritt (AttrFn) würde das Attribut subDef gesetzt, von dessen Wert Du irgendwas abhängig machen willst.
Du kannst also in _Initialize() - die ohnehin nur ein einziges Mal ausgeführt wird - überhaupt noch nicht wissen, worauf Du überhaupt reagieren sollst, weil Du weder das device noch das zum Device gehörige Attribut kennst.
Danke für die Erläuterung... das Problem hatte ich ja auch so beschrieben. Nur nach Abschluss der Inititalisierungsphase muss dann dafür gesorgt werden, dass alle oder vorgegebene Attribute abklappert und geprüft werden. Diese Anforderung tritt vermutlich nicht nur im EnOcean-Modul auf. Deshalb wäre eine übergreifende Lösung für AttrFn m. E. sinnvoll.
Lösung->
Zitat von: betateilchen am 17 Dezember 2014, 11:53:22
eine NotifyFn, die auf global:INITIALIZED triggert?
... in Deinem modul.
(http://www.der206cc.de/forum/images/smilies/schilder/hae.gif)
Zitat von: klaus.schauerNur nach Abschluss der Inititalisierungsphase
Was ist nach Deinem Verständnis eigentlich die "Initialisierungsphase"? Für mich ist das der Zeitpunkt, zu dem das Modul geladen und die <module>_Initialize() einmalig aufgerufen wird.
Zu diesem Zeitpunkt exitieren noch keine Attribute, die man irgendwie prüfen könnte.
Nun ja wir scheinen unterschiedliche Vorstellungen vom Funktionsumfang von AttrFn zu haben. Ich erwartete, dass AttFn auch diese "Sonderfälle" berücksichtigt. M. E. ist es kein guter Weg, immer und immer wieder über solche oder ähnliche Sonderfälle zu stolpern und sie dann in den Modulen selbst zu umschiffen. Nicht jeder, der sich hier "Entwickler" nennt, hat die Zeit, die Lust und das umfassende Wissen über Fhem-Internas, um spezifische und wahrscheinlich redundante Lösungen zu bauen. Die Zeit und den Frust bei der Fehlersuche hätte ich mir gerne geschenkt!
Zitat von: klaus.schauer am 17 Dezember 2014, 15:22:12
Nun ja wir scheinen unterschiedliche Vorstellungen vom Funktionsumfang von AttrFn zu haben.
Stimmt. Und Du scheinst die Aufgabe von AttrFn() noch nicht verstanden zu haben, obwohl sie in der fhem DevelopmentModuleIntro ziemlich eindeutig beschrieben ist.
ZitatDie Attr-Funktion bekommt nicht den Hash der Geräteinstanz übergeben, da sie ja auch keine Werte dort speichern muss, sondern den Befehl set oder del je nachdem ob ein Attribut gesetzt oder gelöscht wird, den Namen der Geräteinstanz sowie den Namen des Attributs und seinen Wert.
Damit ist das, was Du
erwartest nicht einmal ansatzweise angedacht geschweige denn umgesetzt.
Um das Problem von Klaus zu loesen gibt es mehrere Wege:
a) AttrFn mit einem separaten Argument, der von fhem.pl nach der Initialisierung fuer jeden der definierten Geraete aufgerufen wird
b) eine neue Funktion pro Modul (StartupFinishedFn), der von fhem.pl nach der Initialisierung aufgerufen wird
c) das existierende Interface NotifyFn verwenden.
a) und b) muesste implementiert werden, und man muss auch wissen, dass diese Mechanismen existieren.
c) ist schon implementiert, und ich finde es wichtig, wenn jedem Entwickler bewusst ist, was alles ueber NotifyFn empfangbar ist. Wenn man sich auf global Events beschraenken kann, dann sollte man die Funktion notifyRegexpChanged($hash, "global:.*"); aufrufen. Das sorgt dafuer, dass man nur fuer global Events aufgerufen wird, d.h. Systembelastung ist minimal. Den Event-Namen (INITIALIZED) muss man aber weiterhin noch im NotifyFn pruefen.
Zitat von: rudolfkoenig am 17 Dezember 2014, 15:50:04
c) das existierende Interface NotifyFn verwenden.
...
c) ist schon implementiert,
mal schauen, ob er DIR das glaubt :)
@rudi: hat es einen grund das du explizit notifyRegexpChanged erwähnst und nicht $hash->{NOTIFYDEV} = "global" ?
Nicht unbedingt.
Es gäbe noch eine vierte Variante:
AttrFn speichert die Aufträge und gibt sie erst an die Module weiter, sobald die globale Variable $init_done gesetzt ist.
Hat auch viele Wenns und Abers:
- Wird AttrFn dann mit allen Attributen auf einmal aufgerufen? Wuerde neues Interface bedeuten
- Wird sie einzeln aufgerufen: Kein Unterschied zum aktuellen Stand.
- AttrFn setzt im $attr alle Parameter, und ruft dann AttrFn auf: geht schief, wenn Parameter A sich darauf verlassen muss, dass Parameter B (z:Bsp. SlowRF) "richtig" gesetzt wurde, und die Reihenfolge falsch ist.
Und es muss implementiert werden, und allen bewusst sein.
Lieber ist allen bewusst, dass es ein NotifyFn gibt.
Zitat von: rudolfkoenig am 18 Dezember 2014, 08:30:01
Lieber ist allen bewusst, dass es ein NotifyFn gibt.
*unterschreib*
Ich verstehe es nicht; will es auch nicht. Es gibt da eine Funktion, die tut nur teilweise, was sie verspricht. Jetzt fällt das auf und was wird vorgeschlagen... weitermachen wie bisher ... der Nutzer der Funktion möge sich doch selber kümmern. So stelle ich mir die Weiterentwicklung und Verbesserung von Fhem nicht vor.
Ich sehe es anders. Es gibt eine Funktion (AttrFn), die tut das was sie soll. Fuer Sonderfaelle gibt es auch eine Funktion (NotifyFn). Mir sind keine Gruende bekannt, warum das so nicht funktioniert.
Ich stimme Rudi zu 100% zu !
Dein Problem liegt genau hier:
Zitat von: klaus.schauer am 17 Dezember 2014, 15:22:12
... Nicht jeder, der sich hier "Entwickler" nennt, hat die Zeit, die Lust und das umfassende Wissen über Fhem-Internas, ....
Bitte was denn sonst ???!
Du hast jetzt mehrfach Hilfe für
Dein Problem bekommen, nimm sie an !
Ich denke wir sollten die Diskussion an dieser Stelle beenden. Sie dreht sich nicht mehr um die Sache selbst. Auch dafür will ich keine Zeit opfern.
Zitat von: klaus.schauer am 18 Dezember 2014, 12:46:11
Es gibt da eine Funktion, die tut nur teilweise, was sie verspricht.
Sie tut EXAKT das, wofür sie gedacht ist. Dass sie nicht das tut, was Du gerne möchtest, ist ein völlig anderes Problem.