Gelöst - Manuelle Bearbeitung fhem.cfg

[ftsinuglarity]

Auf die Gefahr hin, das du vollends genervt bist betateilchen, warum kein Wiki Eintrag, wenn das Thema so nervt und damit abgekürzt werden könnte?
Um Einsteiger nicht zu motivieren doch direkt zu editieren ?

Vielleicht mit nem fetten WARNING, es gibt keine Hilfe wenn ihr das so macht, weil nicht nötig als Überschrift

[Benni]

Auf die Gefahr hin, das du vollends genervt bist betateilchen, warum kein Wiki Eintrag

Uiih, jetzt nehm ich noch ne extra Hand voll Popcorn

[ftsinuglarity]

Uiih, jetzt nehm ich noch ne extra Hand voll Popcorn

Oh man, ich trete hier scheints von einem Fettnäpfchen und Hassthema ins nächste ... sorry endlosschleife

MUSS ja auch nicht beantwortet werden, ist euer Ding. Ich wollts nur zu bedenken geben.

[betateilchen]

warum kein Wiki Eintrag, wenn das Thema so nervt

weil dieser Teil Deines Textes

und damit abgekürzt werden könnte

ein völliger Irrglaube ist.

Oh man, ich trete hier scheints von einem Fettnäpfchen und Hassthema ins nächste
...
Ich wollts nur zu bedenken geben.

Mach Dir nix draus, Du bist nicht der erste "Anfänger" (bezogen auf die Beitragszahl) hier, der meint, der gesamten FHEM Community endlich einmal erklären zu müssen, wie man FHEM gefälligst "richtig" benutzt und dokumentiert.

[ftsinuglarity]

Um auch mal eine andere Seite zu zeigen:

Ihr habt mit fhem ganze Arbeit geleistet. Das modulare Konzept mit der Möglichkeit Firmenübergreifend Aktoren und Sensoren abzufragen und zu bedienen, damit völlig irre Konstrukte bauen zu können, ist einmalig. Ohne euch würde ich weiter meine Scripte basteln um meine, ich hatte mit Ediplugs angefangen, steuern zu können. Das war ein ganz schöner Aufwand, da ich auch noch verschiedene Netzsegmente habe, und die Scripte so liefen, das sie  sowohl auf den Routern als auch auf dem Server verschiedene Dinge erledigen. Die Netzwerksegmente sind zwar weiterhin mein "Problem", aber ich spare mir das proprietäre Geschreibe meiner Programme UND kann vor allem noch anderes zentral einbinden. Perfekt!

Meinen größtmöglichen Respekt.

[ftsinuglarity]

Mach Dir nix draus, Du bist nicht der erste "Anfänger" (bezogen auf die Beitragszahl) hier, der meint, der gesamten FHEM Community endlich einmal erklären zu müssen, wie man FHEM gefälligst "richtig" benutzt und dokumentiert.

Ähm, so war das nicht gemeint. Es sind einfach Fragen, die sich gestellt haben.

[ftsinuglarity]

weil dieser Teil Deines Textes

ein völliger Irrglaube ist.

Wenn du meinst. Wirst sicher deine Gründe und Erfahrungen haben, warum das sinnlos ist. Ich halte mich da jetzt einfach mal zurück. Für mich ist das Thema abgeschlossen. Vielen Dank für eure Geduld!

[CoolTux]

Um auch mal eine andere Seite zu zeigen:

Ihr habt mit fhem ganze Arbeit geleistet. Das modulare Konzept mit der Möglichkeit Firmenübergreifend Aktoren und Sensoren abzufragen und zu bedienen, damit völlig irre Konstrukte bauen zu können, ist einmalig. Ohne euch würde ich weiter meine Scripte basteln um meine, ich hatte mit Ediplugs angefangen, steuern zu können. Das war ein ganz schöner Aufwand, da ich auch noch verschiedene Netzsegmente habe, und die Scripte so liefen, das sie  sowohl auf den Routern als auch auf dem Server verschiedene Dinge erledigen. Die Netzwerksegmente sind zwar weiterhin mein "Problem", aber ich spare mir das proprietäre Geschreibe meiner Programme UND kann vor allem noch anderes zentral einbinden. Perfekt!

Meinen größtmöglichen Respekt.

In wie weit hast Du mit mehreren Netzsegmenten Probleme. Mal ab von Broadcast Funktionen klappt doch alles wenn man ein vernünftiges Forwarding hat.
Ich habe selbst 7 Segmente und FHEM kommt sofern gewünscht in alle Segmente zu den entsprechenden Ports.

[Benni]

OT! Bitte neuen Thread eröffnen!

[Pfriemler]

Ich gehöre auch zu den Leuten, die sich sehr bald das Herumändern in der fhem.cfg abgewöhnt haben, obwohl es in manchen Fällen tatsächlich ratsam scheint - z.B. wenn man ein Gerät umbenennen möchte. Rename berücksichtigt nicht alles, ebenso wie das deviceRename bei HomeMatic, und "Probably associated with" findet auch nicht alles. Ein einfaches globales Search&Replace in der fhem.cfg ist da echt verlockend. Aber mit dem Reload und dem Statefile hapert es dann gewaltig.
Also benutze ich die fhem.cfg, um global nach allen Stellen zu suchen und sie dann über das Webfrontend nacheinander zu ändern. Und in diesem Zusammenhang danke ich allen Verantwortlichen, dass es das Configfile noch als Text gibt. Zwar würde die Anzeige einer von binär nach Text konvertierten Config in einem laufenden FHEM ausreichen, aber wenn mein FHEM mal abgeschossen ist und ich weiß nicht warum, würde ich dann wieder völlig im Dunkeln tappen.

Jm2c. Ist noch Popcorn da?

[rudolfkoenig]

fhem.cfg direkt zu editieren hat diverse Nachteile: keine Syntaxpruefung, und ein Fehler kann bei Startup leicht uebersehen werden. Das Einlesen via rereadcfg ist ein de-facto Neustart, wobei etliche Sachen, wie simulierte on-for-timer oder der watchdog-Zustand, verloren gehen. Das Initialisieren mancher Geraete kann auch laenger dauern als man sich das wuenscht, und alle Module, die Daten regelmaessig vom Netz holen, rennen nach dem Neustart direkt los.

fhem.cfg direkt zu bearbeiten kann auch Vorteile haben: ich habe ein cfg Verzeichnis mit 100+ configs, um einzelne Module oder Problemfaelle zu testen. Aus diesen Dateien den Richtigen zu finden und vor dem Start mit den gemeldeten Problem zu bestuecken ist mit den gewohnten UNIX-Tools fuer mich einfacher. Bedient wird dann dieser FHEM hauptsaechlich ueber telnet, mit socat (+readline und history). In meiner Produktionsumgebung habe ich fhem.cfg aber seit Jahren nicht mehr direkt editiert.

Als Voreinstellung will ich bei fhem.cfg bleiben aus zwei Gruenden:
- eine Abhaengigkeit (die von der DB-Engine) weniger.
- falls fhem.cfg kaputt ist, dann kann ich es mit einem Editor reparieren. Falls die DB korrupt ist, dann habe ich ernsthafte Probleme.

Das prinzipielle Unterschied zwischen configDB und fhem.cfg ist, dass fuer Datenbanken nicht so viele Editoren (und andere nuetzliche Tools) gibt, wie fuer Dateien. Ich finde es aber albern, Fenster im 100. Stock nicht oeffnen zu koennen, nur weil manche aus dem Fenster springen wuerden. Als Konsequenz duerfen die Vernuenftigen die frische Luft auch nicht mehr geniessen.

Aber fhem.cfg zu editieren wird auch zunehmend erschwert, weil echte Anfaenger gar nicht wissen, wie auf einem Unix-Rechner eine Datei editiert, und zum Editieren in FHEMWEB muss man Doku lesen.
Apropos Doku: ich vermute das ist auch der Grund, warum betateilchen meint, Wiki waere in diesem Fall  Zeitverschwendung: die, die es brauchen, lesen es nicht.

[ftsinuglarity]

In wie weit hast Du mit mehreren Netzsegmenten Probleme. Mal ab von Broadcast Funktionen klappt doch alles wenn man ein vernünftiges Forwarding hat.
Ich habe selbst 7 Segmente und FHEM kommt sofern gewünscht in alle Segmente zu den entsprechenden Ports.

Das sind nicht wirklich "Probleme" .. ich hab nur die Wahl zwischen Rückwärts durchs Nadelöhr ein Loch in meinen Server zu bohren (auch wenn der ping den ich brauche nicht viel erscheint, kann man damit doch erstmal ne Menge ausloten ... bin vlt n bisschen Paranoid was das angeht)  ... oder der Server meldet gesammelte Ergebnisse .. was dann nur per Intervall und nicht aktiv anzustoßen geht, .. es sei denn ich lege ein ssh-cert auf den fhem-raspberry, der außerhalb meines internen Netzes liegt, um aktiv abfragen zu können.   Das ist wie ne Eintrittskarte. Gefällt mir alles nicht.
Ich hoffe das war nicht allzu wirr und irgendwie verständlich.

Ich finde das Thema dann aber doch zu OT, um in diesem Thread darüber zu reden.

Und echt? Wozu brauchst du gleich 7 Segmente ?   (rhetorische Frage)

[ftsinuglarity]

fhem.cfg direkt zu editieren hat diverse Nachteile: keine Syntaxpruefung, und ein Fehler kann bei Startup leicht uebersehen werden. Das Einlesen via rereadcfg ist ein de-facto Neustart, wobei etliche Sachen, wie simulierte on-for-timer oder der watchdog-Zustand, verloren gehen. Das Initialisieren mancher Geraete kann auch laenger dauern als man sich das wuenscht, und alle Module, die Daten regelmaessig vom Netz holen, rennen nach dem Neustart direkt los.

Richtig!, die Neustarts diverser Timer durchs Reaload. Ist definitiv ein Minuspunkt fürs manuelle. Anfangs vlt nicht so wichtig, bei zweien meiner Timern ists aber auch schon bei mir eigentlich nicht so prickelnd das sie resettet werden. Einer davon läuft dann gar nicht mehr, da er über das manuelle Einschalten eines Device ausgelöst wird. Würde ich unten beim "Resüme" nochmal hinzufügen wenns recht ist.

Als Voreinstellung will ich bei fhem.cfg bleiben aus zwei Gruenden:
- eine Abhaengigkeit (die von der DB-Engine) weniger.
- falls fhem.cfg kaputt ist, dann kann ich es mit einem Editor reparieren. Falls die DB korrupt ist, dann habe ich ernsthafte Probleme.
...
.. dass fuer Datenbanken nicht so viele Editoren (und andere nuetzliche Tools) gibt, wie fuer Dateien.

Exakt. .. Wo liegt eigentlich der Vorteil der DB .. ist sie schneller als die *.cfg`s  einzulesen? (rtfm wahrscheinlich)

Ich finde es aber albern, Fenster im 100. Stock nicht oeffnen zu koennen, nur weil manche aus dem Fenster springen wuerden. Als Konsequenz duerfen die Vernuenftigen die frische Luft auch nicht mehr geniessen.

sehr gut

Apropos Doku: ich vermute das ist auch der Grund, warum betateilchen meint, Wiki waere in diesem Fall  Zeitverschwendung: die, die es brauchen, lesen es nicht.

Verstehe. Ja, .. doof.  Da öfter mal reinzuschauen würde mir auch gut tun. Die "passt schon so" Mentalität ist manchmal grobe Zeitverschwendung.
Kann sein das jetzt jemand langsam anfängt Keulen zu schwingen, .. ich finde auf die Art der Konfiguration einzugehen, also ob über Interface oder direkt *.cfg, ist gerade für Neueinsteiger ein wichtiger Anhaltspunkt.
Es wird viele Menschen geben, die aus dem Programier-, Unix-, wasweißich Bereich kommen, und instinkitv über die Textdateien gehen. .. Is ja OpenSource, da muss das.
Andere wieder, die sich darauf freuen, endlich mal so richtig loseditieren zu können.
Ich wäre sogar so vermessen, diesen Hinweis ziemlich weit an den Anfang der FAQ und des Wikis zu stellen. Damit gar nicht erst falsch losgelegt wird und solche Fragen wie meine zum 100. Mal beantwortet werden müssen.
Ich denke jeder wird wenigstens die ersten Absätze der Einführung lesen um einen Anfang zu haben. 
Eigentlich wollte ich mich ja raushalten ..

[ftsinuglarity]

Rename berücksichtigt nicht alles, ebenso wie das deviceRename bei HomeMatic, und "Probably associated with" findet auch nicht alles. Ein einfaches globales Search&Replace in der fhem.cfg ist da echt verlockend.

Dann wird das Rename Problem auch beim manuellen editieren viel umfassender sein als ich das bisher wahrgenommen habe. 

Und in diesem Zusammenhang danke ich allen Verantwortlichen, dass es das Configfile noch als Text gibt.

Volle Zustimmung meinerseits!

Zwar würde die Anzeige einer von binär nach Text konvertierten Config in einem laufenden FHEM ausreichen, aber wenn mein FHEM mal abgeschossen ist und ich weiß nicht warum, würde ich dann wieder völlig im Dunkeln tappen.

Ansonsten gibts ja dann (hoffentlich) ein funktionierendes aktuelles Backup.
Möglicherweise verliert man aber trotzdem ne Menge Neudefinition ... wenn man in einem Anflug von Genialität in einer halben Stunde sonstwas zusammenklimpert.    Bin mir grad nicht sicher was die Autobackup Funktion abfedert.
Bin definitiv Pro Text.cfg . Ist vielleicht altmodischer, dafür die einfachste, robusteste Speicherform die mir einfallen würde. (möchte jetzt keine Diskussion lostreten)

[betateilchen]

Als Voreinstellung will ich bei fhem.cfg bleiben aus zwei Gruenden:

Ich kann keine zwei stichhaltigen Gründe für die Beibehaltung der Voreinstellung erkennen.

- eine Abhaengigkeit (die von der DB-Engine) weniger.

FHEM hat inzwischen so viele Abhängigkeiten, dass es auf eine mehr oder weniger inzwischen wirklich nicht mehr ankommt. Davon abgesehen: sqlite ist von Haus aus sogar auf der von Dir so geliebten Fritzkotz vorhanden.

- falls fhem.cfg kaputt ist, dann kann ich es mit einem Editor reparieren. Falls die DB korrupt ist, dann habe ich ernsthafte Probleme.

Aber nur, wenn Du so schlampig bist, von der Datenbank kein funktionsfähiges Backup zu haben. Und in diesem Fall geschehen Dir die "ernsthaften Probleme" dann aber auch recht 

Exakt. .. Wo liegt eigentlich der Vorteil der DB

Auch DAS wurde bereits gefühlte 200 Mal hier im Forum bis zum Erbrechen durchdiskutiert. Wie wäre es, wenn Du vor dem Schreiben erstmal anfangen würdest zu Lesen?