leichteres Navigieren in der fhem.cfg --> Zeilennummerierung

[CoolTux]

Dagegen, bis man mich eines besseren belehrt hat.
Einwand. Perlcode für  FHEM interner. Wer von Euch weiß genau was diese Änderung eines INTERNALS genau bedeutet? Was passiert mit der Sortiernummer davor und danach? Was passiert wenn der Normaluser sich vertut?

@ Udo, kann mich erinnern das es Mal einen Thread um das INTERNAL NR gab. Hatte Rudi da nicht was geändert oder gar NR entfernt. Weißt Du noch was genau das Ergebnis war?

[CoolTux]

@Udo
Meine Frage hat sich erledigt. Es ging um die Umnummerierung nach einer Änderung der Deviceeigenschaften.


Grüße

[Benni]

Mein vote wäre für "Tipp der Woche"...

Na ja, so prominent würde ich es nicht aufhängen, da es auch nur in Ausnahmesituationen verwendet werden sollte.
Genauer gesagt nur dann wenn, wie im Fall von Otto geschildert, ein IO-Device zwingend vor einem, davon abhängigen Device definiert sein muss.
Ich würde das wenn, dann auch nur genau in diesem Kontext präsentieren.

Ansonsten kommt noch einer auf die Idee er könnte sich seine gesamte cfg so zurechtsortieren 
(dann hätten wir außer Fußpilz auch noch Herpes und irgendwann juckt es dann überall   )

[KernSani]

Meiner Erfahrung nach sortieren sich Devices ohnehin in den allermeisten Fällen wieder korrekt ein, wenn man die DEF oder das IODev attribut ändert...

[CoolTux]

Meiner Erfahrung nach sortieren sich Devices ohnehin in den allermeisten Fällen wieder korrekt ein, wenn man die DEF oder das IODev attribut ändert...

Genau das soll nach meinem Verständnis ja nicht mehr so sein. So interpretiere ich zu mindest Rudi seine Aussage aus einem anderen Thread. Das mit dem Umnummerieren hat er wohl raus genommen.


Grüße

[Benni]

Meiner Erfahrung nach sortieren sich Devices ohnehin in den allermeisten Fällen wieder korrekt ein, wenn man die DEF oder das IODev attribut ändert...

Ich habe damit leider auch schon so meine Erfahrungen gemacht.
Problematisch war dabei v.a., dass die Symptomatik für mich erst mal gar keinen Hinweis auf das ursächliche Problem geliefert hat.

Und ich finde, dass das Nach-Vorne-Sortieren des IOs die einfachere und schnellere Variante ist (zumindest mit betateilchens Kniff), als zig DEF oder IODev anzufassen.

[betateilchen]

Bitte keinen Wiki Eintrag daraus machen. Ich hoffe, dass auch dieser Thread irgendwann wieder in der Versenkung verschwindet, wo er hingehört.

Der beschriebene Weg ist weder eine empfohlene Vorgehensweise, geschweige denn eine "Lösung".
Es ist einfach nur ein böser Hack, der meistens das tut, was man erwartet. Meistens bedeutet "nicht immer".

Eigentlich wollte ich nur meine Aussage, man könne auch dieses "Problem" im Frontend beheben, belegen.

[Beta-User]

Ist angekommen, jedenfalls ich werde keinen Wiki-Eintrag erstellen...
Thread verbleibt in meiner "Gift-Link-Liste" für den Fall, dass ich tatsächlich mal "so ein" Problem haben sollte.

Nur am Rande:
Dass eine "automatische" Sortierung stattfindet, deckt sich jedenfalls nicht mit meinen Beobachtungen in den Backups der config, die ich hin und wieder aus der configDB raushole. Das Ausgangsproblem mit der Sortierung "erst IO, dann nutzende Devices" innerhalb der config hat sich aber wohl schlicht dadurch deutlich verringert, dass die meisten Modulentwickler zwischenzeitlich den Aufbau so haben, dass dies nicht mehr zwingend erforderlich ist.

[betateilchen]

dadurch deutlich verringert, dass die meisten Modulentwickler zwischenzeitlich den Aufbau so haben, dass dies nicht mehr zwingend erforderlich ist.

Das ist auch eindeutig der bessere - und empfohlene - Weg.

[Beta-User]

Für den Fall

Das ist auch eindeutig der bessere - und empfohlene - Weg.

Bin da völlig mit einig, man will sich als user ja nicht mit sowas rumschlagen müssen  .

Für den Fall, das der somfy (und/oder IT) - Modulentwickler versehentlich hier mitliest: Könnt Ihr euren Code mal dahingehend prüfen? (siehe hier: https://forum.fhem.de/index.php/topic,69558.msg610806.html#msg610806)

[Ralf9]

Das Ausgangsproblem mit der Sortierung "erst IO, dann nutzende Devices" innerhalb der config hat sich aber wohl schlicht dadurch deutlich verringert, dass die meisten Modulentwickler zwischenzeitlich den Aufbau so haben, dass dies nicht mehr zwingend erforderlich ist.

Ist dies irgendwo beschrieben wie der Aufbau sein muss, dass dies ("erst IO, dann nutzende Devices") nicht mehr zwingend erforderlich ist?

Gruß Ralf

[Dietmar63]

Code Auswählen Erweitern


{$defs{dummy3}{NR}=2}


Wenn man das macht muss man dann nicht damit rechnen, dass Nummern doppelt vergeben werden, und dass dann etwas verschwindet?

[Beta-User]

Ist dies irgendwo beschrieben wie der Aufbau sein muss, dass dies ("erst IO, dann nutzende Devices") nicht mehr zwingend erforderlich ist?

Gruß Ralf

Wenn ich das richtig interpretiere, ist hier die Antwort von Rudi zu finden:
https://forum.fhem.de/index.php/topic,62653.msg584897.html#msg584897

Gruß, Beta-User

[justcallmeal]

Und es gibt wirklich nur einen Grund die fhem.cfg mit Hand zu editieren.
Also einfach die Oberfläche nutzen  und die letzen Änderungen stehen auf dem roten Fragezeichen.

Hallo zusammen,
zunächst mal vielen Dank für die mittlerweile 4 Seiten hilfreicher Antworten. Vielleicht habe ich mich ja falsch ausgedrückt, aber ich editiere die fhem.cfg schon via Webaufruf 192.XXX.XXX.XXX:8083/fhem, indem ich im Spaltenmenü unten links "edit files" auswähle und anschließend auf "config file" die fhem.cfg auswähle. Mein Wunsch nach Zeilennummerierung bezieht sich demnach auf das große Eingabefenster, in dem die ganze fhem.cfg drinsteht.  Oder meint ihr das alle, das man das nicht machen sollte?


...leicht irritiert,
al

[Benni]

Oder meint ihr das alle, das man das nicht machen sollte?

Ja!