IODev Handling durch device

[rudolfkoenig]

Noch bei Setzen des Reading IODev vor Setzen des Internals zusätzlich zu prüfen, ob das Modul das Attribut unterstützt wäre nicht sehr aufwändig, analog zu CommandAttr($$).

Ich finde zwar die Begruendung sehr speziell, ich will aber weder unsere Zeit mit weiteren Diskussionen vergeuden, noch Euer Wunsch ignorieren, habe also den Vorschlag implementiert. Bin unsicher, ob es alle Sonderfaelle so abfaengt, wie Du dir das vorgestellt hast, bitte also um Feedback.

[noansi]

Hallo Rudolf,

danke für's drüber schauen und den Umsetzungsversuch.

In CommandSetstate wird mit

Code Auswählen Erweitern

    if($b1 eq "IODev") {
      my $ret = fhem_setIoDev($hash, $b[2]);
      push @rets, $ret if($ret);
      next;
    }

über fhem_setIoDev

Code Auswählen Erweitern

  $hash->{IODev} = $defs{$val};
  setReadingsVal($hash, 'IODev', $val, TimeNow()); # 120603

weiterhin das Internal IODev als Sonderbehandlung gesetzt.
Nur das Setzen des Readings wird nun unterbunden (so weit ich den Code verstehe), wenn das Attribut vom Modul nicht unterstützt wird.

Was ich meinte

Das Reading IODev jedoch nicht und es wird mit CommandSetstate gesetzt, erfährt damit auch die Sonderbehandlung des Setzens des Internals IODev.
Hat der Modulprogrammierer aber anderes im Sinn, z.B. Setzen des Internals bereits beim define, dann wird es überschrieben.

sehe ich im Code daher noch nicht umgesetzt.
Das Setzen des Readings hat mich nicht gestört, sondern das Setzen des Internals.

D.h. ich vermute aus Deinem Zitat noch ein Missverständnis und ich hoffe, das klärt es nun.

Weiterhin interpretiere ich Deine Änderung derzeit dahingehend, dass Du das Reading IODev in jedem Fall gerne für fhem.pl reservieren möchtest.

Müsste nicht sein, ich meine primär nur Sonderbehandlungen, wenn das Attribut IODev vom Modul in der Attributsliste geführt wird. Andererseits würde eine klare Exklusiviität auch für das Reading natürlich auch künftige IODev Stolperfallen für Modulprogrammierer und unglückliche Userfehlinterpretation verhindern helfen.
Sprich, ein Modul, das die IO Zurodnungsverwaltung selbst übernehmen möchte, lasst die Finger sowohl vom Attribut, als auch vom Reading IODev.

Readings gehoeren eigentlich nicht dem Benutzer, genauso wie Attribute nicht dem Modul.

Nicht dem Benutzer ist klar, aber noch nicht so recht, unter welchen Bedingungen des Reading IODev dem Modul oder dem Kernel "gehört".

Gruß, Ansgar.

[rudolfkoenig]

Naechste Runde, bitte um Feedback.

[noansi]

Hallo Rudolf,

danke!

Damit steht nun fest:
- das Reading IODev steht grundsätzlich unter der exklusiven Kontrolle von fhem.pl
- das Reading IODev wird nur gesetzt, wenn das Attribut IODev vom Modul unterstützt wird
- das Internal IODev wird nicht nach Reading IODev gesetzt, wenn das das Attribut IODev vom Modul nicht unterstützt wird
- sollte ein Modul dynamisch die Attribut IODev Unterstützung ab-/zuschalten wollen, dann gibt es dafür keine Kernel Unterstützung. Ein entsprechender Feature Request mit Diskussion der Funktionalität wäre dann erforderlich.

Der letzte Punkt entspringt den variablen HM-Device Eigenschaften.

Gruß, Ansgar.

[Beta-User]

Hallo zusammen,

nachdem ich jetzt schon eine Weile das - aus meiner Sicht eher zweifelhafte - Vergnügen hatte, behelfsweise alles mögliche rund um die aktuellen Probleme bei CUL_HM zu sammeln, möchte ich nochmal auf die Anregung von noansi hier zurückkommen:

Im Grunde ist das auch die Begründung für die Sonderbehandlung des IODev Attributs, da die config die Reihenfolge der Definitionen nicht vorschreibt/schreiben möchte -> Verlagerung des Setzens ans Ende der Initialisierung, wenn alle IOs definiert sein sollten.
Da kommt mein IODev Änderungsvorschlag in CUL_HM beim FHEM Init nicht dran, weshalb etwas Disziplin bei der Ordnung in der config für volle Funktionalität erforderlich ist.

Damit wäre es eigentlich besser, einem Modul die Möglichkeit zu geben, eine Funktion bereit zu stellen, die zu diesem Zeitpunkt modulspezifische IO Zuweisung durchführt.
Beispielsweise eine $modulhash->{FinalizeInitFn}, die mit Leben gefüllt werden kann, wenn es benötigt wird.

Mit vorhandenen Bordmitteln ($hash->{NotifyOrderPrefix}) scheint es jetzt zwar zu funktionieren, dass die Initialisierungen von HMLAN und CUL_HM im Verhältnis zueinander und auch im Verhältnis zu anderen INITIALIZED-Eventhandlern in der richtigen Reihenfolge abgearbeitet werden, aber irgendwie fühlt sich das wie ein workaround an, und wenn das weitere Verbreitung findet, wird das ganze vermutlich komplett unübersichtlich.

Was - warum auch immer - bei CUL_HM gar nicht mehr funktioniert ist rereadcfg. Evtl. könnte man das dann auch in dem Zuge wieder reparieren...? (oder ganz ausbauen!)

Na jedenfalls: Falls sowas doch angegangen wird, sollte es m.E. auch die Möglichkeit geben, die Reihenfolge innerhalb der Aufrufe per Modul zu manipulieren.

(Hier OT, aber ansonsten wäre ich sehr glücklich, wenn sich wieder ein wirklich Wissender die Zeit nähme, die hoffentlich einigermaßen strukturiert eingesammelten Problemchen rund um CUL_HM eine Lösung im svn zuführen würde. Danke vorab!)

[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:

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

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

Klar ist:

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.

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.

Und das steht wo genau ?

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]

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

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

dass eine getimerte Initialisierung, z.B. mit "-10000000" immer erst nach den global:INITIALIZED-Eventhandlern drankommt...

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]

Ich baue was ein, wenn mindestens zwei Modulautoren ernsthaft beabsichtigen sie zu verwenden.

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.

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

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

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.

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

[M.Schulze]

Hallo,

nur das ich das richtig verstehe:

Ich habe hier eine Installation mit > 200 Geräten, und bei allen ist das

Reading:
IODev NAMEIODEV 2022-02-21 22:24:12

hinzugekommen. Es war früher nicht da. Und ist jetzt immer da???


Das geht so nicht weil es sich nie ändern wird, und bläht, und die Hausfrau nicht interessiert. Wie bekomme ich das Reading weg?

Ausgangslage: Eigenes Modul, ich setze das Reading aber nicht!!!

Bin ich hier im richtigen Thread? Muss ich mein Modul anpassen?

MfG

[rudolfkoenig]

Es war früher nicht da. Und ist jetzt immer da???

Haengt vermutlich damit zusammen, dass das Modul das FHEM Framework verwendet, und hier ein update durchgefuehrt wurde.

Das geht so nicht weil es sich nie ändern wird, und bläht, und die Hausfrau nicht interessiert. Wie bekomme ich das Reading weg?

Einfach eine alte FHEM-Version installieren, z.Bsp. aus dem SVN.