FHEM - Entwicklung > FHEM Development

IODev Handling durch device

<< < (17/17)

Beta-User:
Nachdem wir heute wieder einen User hatten, der mit at/computeAfterInit ein Verständnisproblem hatte, greife ich das mit dem Vorschlag einer FinalizeInitFn hier nochmal auf:

--- Zitat von: rudolfkoenig am 22 November 2021, 13:19:27 ---Ich kann InitFn() einbauen, aber nur, damit ich nicht immer wieder erklaeren muss, dass es nicht hilft.

--- Ende Zitat ---

Wäre für weitere Rückmeldungen dazu dankbar...

Klar ist:

--- Zitat ---Wenn Astro gettimeofday()+5 fuer die Initialisierung verwendet, dann wird das mit InitFn nicht besser. Um die richtige Reihenfolge zu berechnen, muessten alle Instanzen (und nicht nur die Module) angeben, von welchen Anderen sie abhaengen. Das ist Konfigurations und damit Benutzer abhaengig, und kann nicht ernsthaft von einem Benutzer verlangt werden. Mit etwas "Glueck" darf man auch eine zyklische Abhaengigkeit aufloesen.

--- Ende Zitat ---
Diese Argumentation ist m.E. zwar berechtigt, was den Hinweis betrifft, dass man dadurch nicht alle möglichen Abhängigkeiten beseitigt, sondern "nur" dafür sorgt, dass zumindest ReadingsVal()-Abfragen usw. nicht ins Leere gehen, nur weil die Devices halt - aus welchen Gründen auch immer - in der cfg an der "falschen Stelle" steht.
Diese FinishInitFn() kann nur dafür sorgen, dass der betreffende Code erst dann ausgeführt wird, wenn zwar alle Devices geladen sind und die alten Reading-Werte geladen (soweit überhaupt bekannt) und dabei "nebenbei" bekannte Abhängigkeiten beachten (indem es die Option gibt, eine Reihenfolge vorzugeben).

Events dürfen übrigens m.E. zu diesem Zeitpunkt keine generiert werden.


--- Zitat ---Und das steht wo genau ? :)
--- Ende Zitat ---
:o
Aber im Ergebnis ändert es wenig daran, dass eine getimerte Initialisierung, z.B. mit "-10000000" immer erst nach den global:INITIALIZED-Eventhandlern drankommt, oder übersehe ich da wieder was?
Jedenfalls für CUL_HM war der Zeitpunkt "0" mind. in einem Fall zu spät, sonst wäre nicht der jetzige Vorschlag der Lösung mit NotifyFn() und niedrigem Präfix entstanden...

rudolfkoenig:

--- Zitat ---Ich kann InitFn() einbauen, aber nur, damit ich nicht immer wieder erklaeren muss, dass es nicht hilft.

--- Ende Zitat ---
Ich baue was ein, wenn mindestens zwei Modulautoren ernsthaft beabsichtigen sie zu verwenden.
Bitte spezifizieren:
- wann genau sollen die Funktionen aufgerufen werden
- nach welcher Reihenfolge sollen die Aufrufe erfolgen



--- Zitat ---dass eine getimerte Initialisierung, z.B. mit "-10000000" immer erst nach den global:INITIALIZED-Eventhandlern drankommt...
--- Ende Zitat ---
Das ist richtig.
Die Aufrufreihenfolge kann der Maintainer fuer die Instanzen der eigenen Module festlegen, das geht aber sowohl mit der notify wie auch mit der InternalTimer Methode.
Wenn man von Instanzen fremder Modulen abhaengt, dann muessten diese jeweils ein INITIALIZED Event generieren, das kann vom abhaengigen Modulinstanz ausgewertet werden. Dazu ist "nur" das Wissen notwendig, wer von wem abhaengt.

Beta-User:

--- Zitat von: rudolfkoenig am 22 November 2021, 14:33:21 ---Ich baue was ein, wenn mindestens zwei Modulautoren ernsthaft beabsichtigen sie zu verwenden.

--- Ende Zitat ---
Ich würde einen Vorschlag für CUL_HM/HMLAN/etc. liefern, vorausgesetzt, Martin würde sich dazu (positiv) äußern. Für meine eigenen Module brauche ich es nicht.

Aufgegriffen hatte ich das Thema, weil ich annehme, dass sich manche Initialisierungs-Probleme damit besser lösen lassen, mit denen sich grade zap bei HMCCU.* rumschlägt bzw. die mir als potentielle Probleme bei der ersten Durchsicht über eines der Module aufgefallen waren (ich habe das aber nicht näher untersucht, ist nur ziemlich von ferne). Auch insoweit würde ich ggf. Unterstützung anbieten.


--- Zitat ---Bitte spezifizieren:
- wann genau sollen die Funktionen aufgerufen werden
- nach welcher Reihenfolge sollen die Aufrufe erfolgen

--- Ende Zitat ---
Meine Vorstellung:
- Aufruf vor dem global:INITIALIZED-Event, also: Alle Devices mit allen Attributen geladen, alle Readings aus der statefile geladen.
- Reihenfolge beeinflussbar durch ein Internal, analog zu NotifyOrderPrefix, hilfsweise könnte automatisch auch der Modul-Namenspräfix verwendet werden, also 00_HMLAN ergäbe "00" vor 10_CUL_HM (=> 10).

Einzuhaltende Regel durch die Module wäre: Es werden in diesem Stadium keine Events erzeugt! (Oder es wird irgendwie anders verhindert, dass irgendeine NotifyFn() dazwischengrätscht).


--- Zitat ---Wenn man von Instanzen fremder Modulen abhaengt, dann muessten diese jeweils ein INITIALIZED Event generieren, das kann vom abhaengigen Modulinstanz ausgewertet werden. Dazu ist "nur" das Wissen notwendig, wer von wem abhaengt.

--- Ende Zitat ---
Das wäre auch eine Variante. Hat halt den Nachteil, dass man überhaupt eine NotifyFn() braucht. In einem Gutteil der Module scheint die nur drin zu sein, um die Initialisierung zu machen, und es erfordert in diesen Fällen etwas "Beiwerk", um das auf "global" zu begrenzen usw.. Ergo würde das auch ein klein wenig Overhead sparen, wenn man es insgesamt so macht (in den meisten Fällen kann man vermutlich auch einen InternalTimer alternativ verwenden; so war das jedenfalls bei den Modulen, die ich bisher in diese Richtung in der Hand hatte).

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln