Reihenfolge von defines in fhem.cfg bei nachträglicher Änderung

[CQuadrat]

Hallo Zusammen,

bevor ich hier eine verbale Ohrfeige bekomme: ich editiere die fhem.cfg nicht und definiere und editiere alles per telnet-Session oder Frontend.

Mir ist gestern beim Ansehen der fhem.cfg-Datei zufällig aufgefallen, dass die Definition meines DbLog-Devices (define myDbLog DbLog ...) nach dem ersten Verwenden dieses Device durch diverse SVG-Devices erfolgt. Das hat mich zunächst verwundert und ich hätte Probleme und Fehlermeldungen erwartet (die es aber - zumindest derzeit noch - nicht gibt).

Mittlerweile habe ich eine Vermutung wie es zu dieser falschen(?) Device-Reihenfolgen kommen konnte:

• die SVGPlots basierten ursprünglich auf FileLog
• myDbLog wurde erst nach den SVG-Plots angelegt
• danach wurden die SVG-Plots sukzessive auf myDbLog umgestellt
• die Reihenfolge in der fhem.cfg wurde dabei offensichtlich beibehalten

Meine Frage jetzt: Ist es empfehlenswert die Reihenfolge der defines in der fhem.cfg händisch dahingehend abzuänderen, dass die Definition von myDbLog vor entsprechenden Verwendungen dieses Device erfolgt? Wie gesagt, es funktioniert alles und never touch a running system!

Mein grundsätzliches Verständnis ist, dass in einem define eigentlich kein Bezug zu einem Device genommen werden darf/kann, welches noch nicht definiert ist. Das heißt aber doch, dass bei Deviceänderungen hier durch FHEM eine Prüfung stattfinden sollte wie die Reihenfolge in fhem.cfg ist und ggf. in der fhem.cfg die Reihenfolge geändert werden muss?
Zumindest ist dies meiner Meinung nach eine mögliche Fehlerquelle, derer man sich bewusst sein muss.


Danke und Gruß

Christoph

[betateilchen]

Das hat mich zunächst verwundert und ich hätte Probleme und Fehlermeldungen erwartet (die es aber - zumindest derzeit noch - nicht gibt).
...
Meine Frage jetzt: Ist es empfehlenswert die Reihenfolge der defines in der fhem.cfg händisch dahingehend abzuänderen,

Einfache Regel: Nichts anfassen, was funktioniert

Das heißt aber doch, dass bei Deviceänderungen hier durch FHEM eine Prüfung stattfinden sollte wie die Reihenfolge in fhem.cfg ist und ggf. in der fhem.cfg die Reihenfolge geändert werden muss?

Einfache Regel: Nichts anfassen, was funktioniert

Solange fhem Dich nicht mit einer Fehlermeldung darauf hinweist, dass es ein Problem gibt, weil ein device nicht vorhanden ist, solltest Du nichts an irgendwelchen Reihenfolgen manuell ändern.

[CQuadrat]

Vielleicht sollte ich doch noch auf configdb umsteigen.

Ich vermute mal, dass es dort etwas transparenter und aufgeräumter zugeht.

[marvin78]

Nichts gegen configDB. Der Umstieg ist sicher aus vielen Gründen eine gute Idee, aber trotzdem: Warum interessiert dich, wie aufgeräumt die Config ist, wenn du sie doch nicht direkt bearbeitest? Ich habe in meine letzte Woche zum ersten Mal seit über einem Jahr geschaut und sie ist tatsächlich "Kraut und Rüben" (seit dem kamen etwa 300 Devices dazu), aber das interessiert mich gar nicht, denn in FHEMWEB habe ich ja alles schön geordnet, wie ich es brauche. FHEM findet auch in einer ungeordneten Config alles.

Bei meinem Banking-Progamm interessiert mich übrigens auch nicht, wie die Konfigurationsdaten abgelegt werden....

[CQuadrat]

.. "Kraut und Rüben" ...

Das trifft's! Ich hab' halt ein ungutes Gefühl dabei. Ich mag es da lieber etwas geordnet.
Und erfahrungsgemäß fliegt einem so etwas irgendwann um die Ohren.

[marvin78]

Warum sollte es? Naja. Mach, was du magst. Ich streite mich nicht darüber....

[betateilchen]

Und erfahrungsgemäß fliegt einem so etwas irgendwann um die Ohren.

Mach Dir darüber keine Gedanken. fhem speichert bei einem "save" immer Deine aktuelle laufend Konfiguration ab. Die sollte ja grundsätzlich zu Deiner Zufriedenheit funktionieren.

Du musst komplett umdenken: Die Konfigurationsdatei ist nicht statisch. Sie wird bei jedem "save" komplett neu generiert. Und zwar genau so, wie fhem sie braucht. Dabei gibt es zwischen fhem.cfg und configDB übrigens keinen Unterschied. Auch bei configDB wird exakt die aktuell laufende und funktionierende Konfiguration abgespeichert.

Diese Logik hat sich bewährt und es kommt (hier im Forum nachweisbar!) immer nur dann zu Problemen, wenn Anwender der Meinung sind, schlauer (oder ordentlicher) sein zu wollen als fhem selbst. Man muss schon sehr tief in der Materie drinstecken, um wirklich verstanden zu haben, wie das mit dem Abspeichern der Konfiguration "logisch" abläuft.

[Thorsten Pferdekaemper]

Hi,
aaaaalso... Ich denke mal, dass ich mir einen Fall zusammengebastelt habe, in dem FHEM die cfg nicht ganz so richtig auf die Reihe bekommen hat: Man nehme ein paar Devices, die ueber ein IO-Device laufen. Dann loescht man das IO-Device und legt es neu an. Erstmal ist das kein Problem, es laeuft alles. Dann macht man ein "shutdown restart" und man bekommt eine ganze Latte an Fehlermeldungen im Log und die Devices sind alle weg.
...mal kurz in der cfg nachgesehen und siehe da, die Definition des IO-Devices ist am Ende der cfg. Wenn die Devices, die darauf zugreifen wollen, angelegt werden, dann knallt's.
Moeglicherweise fehlt da auch irgendwo anders etwas, aber zumindest wuerde das nicht passieren, wenn FHEM die cfg automatisch so sortieren wuerde, dass die IO-Devices am Anfang sind.
Gruss,
   Thorsten

[betateilchen]

Dann loescht man das IO-Device und legt es neu an. Erstmal ist das kein Problem, es laeuft alles.

Natürlich führt dieser Spezialfall zu Problemen. Aber warum tut man sowas?

[betateilchen]

zumindest wuerde das nicht passieren, wenn FHEM die cfg automatisch so sortieren wuerde, dass die IO-Devices am Anfang sind.

Dazu müsste es ein eindeutiges Kriterium (z.B.Internal) geben, anhand dessen man ein device als I/O-device "erkennen" kann. Und bisher gibt es sowas meines Wissens nicht.

[rudolfkoenig]

@CQuadrat: Die SVG vs. DB Reihenfolge sollte kein Problem sein, da ein SVG beim Definieren nicht auf die Quellen zugreift, erst wenn es was anzeigen soll. Und das kommt erst, nachdem alles definiert ist. Wg. "Kraut und Rueben": wenn du die DB-Datei mit vi anschaust, schaut es auch nach "Kraut und Rueben" aus, beschweren tut sich aber keiner. Vermutlich sollte ich fhem.cfg nach fhemcfg.bin umbenennen Ueberigens ich habe nichts dagegen, wenn jemand in fhem.cfg was aendert, man sollte sich nur nicht beschweren, wenn nach der Aenderung was nicht funktioniert.

@Thorsten: dein Problemfall stimmt, war aber bisher nicht prominent genug, deswegen ist es nicht gefixt. Auf die Schnelle kann man es "{$defs{IoDeviceName}{NR} = 1 }; shutdown restart" loesen.

@betateilchen: $defs{device}{IODev} ist ein eindeutig.