Initialisierungssequenz für Devices in FHEM

[Dr. Boris Neubert]

Hallo,

in den Modulen gibt es üblicherweise DEVICE_Define, DEVICE_Undefine, DEVICE_DoInit.

Im DoInit wird das Device geöffnet (heißt meist DEVICE_OpenDev). Wenn DoInit aus Define heraus aufgerufen wird, hat das zur Folge, daß bei einem Neustart OpenDev mit dem Default-I/O-Gerät ausgeführt wird, also dem zuletzt definierten, und nicht mit dem per

Code Auswählen Erweitern

attr ... IODev ... gewünschtem Gerät.

Ich habe mir nun die Frage gestellt, wie die Initialisierungssequenz von FHEM bei einem Start eigentlich funktioniert und wie man Module programmieren muß, daß bei einem Neustart von FHEM DoInit erst dran kommt, wenn der Server die Konfigurationsdatei vollständig verarbeitet hat.

Ich würde das gerne dokumentieren.

In diesem Zusammenhang gehört auch global.INITIALIZED.

Vielen Dank für eine Erklärung.
Boris

[rudolfkoenig]

Hallo Boris,

DEVICE_Define wird von jedem Modul benoetigt, der Geraete anbietet.
Es gibt auch noch die reinen Befehls-Module wie xmllist, backup, etc. die nur zusaetzliche Befehle anbieten.

Vor dem Bau solcher reiner Befehlsmodule moechte ich abraten: z.Bsp. waere backup mAn mit define besser dran, weil man damit die backup-Parameter nicht bei global setzen muesste, man auch unterschiedliche backups (lokal-minimal / komplett auf dem Tape / usw.) definieren koennte, und diese Punkte automatisch im Frontend auftauchen wuerden. Das war jetzt nicht als "backup-schelte" gedacht (man lernt schliesslich dazu, gilt auch fuer mich), sondern generell als Argumentation fuer "define".

DEVICE_Undefine it z.Bsp. fuer filedescriptor schliessen notwendig (sog. physikalische Geraete wie CUL/FHZ), oder um die modul-interne ID zu FHEM-Namen Mapping zu bereinigen (bei logischen Geraete wie FS20, CUL_HM).

DEVICE_DoInit wird mAn nur von den physikalischen Geraeten verwendet, die eine Datei mit DevIo_OpenDev oeffnen, und das Geraet zusaetzlich zu Baudrate/etc initialisieren muessen. Ich kann keine Verwendung im Zusammenhang mit dem IODev Attribut erkennen.

Wenn ein Modul die Initialisierung der einzelnen Geraete nur nach Kenntnis aller Attribute und Readings vornehmen will, dann spezifiziert main ein NotifyFn, wartet hier auf dem Aufruf mit dem (indirekten) Parameter "global:INITIALIZED", fuehrt eine Schleife ueber alle Geraete durch, fischt dabei seine eigenen raus, und initialisiert diese. Danach kann in diese Routine NotifyFn entfernen oder umsetzen. Das passiert im Telnet Modul, um motd mit SecurityWarning zu fuellen.

Gruss,
  Rudi

[Martin Fischer]

> ich habe mir nun die Frage gestellt, wie die Initialisierungssequenz von FHEM bei einem Start eigentlich
> funktioniert und wie man Module programmieren muß, daß bei einem Neustart von FHEM DoInit erst dran kommt,
> wenn der Server die Konfigurationsdatei vollständig verarbeitet hat.

es gibt eine globale variable namens $init_done die true ist, wenn die config komplett eingelesen wurde.

martin

[Martin Fischer]

> DEVICE_Define wird von jedem Modul benoetigt, der Geraete anbietet.
> [...]
> Vor dem Bau solcher reiner Befehlsmodule moechte ich abraten: z.Bsp. waere backup mAn mit define besser dran,
> weil man damit die backup-Parameter nicht bei global setzen muesste, man auch unterschiedliche backups (lokal-
> minimal / komplett auf dem Tape / usw.) definieren koennte, und diese Punkte automatisch im Frontend auftauchen
> wuerden. Das war jetzt nicht als "backup-schelte" gedacht (man lernt schliesslich dazu, gilt auch fuer mich),
> sondern generell als Argumentation fuer "define".

und hier ist der widerspruch:
im ersten satz schreibst du, das ein DEVICE_Define ein gerät anbietet und dann bringst du das bespiel mit backup, welches ja definitiv kein gerät ist.

ich hätte theoretisch nichts dagegen das auch im gui anzeigen zu lassen aber ich habe definitv was dagegen, wenn jetzt geräte mit befehlen vermischt werden. unabhängig vom gewählten beispiel:
backup ist aus meiner sicht genauso ein "globales" thema für die fhem installation wie z.b. eine spracheinstellung. und genau deshalb beführworte ich auch die (sinnvolle) erweiterung von globalen attributen für core-module.

genauso ist es aus meiner sicht erforderlich für die homematic definitionen einen neuen "analogen" befehl zu define für die channels in fhem realisieren. ich will einfach nicht mehr bei einem HM-CC-TC drei geräte angezeigt bekommen, wenn es physikalisch nur ein gerät ist.

hierbei geht es mir aber nicht nur um die darstellung, sondern auch um die logik. wenn nur ein physikalisches gerät vorhanden ist, dann sollte das auch nur einmal über ein "define" angebildet werden. channels sollten dann z.b. über "channel" oder wenn man es fhem global umsetzen wollte über ein "extend" abgebildet werden.

und genau aus diesen gründen würde ich ein "backup" auch nicht mittels define begrüssen.

meine momentane wahrnehmung:
Fhem "verwildert" immer mehr... die erstellung von device-klassen, apis, einheitlichen bezeichnern oder sonstige vereinheitlichungen rücken in weite ferne..

martin

[Dr. Boris Neubert]

Hallo Rudi,

Danke für die Erläuterung - kommt demnächst ins Wiki.

Hallo Boris,
DEVICE_DoInit wird mAn nur von den physikalischen Geraeten verwendet, die eine Datei mit DevIo_OpenDev oeffnen, und das Geraet zusaetzlich zu Baudrate/etc initialisieren muessen. Ich kann keine Verwendung im Zusammenhang mit dem IODev Attribut erkennen.

Du hast recht und ich hatte einen Knoten im Gehirn.

Wenn ein Modul die Initialisierung der einzelnen Geraete nur nach Kenntnis aller Attribute und Readings vornehmen will, dann spezifiziert main ein NotifyFn, wartet hier auf dem Aufruf mit dem (indirekten) Parameter "global:INITIALIZED", fuehrt eine Schleife ueber alle Geraete durch, fischt dabei seine eigenen raus, und initialisiert diese. Danach kann in diese Routine NotifyFn entfernen oder umsetzen. Das passiert im Telnet Modul, um motd mit SecurityWarning zu fuellen.

Ja, das ist es, was ich brauche. Ein OWDevice darf nämlich erst beginnen, mit dem OWServer zu sprechen, wenn es vollkommen definiert ist. Das trifft m.E. für alle Client-Geräte zu. Ich verstehe das jetzt besser. Grundsätzlich sollten Client-Geräte auf $init_done (Danke, Martin!) prüfen, bevor sie aktiv werden.

Viele Grüße
Boris

[rudolfkoenig]

> dann bringst du das bespiel mit backup, welches ja definitiv kein gerät ist.

Stimmt, ich finde es waere aber besser, wenn es eins waere, weil man dann mehr Moeglichkeiten haette, s.o. Ich wuerde heutzutage auch SUNRISE_EL und SVG als Geraet bauen, beim SVG bin ich gerade sehr am ueberlegen. Ich widerhole es gerne: es war nicht als Angriff auf Backup oder gar auf Dich gemeint, und ich will Dich auch nicht zum Umbau von backup motivieren.


> ich will einfach nicht mehr bei einem HM-CC-TC drei geräte angezeigt bekommen, wenn es physikalisch nur ein gerät ist.

Da bin ich vollkommen bei Dir. Uebrigens sind es 4 Geraete: X + X_Climate + X_Weather + X_WindowRec. Ich finde es ungluecklich, dass der Benutzer mit dem internen Aufbau des Geraetes "belaestigt" wird.


> genauso ist es aus meiner sicht erforderlich für die homematic definitionen einen neuen "analogen" befehl zu define für die channels in fhem realisieren.

Ich sehe das anders, mit einem neuen Befehl ist noch keinem geholfen. Wenn man zu den Geraeten parallel Kanaele einfuehrt, dann muss man noch mindestens das Konzept der Geraete und der Events anpassen, samt Anpassung aller alten Module + Doku, fuer den Benutzer wird es auch nicht einfacher. Ich finde diesen Aufwand nicht nur unverhaeltnismaessig sondern einfach unnoetig: man koennte das alte HM Modul (oder ein Neues?) auch so bauen, dass es auf Benutzer-sichtbare Kanaele verzichtet.

Es ist mAn eine Philosophiefrage, ob man _alle_ Eigenschaften komplexer Geraete in fhem zugaenglich macht, oder ob man es fuer Anfaenger einfach macht. Ich setze bei meinen Modulen eher auf einfach, das CUL_HM Modul setzt auf vollstaendig.

Bei der Aufnahme/Pflege von FHEM-Modulen wird die Befolgung der "richtigen" Philosophie nicht erzwungen, auch weil es gar nicht definiert ist.


>  Fhem "verwildert" immer mehr...

Dem will ich nicht widersprechen, und ich nehme das in Kauf.

FHEM ist ein Freizeitprojekt, damit man Spass hat, und Richtlinien fuer andere zu definieren oder gar zu erzwingen gehoert nicht dazu. Wenn FHEM wegen der Verwilderung nicht das naechste grosse Ding wird und kommerziell weiterhin ein Flop bleibt, dann hat das auch sein Gutes: ich muss mir nicht ein neues Freizeitprojekt suchen :)

[Martin Fischer]

> Stimmt, ich finde es waere aber besser, wenn es eins waere, weil man dann mehr Moeglichkeiten
> haette, s.o. Ich wuerde heutzutage auch SUNRISE_EL und SVG als Geraet bauen, beim SVG bin ich
> gerade sehr am ueberlegen.

Wie ich schon schrieb:
Ich habe prinzipiell nichts dagegen. Allerdings möchte ich gerne eine logische Trennung von einer Gerätedefinition und einer "Funktionsdefinition". Und das ist aus meiner Sicht eine grundsätzliche Designfrage.

> Ich widerhole es gerne: es war nicht als Angriff auf Backup oder gar auf Dich gemeint, und ich
> will Dich auch nicht zum Umbau von backup motivieren.

Das habe ich auch so nicht gewertet! Backup ist ein von Dir gut gewähltes Beispiel, das mein Sichtweise nur unterstreicht.

>> genauso ist es aus meiner sicht erforderlich für die homematic definitionen einen neuen
>> "analogen" befehl zu define für die channels in fhem realisieren.
>
> Ich sehe das anders, mit einem neuen Befehl ist noch keinem geholfen. Wenn man zu den Geraeten
> parallel Kanaele einfuehrt, dann muss man noch mindestens das Konzept der Geraete und der Events
> anpassen, samt Anpassung aller alten Module + Doku, fuer den Benutzer wird es auch nicht einfacher.
> Ich finde diesen Aufwand nicht nur unverhaeltnismaessig sondern einfach unnoetig: man koennte das
> alte HM Modul (oder ein Neues?) auch so bauen, dass es auf Benutzer-sichtbare Kanaele verzichtet.

Ja, keiner hat gesagt, dass man das mal eben "im vorbeigehen" macht. Fakt ist: so wie HM zur Zeit implementiert ist (1 physikalisches Gerät = n Devices), ist es weder übersichtlich noch logisch.

Den Vorschlag ein neues HM Modul zu unterstützen finde ich vollkommen abwägig. Es reicht aus meiner Sicht schon, das der Nutzer bei 1-Wire vor die Qual der Wahl gestellt wird. Das diese Module auch künftig nicht "gemerged" werden, hat an dieser Stelle andere Gründe, die wir alle kennen.

Das Problem stellt sich aus meiner Sicht so dar, das Fhem in den Jahren mit dem derzeitigen Design das ein "define" je (physikalischem) Gerät und angereichert mit "attribute" ausreichend war, durch HomeMatic aber neue Anforderungen wie Channels und Register hinzukamen. Und auch die Definition der "readings" hat dadurch eine andere Sicht bekommen.

> Es ist mAn eine Philosophiefrage, ob man _alle_ Eigenschaften komplexer Geraete in fhem
> zugaenglich macht, oder ob man es fuer Anfaenger einfach macht. Ich setze bei meinen Modulen
> eher auf einfach, das CUL_HM Modul setzt auf vollstaendig.

Auch hier bin ich einer anderen Meinung. Ein Gerät sollte nach Möglichkeit immer vollständig unterstützt werden. Das was Du bzgl. der "Einfachheit" ansprichst ist aus meiner Sicht genau die Herausforderung: Wie implementiere ich ein Gerät mit allen Funktionen so, das auch ein Anfänger damit zurecht kommt? Und das ist aus meiner Sicht u.a. auch sehr stark mit der Darstellung innerhalb von Fhem verbunden.

HomeMatic ist dafür ein sehr treffendes Beispiel. Ich mache an dieser Stelle dem "anderen" Martin keinen Vorwurf. Respekt vor seiner Leistung auch wenn ich persönlich keinen "roten Faden" erkennen kann, da aus meiner Sicht zuviel "gesprungen" wird. Es bleibt ihm zur Zeit aber nichts anderes übrig als sich an das Design von Fhem zu halten. Und das ist aus meiner Sicht eher hinderlich um HomeMatic für den Anwender aber auch für Entwickler die darauf aufbauen möchten. logisch und einfach in Fhem zu integrieren.

Hier sollte man meiner Meinung nach ernsthaft in Erwägung ziehen ob man "alte Zöpfe" nicht abschneidet und das momentane Konzept überdenkt / anpaßt.

>> Fhem "verwildert" immer mehr...
>
> Dem will ich nicht widersprechen, und ich nehme das in Kauf.
>
> FHEM ist ein Freizeitprojekt, damit man Spass hat, und Richtlinien fuer andere zu definieren
> oder gar zu erzwingen gehoert nicht dazu. Wenn FHEM wegen der Verwilderung nicht das naechste
> grosse Ding wird und kommerziell weiterhin ein Flop bleibt, dann hat das auch sein Gutes: ich
> muss mir nicht ein neues Freizeitprojekt suchen :)

Es bleibt mir nach wie vor ein Rätsel, warum Du immer (auch in unseren privaten Mails) den kommerziellen Aspekt als Grund nennst. Mir persönlich ist es egal ob Fhem "kommerziell ein großes Ding" wird, da ich das genauso wie Du (und andere) in meiner Freizeit mache. Sollte die Überlegung mal im Raume stehen, dann weißt Du, das ich das Unterstützen würde. Aber das ist nicht mein Fokus.

Allerdings ist es auch bei einem "Freizeitprojekt" nicht abwägig, gewisse "Spielregeln" oder "Konzepte" vorzuhalten. Und sei es nur dazu gedacht, das es eben weniger "chaotisch", dafür aber transparenter, nachvollziehbarer und einfacher wird. Letztlich gewinnen doch am Ende alle.

Dabei ist es doch egal, mit welcher Art von "Freizeitprojekt" man sich befaßt. Denn wenn man sich z.B. eine Gartenlaube in seiner Freizeit bauen will, so muß man sich auch da mal ggf. mit der Statik und vielem mehr auseinander setzen. Und schon hält man sich an gewisse Vorgaben oder man nimmt wissentlich in Kauf, das die Hütte den nächsten Sturm nicht übersteht. Und je mehr an der "Hütte basteln" desto mehr Absprachen sind erforderlich.

Gruß Martin

[rudolfkoenig]

> Denn wenn man sich z.B. eine Gartenlaube in seiner Freizeit bauen will, so muß man sich auch da mal ggf. mit der Statik und vielem mehr auseinander setzen.

Um bei diesem Vergleich zu bleiben: Meine "Laube" funktioniert seit 7 Jahren ohne Probleme. Und ich reisse meine Laube nicht ab, nur weil das was der Nachbar nach meine Skizze gebaut hat, mir nicht passt.

[Martin Fischer]

> Um bei diesem Vergleich zu bleiben: Meine "Laube" funktioniert seit 7 Jahren ohne Probleme.
> Und ich reisse meine Laube nicht ab, nur weil das was der Nachbar nach meine Skizze gebaut
> hat, mir nicht passt.

no comment!