FHEM Start und Definition von IO Devices

[zap]

Wird beim zweistufigen Modulkonzept beim Starten von FHEM zuerst das IO Device und dann die Client-Devices definiert bzw. wird das beim Speichern in der entsprechenden Reihenfolge in fhem.cfg geschrieben?

[CoolTux]

Wenn Du die entsprechenden Prefix verwendest dann ja.

73 IODev
74 das Device Modul

Nur als Beispiel

[zap]

Welches Präfix meinst Du? Oder richtet sich die Reihenfolge der Speicherung nach dem Internal NR?

[CoolTux]

Nach der Zahl vor dem Modulnamen

Sorry bin kurz angebunden, sonst wurde ich mehr schreiben

[rudolfkoenig]

@zap: die Reihenfolge des Speicherns in fhem.cfg ist identisch mit der Reihenfolge des Definierns, bzw. die beim Einlesen der Konfiguration.
Wenn man ein Clientdevice ohne IOdevice definirt, dann kommt normalerweise im Logfile die Meldung "No I/O device found for ...". Das passiert, wenn man fhem.cfg (ohne darueber nachzudenken) selbst umbaut, oder IOdevice entfernt bzw. ersetzt.
Es gibt z.Zt. keine elegante Moeglichkeit, die Reihenfolge von spaeter hinzugefuegten IOdevice (beim Ersetzen) zu aendern, ausser fhem.cfg direkt zu editieren..

@CoolTux: dieser Praefix ist inzwischen beinahe nutzlos: es bestimmt die Reihenfolge in der Dispatch Funktion den Client-Modulen die Rohdaten vom IODev zu praesentieren. Damit kann z.Bsp. das USF1000 Modul FS20 Signale "entfuehren".

[CoolTux]

Guten Morgen Rudi,

Dann lag ich ja total daneben. Danke für die korrekte Info.

@Zap
Sorry für die falsche Info. Da lag ich voll daneben.



Grüße

[zap]

Danke Euch für die Antworten. Ich werde meine Client Module dahingehend anpassen, dass sie im Define nicht einfach davon ausgehen, dass das IO Device schon definiert ist bzw. im Zweifel eine entsprechende Fehlermeldung werfen.

Ich stecke jetzt in der FHEM Entwicklung bzw. fhem.pl nicht so tief drin. Aber grundsätzlich weiß doch jedes IO Modul, welche Client-Module zu ihm gehören und wenn man eine lauffähige Konfiguration in FHEM aktiv hat, sollte entsprechend auch in jedem Client-Modul das IODev gesetzt sein. Auf dieser Grundlage könnte man doch beim Speichern der Config dafür sorgen, dass dies in der richtigen Reihenfolge in fhem.cfg geschrieben wird, oder? Passiert das aktuell schon so?

[CoolTux]

Man darf mich gerne hauen wenn ich mich irre, aber so wie ich das verstanden habe und auch entwickelt habe muß der Modulauthor selber für die Logik sorgen was das wissen und erkennen an geht.

Code Auswählen Erweitern


$hash->{Clients}    = ":NUKIDevice:";

Dies sorgt dafür das das physisches Modul weiß welche logischen Module ihm zugeordnet sind.

[Markus Bloch]

Das ist korrekt. Ich habe das ganze zweistufige Modulkonzept vor einiger Zeit im Wiki mal ausführlich dokumentiert: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module

Gruß
Markus

[rudolfkoenig]

Man darf mich gerne hauen wenn ich mich irre,

Nicht hauen, hoechstens korrigieren

$hash->{Match} in der logischen Modulbeschreibung  (nicht Instanz $hash!) wird verwendet, um in Dispatch eine vom physischen Geraet gemeldete Nachricht dem zustaendigen logischen Modul zuzuordnen (man denke an CUL vs FS20/FHT/CUL_EM/CUL_WS/etc). Das geht natuerlich nur mit geladenen logischen Modulen, d.h. wenn ein "define XXX FS20 ..." usw. vorher durchgefuehrt wurde.

$hash->{Clients} in der physischen Modulbeschreibung wird verwendet, falls kein bereits geladenes logisches Modul sich fuer die gemeldeten Daten zustaendig fuehlt, um ein autoload durchzufuehren. Normalerweise fuehrt das Interpretieren dieser Nachricht im gerade geladenen logischen Modul zu einem "UNDEFINED XXX FS20 ..." Event, was ueblicherweise via autocreate mit dem Anlegen einer logischen Instanz (define XXX FS20 ...) endet.

Der Artikel von Markus ist aber viel detaillierter...

[Markus Bloch]

Danke Euch für die Antworten. Ich werde meine Client Module dahingehend anpassen, dass sie im Define nicht einfach davon ausgehen, dass das IO Device schon definiert ist bzw. im Zweifel eine entsprechende Fehlermeldung werfen.

Ich stecke jetzt in der FHEM Entwicklung bzw. fhem.pl nicht so tief drin. Aber grundsätzlich weiß doch jedes IO Modul, welche Client-Module zu ihm gehören und wenn man eine lauffähige Konfiguration in FHEM aktiv hat, sollte entsprechend auch in jedem Client-Modul das IODev gesetzt sein. Auf dieser Grundlage könnte man doch beim Speichern der Config dafür sorgen, dass dies in der richtigen Reihenfolge in fhem.cfg geschrieben wird, oder? Passiert das aktuell schon so?

Ich würde dir empfehlen jeglichen Versuch von Kommunikation mit dem IO-Device in der Define-Funktion nur dann vorzunehmen, wenn FHEM bereits initialisiert/gestartet ist ($init_done == 1). Während der Initialiserungsphase sollte man keine IO-Operationen via IO-Device machen. Im Falle das FHEM sich gerade initialisiert ($init_done == 0) sollte man in der NotifyFn auf das global-Event INITIALIZED bzw. REREADCFG lauschen. Details dazu im Wiki zur DefineFn: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Define

Gruß
Markus

[betateilchen]

Es gibt z.Zt. keine elegante Moeglichkeit, die Reihenfolge von spaeter hinzugefuegten IOdevice (beim Ersetzen) zu aendern, ausser fhem.cfg direkt zu editieren..

Deshalb hatte ich schon vor langer Zeit vorgeschlagen, in den Modulen, die IOdevices erzeugen, dafür zu sorgen, dass ein IOdevice als solches "erkennbar" ist, beispielsweise durch ein entsprechendes Internal. Dann könnte man beim Speichern der fhem Konfiguration automatisiert dafür sorgen, dass IOdevices möglichst früh gespeichert werden.

[zap]

Ist nicht die Existenz von $hash->{clients} genau dieses Flag? Ok, gibt es natürlich nur, wenn es auch Client Module gibt. Allerdings ist auch nur dann wichtig, dass ein IO Device frühzeitig definiert wird.

Also könnte man beim Speichern zunächst mal alle Devices speichern, die o.g. Internal gesetzt haben.

[justme1968]

es sind keine zusätzlichen flags nötig.

man müsste vor dem speichern nur alle devices durch gehen und an hand des IODev internals jeweils alle devices die zu einem iodev gehören zusammen suchen und dann jeweils zuerst das iodev und alle zugehörigen devices speichern und dann mit dem nächsten iodev weiter machen. und danach den ganze rest.

[Benni]

Deshalb hatte ich schon vor langer Zeit vorgeschlagen

... genau den Thread habe ich aus (bei mir) aktuellem Anlass vor ein paar Tagen ausgegraben