Rätselhaftes Überschreiben der fhem.cfg

[Prof. Dr. Peter Henning]

Guten Morgen,

zusammen mit Daniel (ext23) stehe ich vor einem Rätsel.

Ich bin inzwischen seit mehr als einem Jahr dabei, ein neues OWX-Backend zu bauen, das sowohl synchron, als auch asynchron laufen kann. Hat sich als schwierig herausgestellt, weil das Timing des 1-Wire Bus zeitkritisch ist - aber läuft inzwischen einigermaßen rund.

Dabei werden dieselben Frontendmodule wie bisher verwendet (na ja, ein paar minimale Anpassungen gibt es schon).

Nun schreibt aber ext23, dass bereits der einfache Ersatz des alten 00_OWX.pm durch das neue 00_OWX.pm dazu führt, dass bei ihm die gesamte Konfigurationsdatei zerschossen wird. Das kann m.E. nur passieren, wenn ein "Save" ausgelöst wird, bevor die Datei komplett eingelesen wurde - aber, um Himmels Willen, wodurch denn ?

Es gibt nur einen strukturellen Unterschied: Das in der Distribution befindliche 00_OWX.pm erwartet Hilfsmodule OWX_SER.pm etc. während das "neue" Hilfsmodule 11_OWX_SER.pm etc. erwartet.

Ich habe jedenfalls die derzeit noch etwas Alpha-mäßige Version des Backends auf allen meinen Systemen im Einsatz, und kein solches Problem, wenn ich eine neue Version aufspiele.

Ärger gab es nur einmal: Bei der Umstellung von 5.7 auf 5.8 hat es beim ersten Start meine config.db zerschossen. Ich weiß aber bis heute nicht, warum - das kam danach niemals wieder vor, war auch schnell behoben.

Ich werde sehen, ob ich ext23 bewegen kann, seine Probleme hier genauer zu schildern.

Die aktuellen Alpha-Versionen hänge ich hier an - aber bitte Vorsicht, nicht einfach irgendwie installieren. Ich möchte nicht, dass jemand sich damit ein Problem einhandelt. Aber vielleicht gibt es ja irgendeinen dummen Fehler, den man durch eine Code-Inspektion finden kann.

LG

pah

[zap]

Irgendein Modul könnte ja während dem Start von FHEM den Save auslösen, oder?

[CoolTux]

Es muss nicht mal ein Modul sein. Es kann auch eine eigene Anwender Sub oder ein Notify sein.

[zap]

Den Status von FHEM (Initialized oder nicht) könnte man aber in CommandSave() abfragen und entsprechend das Speichern verweigern, sofern der Start von FHEM noch nicht abgeschlossen ist. Momentan wird das nicht gemacht, habe gerade in fhem.pl mal nachgeschaut.

[rudolfkoenig]

Stimmt, man koennte aber auch vieles sonst pruefen, was unpausibel ist.
Wie schafft man waehrend des Startens ein save auszufuehren?

[Thorsten Pferdekaemper]

Wie schafft man waehrend des Startens ein save auszufuehren?

Ein Modul schreiben, das im Define CommandSave aufruft?
...oder man schreibt das save direkt in die fhem.cfg rein.
Ich gebe zu, dass das beides ziemlich dämlich wäre, aber möglich. Oder?
(Ich sage damit nicht, dass pah oder ext23 so etwas tun. Ich wollte nur Rudis Frage beantworten.)
Gruß,
   Thorsten

[rudolfkoenig]

Ok, ich korrigiere, ich wollte einen halbwegs sinnvollen Grund fuer save in fhem.cfg haben.
Man kann schliesslich auch "rm -rf /" ins fhem.cfg reinschreiben, ich fuehle mich trotzdem nicht genoetigt, dagegen was zu unternehmen.

[Prof. Dr. Peter Henning]

Hm, Daniel schreibt, dass es sich nicht um ein Save handeln könne.

Hier sein O-Ton (hat hier keine Schreibrechte):

Es geht nicht um ein "Save". Hier wird kein Save ausgeführt, das muss man wenn dann manuell machen! Noch mal kurz zur Problem Beschreibung:
Vorher:
FHEM läuft, keine Änderungen im pending (Also kein rotes Fragezeichen neben "Save config")

Jetzt tausche ich die 00_OWX aus und starte FHEM neu (shutdown restart oder service fhem restart, egal)

Nachher:
FHEM läuft, aber ich sehe jetzt das rote Fragezeichen, schaue ich dort rein sehe ich die maximal anzuzeigender Änderungen (10 oder so). Da ist aber ALLES drin, also wenn ich jetzt save drücke, wird die gesamte config neu geschrieben. Das habe ich einmal gemacht, danach lief aber einiges nicht. Vermutlich macht er nicht alles richtig.
Mache ich aber bevor ich ein save mache ein "rereadcfg" ist alles OK, das Fragezeichen ist auch weg. Aber nur bis zum nächsten Neustart!

Vielleicht hilft die Beschreibung etwas besser. Also es wird hier kein automatisches Save ausgelöst, das ist falsch.

Ich verstehe aber jetzt noch weniger, als vorher, was hier abläuft.

LG

pah

P.S.: So trottelig, dass ich während der Initialisierung des Moduls ein Save ausführe, bin ich nun doch noch nicht.

LG

pah

[Thorsten Pferdekaemper]

P.S.: So trottelig, dass ich während der Initialisierung des Moduls ein Save ausführe, bin ich nun doch noch nicht.

Deshalb habe ich je extra das hier geschrieben:

(Ich sage damit nicht, dass pah oder ext23 so etwas tun. Ich wollte nur Rudis Frage beantworten.)

Jetzt zu der Problembeschreibung:
Das sieht eher so aus, dass FHEM die fhem.cfg komplett liest, aber dann am Ende der Meinung ist, dass das alles nicht in der fhem.cfg steht. Woher weiß eigentlich FHEM beim Starten, dass die ganzen defines etc. aus der fhem.cfg kommen und nicht danach vom Benutzer eingegeben warden? Vielleicht geht bei diesem Mechanismus was schief.

Gruß,
   Thorsten

[rudolfkoenig]

FHEM läuft, aber ich sehe jetzt das rote Fragezeichen, schaue ich dort rein sehe ich die maximal anzuzeigender Änderungen (10 oder so). Da ist aber ALLES drin, also wenn ich jetzt save drücke, wird die gesamte config neu geschrieben.

Das rote Fragezeichen gibt @structChangeHist aus. Dieser wird von jedem attr/define/modify/delete/deleteattr/rename gefuellt, aber nur wenn $init_done nicht wahr ist. Evtl. wird $init_done von jemandem zu frueh auf 1 gesetzt. Sollte aber trotzdem nicht direkt fuers kaputtschreiben der fhem.cfg verantwortlich sein, hoechstens auf einem mir noch unbekannten indirekten Weg.

Ich sehe gerade, dass 70_SCIVT.pm, 70_SISPM.pm und 70_TellStick.pm temporaer init_done auf 1 setzen, statt den letzten Parameter von InternalTimer auf 0. Sollte aber keine Auswirkungen haben.

[justme1968]

@rudi: $waitIfInitNotDone=1 im InternalTimer funktioniert sowieso nicht. zumindest nicht so wie man es erwarten würde. das warten ist blockierend und in fhem ändert sich nichts. die drei module oben könnten also ihre routine auch direkt aufrufen. oder ein perl sleep verwenden.

zumindest 70_SCIVT.pm setz readings und triggert events bevor fhem richtig läuft. da $init_done temporär umgebogen wird kann ich mir schon szenarien vorstellen bei denen dann etwas schief geht. aber ich glaube eher nicht das es im zusammenhang dieses threads relevant ist.

ich denke waitIfInitNotDone sollte entfernt/ignoriert werden und das umbiegen von init_done verboten.

zu dem konkreten problem hier: ein stacktrace aus CommandSave müsste helfen zu identifizieren ob es wirklich an einem save liegt.

[CoolTux]

@rudi: $waitIfInitNotDone=1 im InternalTimer funktioniert sowieso nicht. zumindest nicht so wie man es erwarten würde. das warten ist blockierend und in fhem ändert sich nichts.

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.

[Prof. Dr. Peter Henning]

Hier noch eine weitere Beschreibung von ext23:

Hinter dem Fragezeichen sieht man ja alle Änderungen die im "pending" sind, also alles was in den config files geändert wird "wenn" man save drückt. Dort werden aber nur maximal 10 Sachen angezeigt. Die Liste ist in Wirklichkeit aber länger also dort steht dann alles drin was ich als define auf dem System habe. Drücke ich dann save, schreibt der alle config files neu. Ich habe das nur ein mal gemacht, dann wurden aber alle 1-Wire Geräte irgendwie neu angelegt mit neuen namen etc. Habe ich in die config files geschaut fehlten viele Einträge. Ich habe dann nur noch die Kommentare gesehen. Eventuell sind die Änderungen auch in die Hauptkonfiguration (fhem.cfg) gerutscht, das weiß ich nicht. Ich habe mir das nicht so genau angeschaut.

Aus meiner Sicht ist diese Beschreibung immer noch nicht zielführend. Aber es kristallisiert sich ein Verdacht heraus, um dessen Bestätigung ich Daneil jetzt gebeten habe:

2. Kann es sein, dass die Defines der ganzen 1-Wire-Geräte in untergeordneten cfg-Dateien liegen ? 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 ?

LG

pah

[CoolTux]

Das wäre endlich mal eine wirklich plausible Begründung. Auf die Antwort bin ich mega gespannt. pah bitte sei so nett und gib uns das Ergebnis dann hier bekannt. Danke

[CoolTux]

Code Auswählen Erweitern

Ich glaube ich kann Deine Frage beantworten. Unsicher zwar aber

[quote]
Eine Frage, ich habe die Config Files alle nach Räumen aufgeteilt und mit
include eingebunden. Das funktioniert auch ganz gut wenn man bei einiges
Sachen die Reihenfolge beachtet. Ich stelle nur immer wieder fest, dass
meine 3 AT Jobs immer wieder in die Hauptconfig wandern nachdem neue Geräte
durch autocreate hinzugefügt würden.

Ist das noch ein kleiner Fehler oder irgendwie bedingt durch den Aufbau?

Und dann hätte ich ja noch einen kleinen CR anzumelden ;-) Es wäre ganz
praktisch wenn die mit include eingebundenen Config Files auch über die
Webseite editierbar wären.

Viele Grüße
Daniel


Unsicher daher, weil diese Aussage aus dem Jahr 2012 stammt.

[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.

[Thorsten Pferdekaemper]

eine reorganisation in package wäre eine große und nicht kompatible änderung.

Wieso das denn? Ich rede ja nicht davon, die fhem.pl in ein anderes Package zu verschieben, sondern nur in den Modulen. Es ist mir auch klar, dass man das nicht einfach so für jedes Modul schnell mal ändern kann, aber für neue Module sollte man es "verlangen".

das absichtliches überschreiben lässt sich damit auch nicht verhindern.

Nein, das natürlich nicht.

das versehentliche nur bedingt.

Zumindest das hier beschriebene Problem wäre nicht aufgetreten, oder?

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

Welche?
Ich habe das selbst schon so gemacht. Nur die Funktion <module>_Initialize muss man im main-Package lassen, weil sie ansonsten natürlich nicht gefunden wird. Alles weitere kann man in ein eigenes Package legen. Zumindest bei meinem Roomba980-Prototyp funktioniert das.

Gruß,
   Thorsten

[papa]

Eine langfristige Lösung kann eigentlich nur das Unterbinden von ungeprüften Manipulationen der internen Datenstrukturen sein. Das sollte nur über eine entsprechende API möglich sein. Für $init_done könnte das z.B. so aussehen:

• Zugriffsfunktionen implementieren: isInitDone(), setInitDone()
• Zeitfenster zur Migration der Module definieren
• globale Variable $init_done umbenennen und am besten "privat" machen - keine Ahnung, ob das in Perl möglich ist

Die Manipulationsfunktionen könnten dann auch gegebenenfalls eine Prüfung der Argumente vornehmen oder checken, ob eine Manipulation gerade erlaubt ist (Statemachine oder ähnliches Prüfen).

[Thorsten Pferdekaemper]

Das ist jetzt aber wirklich etwas viel Aufwand. ...zumindest wesentlich mehr als meine Idee.
Gruß,
   Thorsten

[Benni]

Das ist jetzt aber wirklich etwas viel Aufwand.

Aber entspricht im wesentlichen auch dem Ansatz, den auch die Funktionen ReadingsVal, AttrVal und InternalVal, sowie die readings.*Update() (und div. andere) zumindest teilweise bereits verfolgen.

Für meinen Geschmack jedenfalls logischer und übersichtlicher, als die Package-Lösung.

[justme1968]

da es niemand von außen setzen soll reicht doch ein isInitDone. setInitDone braucht es garnicht.

das problem ist hier eher das schon alle möglichen module $init_done verwenden und es sich nicht einfach umstellen lässt.

es nützt glaube ich auch nicht wirklich etwas sich an dieser einen variable fest zu beissen. in den ganzen letzen jahren gab es ja scheinbar erst ein mal ein problem damit.

@Thorsten Pferdekaemper: je nach dem wie man genau was in welcher reihenfolge macht führt das verenden von namespaces unter anderem dazu das externe pakete die unter einem namespace geladen werden auch (nur) innerhalb des namespace landen. das gegenseitige abschotten ist zwar gut, aber ich glaube das sie dann auch mehrfach geladen werden. das geht bei modulen wie xml und json schon etwas in den speicher. zumindest auf den ganzen kleinen kisten. auch ist dann z.b. Data::Dumper nicht mehr 'einfach da' sondern muss wenn man man schnell auf der kommandozeile etwas ausgeben will.

d.h. unabhängig davon ob man die änderungen positiv oder negativ bewertet muss man die nebenwirkungen beachten.

[zap]

Ich halte den Vorschlag von papa für den einzig sinnvollen. Oder man lässt alles wie es ist.

Eigentlich hätte man für jede globale Variable in fhem.pl gleich entsprechende Zugriffsfunkionen (is/set/get) zur Verfügung stellen müssen. Aber hätte, hätte, Fahrradkette

Zu spät ist es noch nicht, aber aufwändig:

1. Funktionen bereitstellen
2. Modulautoren bitten, alle Module anzupassen sofern sie eine globale Variable verwenden
3. Ein Prüfscript schreiben, das die Verwendung globaler FHEM Variablen in den Modulen prüft. Falls welche gefunden werden, den Modulautor nochmal anschreiben.
4. Bei Aufnahme neuer Module in SVN prüfen, ob globale Variablen verwendet werden. Eine einfache Prüfung auf $varname sollte genügen.

[viegener]

Mir erscheint es als erster Schritt am einfachsten mal kurz zu listen welche globalen variablen in Modulen (vielleicht auch durch Gruppierung in fhem.pl):
- gelesen werden können --> sprich z.B. init_done (gibt es wirklich szenarien in denen ein normales Modul das setzen sollte )
- verändert werden dürfen --> z.B: in gewissen Grenzen %attr etc
- nicht angefasst werden sollten --> subject to change without notice

[Thorsten Pferdekaemper]

@Thorsten Pferdekaemper: je nach dem wie man genau was in welcher reihenfolge macht führt das verenden von namespaces unter anderem dazu das externe pakete die unter einem namespace geladen werden auch (nur) innerhalb des namespace landen. das gegenseitige abschotten ist zwar gut, aber ich glaube das sie dann auch mehrfach geladen werden. das geht bei modulen wie xml und json schon etwas in den speicher. zumindest auf den ganzen kleinen kisten. auch ist dann z.b. Data::Dumper nicht mehr 'einfach da' sondern muss wenn man man schnell auf der kommandozeile etwas ausgeben will.

Soweit ich das verstehe, werden zumindest Module, die man mit require lädt, nur einmal geladen. Das mit dem mehrfach "Laden" betrifft das import (implizit durch use). Dadurch kommen die vom Modul exportierten Symbole in den jeweiligen Namespace. Das dürfte aber nicht viel Speicherplatz kosten. Data::Dumper wäre dann trotzdem noch da, so lange irgend jemand das "require"t. Nur wenn ein Modul etwas "use"t, dann müsste man, wenn man die entsprechende Funktion/Variable von woanders verwenden will, sie entweder dort auch importieren oder halt "<Modul>::" vorne dran setzen.
Ausprobiert habe ich das alles nicht...

d.h. unabhängig davon ob man die änderungen positiv oder negativ bewertet muss man die nebenwirkungen beachten.

Da stimme ich voll zu.

Das mit den Zugriffsfunktionen hilft übrigens nichts, solange alles im package main ist. ...denn dann kann es immer noch relativ leicht passieren, dass ein Modul "aus versehen" auf eine globale Variable eines anderen Moduls (oder fhem.pl) zugreift.

Gruß,
   Thorsten

[justme1968]

wie gesagt ist es ein abwägen. wenn man die namespace vorteile auch für pakete möchte um z.b. konflikte mit unterschiedlichen parametern zu vermeiden (ist z.b. bei xml schon mehrfach vorgekommen) kostet es den speicher. und das wäre ein anwendungsfall der tatsächlich schon ein paar mal vorgekommen ist.

[betateilchen]

Die ganze Diskussion über is/set/get<globaleVariable> ist doch müssig, solange selbst in neuen Modulen (beispielsweise) immer noch $hash->{STATE} von den Modulautoren hart beschrieben wird anstatt das entsprechende reading state zu verwenden und dem Anwender die Freiheit zu lassen, STATE nach seinen Wünschen zu formatieren.

[Prof. Dr. Peter Henning]

Auch das ließe sich mit einer Konformitätsprüfung in einen Warnhinweis überführen.

LG

pah

[justme1968]

die frage ist ob uns eine warnung bzw. prüfung beim einchecken reicht oder ob es nicht besser ist zu versuchen die 'altlasten' aktiv anzugehen und alle module aktiv anzupassen.

ersteres ist zwar sehr viel weniger aufwand, der effekt hält sich aber in grenzen und 'alte' module veralten immer mehr.

letzteres ist deutlich aufwändiger aber der code bleibt längerfristig auf einem aktuellen stand und neuerungen lassen sich besser einführen.

[Prof. Dr. Peter Henning]

Einverstanden. Das wäre also eine einfache Routine zum Codecheck aller Module - mit kurzem Elektroschock für die Maintainer, ihren Code gefälligst anzupassen.

LG

pah