Verhalten eines Moduls beim Neustart

[pizmus]

Hallo,
ich entwickle die Esera-Modulfamilie (e.g. 66_EseraOneWire) fuer die 1-wire Controller von Esera, siehe "1Wire" Abteilung im Forum und https://github.com/pizmus/EseraOneWire .

Ich habe Fragen bzgl. des gewünschten Verhaltens eines Moduls beim Start von FHEM. Ich habe dazu leider noch nichts in Wiki und Forum gefunden.

FHEM definiert beim Start die Devices so wie sie z.B. im config File beschrieben sind. Nach dem Ausführen der
"Define"-Implementierung des Moduls ist das Modul EsereOneWire noch einige Sekunden im Hintergrund damit beschäftigt,
- die TCP Verbindung zur Hardware aufzubauen (via DevIo)
- den Esera Controller in einen definierten Zustand zu versetzen (asynchrone Kommunikation mit der Hardware)
- auf die ersten Readings von der Hardware zu warten und sie an die logischen Module/Devices weiterzuleiten (2-stufiges Modell)

Erst danach sind das physikalische Modul (EseraOneWire) und das logische Modul (e.g. EseraDigitalInOut) gemeinsam in der Lage,
"set" Kommandos erfolgreich zu verarbeiten. FHEM hat zu diesem Zeitpunkt vermutlich bereits INITIALIZED signalisiert.

Ein Benutzer von EseraOneWire versucht direkt nach dem INITIALIZED Event Ausgänge zu schalten, was aber fehlschlägt. Siehe https://forum.fhem.de/index.php/topic,91764.0/all.html#lastPost.

Fragen:
Welches Verhalten wird von einem neuen Modul an dieser Stelle erwartet?
Wie signalisiert ein Modul, dass es nicht nur definiert, sondern auch initialisiert (im Sinne von voll einsatzfähig) ist?
Gibt es einen Standard, wie man diesen Zustand mit internals reflektieren sollte?
Hat ein Modul Einfluß auf den Zeitpunkt zu dem global.INITIALIZED signalisiert wird? Und will man das überhaupt?

Viele Grüße,
pizmus

[justme1968]

wenn das tatsächlich so lange dauert das es probleme für die anwender
gibt würde ich vorschlagen das dein modul ein eigenes ,ready' signal erzeugt. entweder über ein reading oder einfach nur als event. darauf können die anwender dann reagieren.

die meisten module setzen nur ein internal. das reicht bei dir aber nicht da kein event ausgelöst wird auf das man reagieren kann.

wenn im define init_done noch nicht gesetzt ist sollte ein modul in der regel selber auf das INITIALIZED event warten bevor es sich initialisiert und verbindung zu seiner hardware aufbaut.  der grund ist das erst nach dem INITIALIZED garantiert ist das alle attribute und bereits vorhandenen readings tatsächlich gesetzt sind.

[rudolfkoenig]

Zusaetzliche Bemerkungen:
- statt per NotifyFn auf global:Initialized zu warten kann man im DefFn auch InternalTimer(1,"myInitFunction",$hash,0) verwenden.
- wenn man DevIo mit TCP/IP verwendet, gibt es ein device:CONNECTED Event, nachdem die Verbindung aufgebaut und initFn aufgerufen wurde.
Diesen Event gibt es neuerdings auch direkt bei der ersten Verbindung, frueher gab das nur beim reconnect.

[pizmus]

Danke schon mal für die Infos. Ich werde dann wohl ein Reading (mit Events) mit dem Namen "status" erstellen, das folgende Werte annehmen kann: defined, connected, initializing, initialized, ready, disconnected. Damit kann der Anwender verschiedene Dinge tun, z.B. wenn das Device "ready" wird, oder auch wenn die Verbindung zur Hardware verloren geht.

Mir fiel noch auf, dass DevIo automatisch ein Reading "state" erzeugt, das die Werte "opened" und "disconnected" annimmt, aber ohne Eventerzeugung. Es ist nicht so optimal, dass ich dann zwei Readings mit ähnlichen Namen und überlappender Bedeutung habe. Gibt es Informationen dazu, wie sich "state" genau verhält und was ein Modul damit tun soll?

Viele Grüße,
pizmus

[rudolfkoenig]

Es ist nicht so optimal, dass ich dann zwei Readings mit ähnlichen Namen und überlappender Bedeutung habe.

Dann mach das nicht, und verwende state selbst.

[pizmus]

Das war ja der Hintergrund meiner Frage. Ohne Absprache werde ich keine Readings überschreiben, die in fremdem Source Code erzeugt werden. Ich muss wissen ob das erlaubt/erwünscht ist, ob sich jemand auf einen bestimmten Wertebereich für das Reading verlässt, wofür das Reading gedacht ist und ob Änderungen in dem Bereich geplant sind.
Ich werte Deinen Kommentar als Antwort auf diese Fragen, und fasse "status" und "state" zusammen. Details in der CommandRef.
Danke und Gruß,
pizmus