Autor Thema: Verhalten eines Moduls beim Neustart  (Gelesen 608 mal)

Offline pizmus

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 91
Verhalten eines Moduls beim Neustart
« am: 03 April 2019, 12:04:02 »
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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19640
Verhalten eines Moduls beim Neustart
« Antwort #1 am: 03 April 2019, 12:13:13 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21262
Antw:Verhalten eines Moduls beim Neustart
« Antwort #2 am: 03 April 2019, 12:47:46 »
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.

Offline pizmus

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 91
Antw:Verhalten eines Moduls beim Neustart
« Antwort #3 am: 03 April 2019, 23:20:43 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21262
Antw:Verhalten eines Moduls beim Neustart
« Antwort #4 am: 04 April 2019, 08:10:38 »
Zitat
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.

Offline pizmus

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 91
Antw:Verhalten eines Moduls beim Neustart
« Antwort #5 am: 07 April 2019, 15:50:00 »
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