Rätselhaftes Überschreiben der fhem.cfg

[rudolfkoenig]

Kann ich bestättigen. Ich hatte eine 1 als zweiten InternalTimer Wert in meinem PLAYBULB Modul im Define Teil und da ich 8 Devices hatte hat sich das starten von FHEM ewig hingezogen.

Bin verwirrt. Der Parameter nennt sich $waitIfInitNotDone. Wieso beschwert man sich, dass es genau das tut? Default ist 0, d.h. man muss es schon explizit auf 1 setzen, damit es waehrend des inits wartet.

Und dass die 1-Wire Geräteerkennung so früh los läuft, dass diese Geräte einfach mit den Default-Namen in der Haupt-Konfiguration neu angelegt werden, weil sie schon auf dem Bus gefunden wurden, bevor die (alten) Defines gelesen wurden ?

Ich gehe davon aus, dass die Erkennung nicht "blockierend aus dem define" ausgefuehrt wird. Dann sollte auch nichts schiefgehen, da waehrend des Einlesens von fhem.cfg+fhem.state select noch nicht aktiv ist, d.h. die Module nicht per ReadFn benachrichtigt werden, und auch InternalTimer ist (bis auf dem "unverstandenen" Flag) verzoegert.

[Prof. Dr. Peter Henning]

Vor allem aber wird das erstens seit Jahren genau so gemacht, und hat zweitens noch nie solche Probleme verursacht. Bis ich auf die configdb gewechselt bin, habe ich auch einen ganzen Zoo von Konfigurationsdateien unterhalten.

Ich versuche jetzt mal, die Device-Erkennung zu verzögern, bis wirklich alle defines gelesen wurden.

LG

pah

[CoolTux]

Bin verwirrt. Der Parameter nennt sich $waitIfInitNotDone. Wieso beschwert man sich, dass es genau das tut? Default ist 0, d.h. man muss es schon explizit auf 1 setzen, damit es waehrend des inits wartet.

Ach Rudi, das fragst Du mich wirklich. ICH bin es, das sollte die Frage an sich schon beantworten 
Mal habe ich gute und mal schlechte Tage, das war mal ein schlechter. Ich hatte mich damals einfach vertippt und und den Zusammenhang nicht gefunden 



Grüße

[Prof. Dr. Peter Henning]

det. hat sich jetzt mit folgender Beobachtung angeschlossen:

da ich selbige "Erscheinung" auch hatte, vor einigen Wochen (ich berichtete das und fühlte mich damit leider überhaupt nicht ernst genommen), noch mal meine Anmerkungen zu dem Thema. Bei mir fehlte nach Austausch der OWX Module durch die Neuen und anschließendem Neustart ca. 60% der Zeilen in der fhem.cfg und zwar nicht spezifisch welche, die mit OWX zu tun hatten, sondern auch z-wave Gerätedefinitionen, Wetter, Holiday etc. ... Der Umstieg auf 5.8 war bei mir vorher und ohne Komplikationen, daran lag es nicht.


Peter, kannst Du Deine Neuentwicklung mal auf deutlich schnellerer Hardware (Intel Plattform >2GHz, Dualcore) testen, um auszuschließen, das es sich um Timingprobleme handelt. Die alten asynchronen Module von Norbert liefem bei mir auch nur auf dem RPI und auf dem schnelleren Server nicht.
Dagegen laufen Deine bisherigen Module bei mir so gut, das ich auf die asynchrone Weiterentwicklung gerne verzichten kann.

Hm. Würde meiner oben gemachten Vermutung widersprechen.

LG

pah

[Prof. Dr. Peter Henning]

Und es gibt noch mehr:

Wird vermutlich nicht helfen, aber exakt dieses Problem hatte ich auch vor einigen Wochen mit einer Testversion von OWX.
Hat mit meine komplette Config zerschossen sodaß ich das FHEM komplett neu aufsetzen musste.
Zum "Glück" war es "nur" der Raspi auf dem "nur" meine 1-Wire-Devices laufen und nicht mein Haupt-FHEM.

Ich hatte es da als Anwenderfehler verbucht, aber scheinbar war es das nicht...?

grtz
CmdA

*fingerheb*
Ich auch. Ab einer bestimmten OWX-Version wurden beim Start von FHEM sämtliche include-Verweise gelöscht. Ich hatte die 1-Wire-Device-Definitionen, FHT, HM485 und einiges andere in externe cfg-Dateien ausgelagert. Die defs der Busmaster usw. standen am Anfang der fhem.cfg. Hat auch lange Zeit funktioniert, bis eben ab einer OWX-Version (schon länger her, nicht mehr nachvollziehbar welche) beim Start dann die includes weg waren und dann alle Devices neu eingelesen wurden. Somit war "shutdown restart" tabu, ich musste auf der Konsole beenden, das Backup der fhem.cfg einspielen und starten...manchmal bis zu 3 Mal, bis es funktioniert hat.
War mir bisher nicht sicher, ob es an OWX gelegen hat, aber wenn ich das hier so lese...
Bin dann später auf configDB umgestiegen, da war der Spuk zu Ende.

Gruß
Uwe

Sehr rätselhaft. Und unabhängig davon, ob hier ein doofer Fehler in der Testversion vorliegt: Das müssten wir schon irgendwie verstehen, sonst besteht die Gefahr, dass es noch irgendwo anders auftritt.

LG

pah

[Prof. Dr. Peter Henning]

Nach längerem Suchen ist die Ursache gefunden und in der Testversion von 00_OWX.pm behoben - das Problem liegt aber tiefer und sollte noch an anderer Stelle angegangen werden, sprich, in fhem.pl. Was ist nun die Ursache gewesen:

1. Auf Grund des vielschichtigen Initialisierungsprozesses in OWX (FHEM-Device, Hardware, Busmaster und Bus) gab es eine lokale Variable $init_done. Bei einer der Änderungen im Ende 2016 habe ich den Block auskommentiert, in dem "my $init_done;" deklariert wurde.

2. Damit griff das Modul auf die globale Variable $init_done zu und setzte diese auf 1, sobald der 1-Wire Bus initialisiert war.

3. Unter FHEM 5.7 bewirkte das offensichtlich gar nichts, normaler Start.

4. Unter FHEM 5.8 sorgte das dafür, dass der Initialisierungsprozess auch an anderer Stelle gestoppt wurde, insbesondere, dass die "include"-Direktiven in der Konfigurationsdatei ignoriert wurden. Damit fehlten dann wesentliche Stücke von komplexeren Installationen, 1-Wire Devices waren aber auf Grund der Tatsache, dass der Bus schon gescannt war, unter ihrem generischen Namen vorhanden.

5. Weder bei Leuten mit einer einzigen Konfigurationsdatei, noch bei denjenigen, die configDB verwenden, zeigte sich diese Auswirkung. Sie ist offenbar auch abhängig von der allgemeinen Systemgeschwindigkeit, und davon, wie schnell die jeweilige Hardware initialisiert war.

LG

pah

[rudolfkoenig]

Unter FHEM 5.8 sorgte das dafür, dass der Initialisierungsprozess auch an anderer Stelle gestoppt wurde, insbesondere, dass die "include"-Direktiven in der Konfigurationsdatei ignoriert wurden.

Das kann ich so nicht nachvollziehen.

Ich sehe aber, dass in diesem Fall das include Statement nicht  gemerkt wird (sozusagen als "Kommentar"). Die Befehle aus der include werden normal ausgefuehrt, save sollte auch alles normal speichern, bis auf die include Statements. Nach einem restart fehlt natuerlich dank fehlenden include Zeilen einiges.

Fix: include Zeilen manuell wieder einfuegen.

[Prof. Dr. Peter Henning]

Das ist zwar als temporäre Reparatur ok, aber die Frage ist, ob das Problem nicht ganz vermieden werden kann.

Ideal wäre, wenn wir eine Testroutine hätten, die nicht nur beim Einchecken, sondern auch manuell aufrufbar bestimmte Kompatibilitäten eines Moduls überprüft.

Nicht nur, ob die Doku alle Bestandteile enthält. Sondern beispielsweise auch, ob bestimmte globale Variablennamen im Modul auftauchen (z.B. $init_done).

LG

pah

[rudolfkoenig]

Auftauchen alleine ist ja nicht schlimm, erst wenn sie geaendert wird.
Das zu pruefen duerfte nicht ganz trivial sein.

[Prof. Dr. Peter Henning]

Ich denke einfacher - der reguläre Ausdruck

<Variablenname>.*=

sollte für einen Warnhinweis ausreichen.

LG

pah

[rudolfkoenig]

return if($init_done == 0);
if($init_done) $a="b";

[justme1968]

oder in callFn den wert sichern und nach dem return prüfen. damit wäre zumindest das versehentliche überschreiben abzufangen.

statt sichern könnte fhem.pl auch eine zweiten interne variable verwenden und prüfen das beide immer gleichen wert haben.

[rudolfkoenig]

Sowas waere aber eher was fuer 98_fhemdebug.pm.

[Thorsten Pferdekaemper]

Hi,
das Problem nur für $init_done anzugehen wäre doch etwas zu kurz gesprungen, oder? Meiner Meinung nach liegt das Grundproblem darin, dass praktisch alles im package main liegt. Natürlich ist das jetzt nicht ganz so einfach zu ändern, aber vielleicht sollten wir den Modulautoren ans Herz legen, jedem Modul ein eigenes package zu geben. Dann kann es nicht mehr passieren, dass man aus versehen eine globale "main"-Variable benutzt, wenn man eigentlich eine lokale meint.
Man muss dann nämlich explizit $main::init_done hinschreiben, und dann ist man wirklich selbst schuld.
Gruß,
   Thorsten

[justme1968]

eine reorganisation in package wäre eine große und nicht kompatible änderung. das absichtliches überschreiben lässt sich damit auch nicht verhindern. das versehentliche nur bedingt.

packages für module haben auch noch andere aspekte bzw. nebenwirkungen die man zumindest berücksichtigen müsste.