AttrFn: Prüfung von Attributen während der Fhem-Startphase

[klaus.schauer]

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.

[betateilchen]

eine NotifyFn, die auf global:INITIALIZED triggert?

[klaus.schauer]

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.

[herrmannj]

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.)

[betateilchen]

Die Reihenfolge ist doch folgende:

Code Auswählen Erweitern


<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.

[klaus.schauer]

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.

[herrmannj]

Lösung->

eine NotifyFn, die auf global:INITIALIZED triggert?

... in Deinem modul.

[betateilchen]

(http://www.der206cc.de/forum/images/smilies/schilder/hae.gif)

Nur 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.

[klaus.schauer]

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!

[betateilchen]

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.

Die 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.

[rudolfkoenig]

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.

[betateilchen]

c) das existierende Interface NotifyFn verwenden.

...

c) ist schon implementiert,

mal schauen, ob er DIR das glaubt

[justme1968]

@rudi: hat es einen grund das du explizit notifyRegexpChanged erwähnst und nicht

Code Auswählen Erweitern

$hash->{NOTIFYDEV} = "global" ?

[rudolfkoenig]

Nicht unbedingt.

[klaus.schauer]

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.