Fhem.cfg Kommentare und Gliederungen

[Mopedpaul]

Hallo,
seit längerem benutze ich schon das Fhem System, aber ab und an bekomme ich immer wieder Probleme mit der Gliederung und bei Kommentaren in der Fhem.cfg

Da die Größe der Config Datei ja stetig wächst, muss man ja irgend wie noch die Übersicht behalten. Das mache ich, in dem ich bestimmte Teile in include Dateien auslagere, und die Fhem.cfg gliedere und mit Kommentaren versehe.
z.Bsp

include heizung.cfg
###### FS 20 Komponenten ************************


Auch beim Test einer neuen Funktion gehe ich schon einmal hin, wenn es nach dem Testen nicht ganz so rund läuft, um Kommentiere die neuen Programmzeilen mit einem # Zeichen am Anfang der Zeile aus, bis ich wieder weitere Funktions Teste durchgeführt habe und die Funktion zufriedenstellend läuft.

Aber das eigentliche Problem:

Manchmal ist nach einem Update oder "save fhem.cfg" die ganze fhem.cfg wieder , ich sage mal "gereinigt" - alle Formatierungen und Kommentare sind weg. Zu Letzt waren auch plötzlich alle include Befehle einfach gelöscht - das nervt unheimlich.

Wie kann man solche unerwünschten Eigenmächtigkeiten von Fhem abstellen - wie macht Ihr das.  

MfG Uwe

[Puschel74]

Hallo,

wie macht Ihr das

Mein Haupt-FHEM läuft und läuft und läuft.
Da geh ich nur dran wenn ich was neues implementiere.

Getestet wird bei mir entweder auf der 7390 oder auf einem RasPi der nur für solche Testzwecke sein Dasein fristet.

Bevor ich den neuen Code auf mein Haupt-FHEM los lasse wird erstmal von der bestehenden Installation (der Ordner /opt/fhem)
eine Sicherungskopie per WinSCP gezogen.
Dieses Backup wird nochmal kopiert und in dieser Kopie wird der neue Code eingepflegt.
Die relevanten Teile der Konfiguration (fhem.cfg und/oder zugehöriges include-File) werden danach per WinSCP wieder auf den
RasPi kopiert.
Währenddessen läuft auf dem RasPi ein update und upgrade.
Nach dem Rückkopieren der Konfig wird entweder fhem oder der komplette RasPi neu gestartet.

Aufwändig?
Vermutlich, aber das stört mich nicht.

Grüße

[Mopedpaul]

Hallo Puschel,
mag ja aufwändig sein, Dein System, aber es ist noch viel aufwändiger irgend welche zerschossenen cfg Dateien wieder herzustellen. Von daher werde ich wohl auch die Finger vom eigentlichen "Betriebs-FHEM" lassen und neue Funktionen auf dem Pi testen. Mein FHEM läuft auf eine FB 7390 ein Pi hängt schon mit im Netzwerk mit installiertem FHEM hat aber noch nichts zu tun.

Ich merke schon ,worauf es hinaus läuft -sichern - sichern -sichern.

Danke für Deine Infos

MfG Uwe

 

[betateilchen]

Ich merke schon ,worauf es hinaus läuft -sichern - sichern -sichern.

läuft bei mir per cronjob jede Stunde (cfg-Dateien und die addon-Dateien wie z.B. RSS-Layoutdateien) und ich war schon zweimal sehr froh über die vorhandenen Sicherungsdateien.

Außerdem steht in meiner fhem.cfg nur eine einzige include Zeile:

Code Auswählen Erweitern

include testinclude.cfg

In der Datei testinclude.cfg stehen dann alle anderen Definitionen:

Code Auswählen Erweitern


# Include Datei für GDS laden
include gds.cfg

# Include Datei für OWO laden
include owo.cfg


In den beiden Dateien gds.cfg und owo.cfg befinden sich dann die eigentlichen Definitionen.

Das hat den Vorteil, dass bei einem eventuellen Überschreiben der fhem.cfg lediglich eine einzige Zeile verlorengeht. Und das ist ja schnell und problemlos wieder repariert.

[Mopedpaul]

Hallo,
solch ein Testsystem im Fhem Netzwerk ist sicherlich eine tolle Sache. Aber was mache ich, wenn ich direkt Devices z.Bsp anlernen , auslesen , oder steuern will. Kann man die Fhem Interface wir der CUL, der bei mir direkt per USB an der FB 7390 hängt auch über z. Bsp einen Pi im Netzwerk ansprechen obwohl es USB mäßig an der FB hängt ? Und wie verhält es sich mit Netzwerk Interfaces wie dem CUNO , AVR NetIO oder HM Lan Adapter, kann ich diese Interfaces gleichzeitig auf 2 Fhem Systemen nutzen die per Fhem2Fhem verbunden sind ?
Denn sonst stelle ich mir das mit dem Testen von Funktionen, so wie Puschel es beschrieben hat, schwierig vor, ohne das Hauptsystem an zufassen. Das mit dem Auslesen scheint ja bei den Komponenten zu funktionieren, die nach dem Lesen ,oder bei Temp/Feuchte Sendern nach dem autom Senden, die Infos auf beiden Systemen aufteilen.

MfG Uwe

[Puschel74]

Hallo,

steuern oder anlernen kann ich mit meinem "Testsystem" in dieser Form natürlich erstmal nichts.
Das will ich aber auch garnicht.

Geräte werden bei mir schon länger nichtmehr per autocreate angelegt.
Das mache ich händlisch und kann das daher auch durchaus auf dem Testsystem erledigen.

Um einen Code zu testen benötige ich nicht zwingend einen Aktor den ich schalten lassen muss.
Mir genügen dafür schonmal die passenden Logausgaben die ich in meinen Code einbaue (und danach wieder entferne).

Auf Ereignisse kann ich allerdings auch auf meinem Testsystem reagieren.
fhem2fhem macht das wunderbar möglich.

Wenn ich nun also einen Code testen will der, so wie jetzt gerade, auf eine Änderung von Twilight reagiert schreibe ich den Code auf meinem Testsystem.
Das ist sowieso immer per fhem2fhem mit meinem Haupsystem verbunden.
Wenn nun also auf dem Hauptsystem Twilight ein Statusupdate macht reagiert auf meinem Testsystem das notify.
Der Code wird abgearbeitet und die entsprechnenden Logeinträge ins Logfile des Testsystems geschrieben.
Wenn alles so läuft wie ich mir das vorstelle werden die Logeinträge wieder gelöscht und an deren Stelle werden dann die Aktoren eingetragen.
Das die Aktoren funktionieren weiß ich ja.

Selbst ein Test auf einen Sender ist so möglich.
Erst den Sender im Hauptfhem definieren und anlegen (das geht auch per autocreate wenn man das will).
Danach einfach die jeweilige Taste drücken - per fhem2fhem bekommt das auch das Testsystem mit.
Code durchtesten und danach auf das Hauptsystem übertragen.

Grüße