Gelöst - Manuelle Bearbeitung fhem.cfg

[ftsinuglarity]

Ich habe widersprüchliche Statements zu setstate und setreading gelesen. Oft wurde abgeraten und der Kopf geschüttelt, wenn vor allem setstate verwandt wird.
Ist das mittlerweile überholt ? Was spricht dagegen ?


Ebenso wird auch von den Entwicklern abgeraten, direkt in der cfg zu arbeiten.
So gut umgesetzt wie die Weboberfläche auch ist, im Sinne von (fast) alles kann man direkt darüber erstellen und bearbeiten, so umständlich finde ich die Handhabe. In vielen Fällen ist mir das zusammengesuche und -geklicke einfach zu umständlich, als die cfg's sinnvoll zu splitten, und für mich übersichtlich direkt in den Codeblock reinspringen zu können.
Anfangs gab es dadurch natürlich mehr Fehler .. Dinge an die falsche Stelle geschrieben, Attribute falsch aufgerufen etc ... Die Weboberfläche schließt Fehler aber ebensowenig aus, unterstützt "nur" ( nicht falsch verstehen, ist klasse gemacht)

Mein Frage ist, was genau sind die schlimmsten zu erwartenden Fehler, die durch das manuelle Editieren auftauchen könnten, über die Weboberfläche nicht? Wenn irgendwas nicht stimmt, sehe ich das doch beim Reload im Interface. Falls mal etwas untergeht, .. ich weiß ja wo ich suchen muß um zu korrigieren.

Edit: Durch einen Vorbeitrag angestoßen, habe ich versucht mal auschließlich übers Interface zu arbeiten mit obigem Ergebnis. Mittlerweile ist es ein Mix aus beidem. Manches läßt sich einfacher und syntaxsicherer auf der Oberfläche erstellen. Die Auswahl der verfügung stehenden Attribute zb per Dropdownliste  vermeidet Fehler durch das Setzen gar nicht nutzbarer/falsch verstandener Attribute.

[ftsinuglarity]

zur fhem.cfg:
automatisch gesetzte Enträge von struct's zb werden nicht korrigiert, wenn ich manuell an beeinflussender Stelle bearbeite und dann ein reload_config mache. Wäre ein Problem

[betateilchen]

ich geh mal Popcorn holen...

[CoolTux]

Mein Frage ist, was genau sind die schlimmsten zu erwartenden Fehler, die durch das manuelle Editieren auftauchen könnten, über die Weboberfläche nicht? Wenn irgendwas nicht stimmt, sehe ich das doch beim Reload im Interface. Falls mal etwas untergeht, .. ich weiß ja wo ich suchen muß um zu korrigieren.

Weißt Du warum die Entwickler und Helfenden den Anfängern dazu raten die cfg nicht direkt zu editieren und dieses includen zu lassen?
Nicht etwa weil wir sie schützen wollen, jeder wie es ihm beliebt. Nein sondern weil uns unsere kostbare Zeit zu schade ist solchen Leuten zu helfen nur um dann fest zu stellen das da wieder einer ohne Ahnung rumgefrickelt hat.
Nach 9 Antworten stellt sich dann raus das er Mist bei der Reihenfolge gemacht hat oder sich dank seines externen Editors ein nicht sichtbares Character eingeschlichen hat. In der Zeit hätte man anderen mehr helfen können oder ein neues Gerät analysieren können.

[ftsinuglarity]

ich geh mal Popcorn holen...

... da hab ich ja wieder was gefragt

Weißt Du warum die Entwickler und Helfenden den Anfängern dazu raten die cfg nicht direkt zu editieren und dieses includen zu lassen?
Nicht etwa weil wir sie schützen wollen, jeder wie es ihm beliebt. Nein sondern weil uns unsere kostbare Zeit zu schade ist solchen Leuten zu helfen nur um dann fest zu stellen das da wieder einer ohne Ahnung rumgefrickelt hat.
Nach 9 Antworten stellt sich dann raus das er Mist bei der Reihenfolge gemacht hat oder sich dank seines externen Editors ein nicht sichtbares Character eingeschlichen hat. In der Zeit hätte man anderen mehr helfen können oder ein neues Gerät analysieren können.

Ok, das verstehe ich CoolTux. Werde ich bedenken, bevor ich Fragen stelle.

Ich bin sicher nicht über solche Fehler erhaben, denke das ich mit solch grundlegenden Dingen wie utf-8 klarkomme, und mein Editor auch.
Bleibt für mich, sei mir nicht bös, immer noch die Frage, warum ist davon noch abzuraten ?
Ich komme im Editor besser und vor allem sehr viel schneller klar als im Webinterface mit in meinen Augen umständlicherer Handhabe. Dafür ist mir dann meine Zeit zu schade, wenn ich sehe daß es manuell sehr gut hinhaut. Deshalb auch meine Frage.

1.) Bisher bin ich auf die automatisch gesetzten structs die sich nicht anpassen gestoßen (wenn ich das überhaupt richtig gesehen habe),
2.) und ein paar Kleinigkeiten bei der Namensanpassung. Wenn ich den Dummynamen verändere, passt sich der Name im Notify nicht an.
Weiß ich jetzt, kann ich mit leben.

Die von dir angesprochene Reihenfolge. Damit meinst du zb die Attributreihenfolge ?
Kann es passieren, das bei falscher Reihenfolge beim reload_config nicht gemeckert wird, wenn nicht grobe Fehler gemacht werden, und dann Dinge "unerklärlich" nicht so funktionieren wie gedacht?
(grober Fehler: wenn ein attr für A definiert wird NACH einem define für ein anderes Device B. Das merkt die Syntaxprüfung)



Edit: ich erwarte keine vollständige Liste aller möglichen Fehlerquellen.
Wenn du sagst, das sind zu viele Dinge, auf die man dann letztlich aufpassen muß, und es ist Dringend! davon abzuraten, wenns nachher komplizierter wird ist das ausreichend. Bin ja noch relativ am Anfang mit fhem und hab noch lang nicht alles verstanden.
Ansonsten wär ich dann doch froh über ein, zwei Hinweise, worauf man noch aufpassen muß.

[Amenophis86]

Ich komme im Editor besser und vor allem sehr viel schneller klar als im Webinterface mit in meinen Augen umständlicherer Handhabe.

Du vielleicht, viele andere, die mit FHEM anfangen nicht. Und damit ist das Problem schon beschrieben. Wer weiß was er macht, der möge machen. Wer nicht weiß, was er macht, der möge es lassen.

Sortierung der IODevice fällt mir da noch ein.

[CoolTux]

Sortieren der IODev Geräte ist mit Reihenfolge gemeint. Und es gab schon einige die meinten sie kennen ihren Editor. Und schwupps ist beim zurück kopieren der cfg irgendwas schief gegangen und weil man selber "nichts gemacht hat" muss ein FHEM Fehler vor liegen. Nach 2 Tagen dann die Erkenntnis daß wenn man die Konfig über FHEMWEB einträgt es auf einmal geht.
Interessant wird es ja wenn du 2 Jahre config editiert hast und nur rudimentär mit FHEMWEB klar kommst und dann Intresse an condigDB findest. Wieder von vorn anfangen zu lernen. Dann lieber gleich vernünftig.

Du hast eine include EDV und du hast eine include kueche, unter EDV ist dein Homematic LAN Adapter in kueche der Homematic Lichtschalter und Thermostat.
Was passiert wohl wenn zu erst kueche includet wird und dann EDV?

Mit viel Glück heute nichts mehr, vor 6 Monaten gab es ein riesen Theater und wer dann noch Geistig umnachtet save gemacht hat, hatte Spaß.

[ftsinuglarity]

Und es gab schon einige die meinten sie kennen ihren Editor. Und schwupps ist beim zurück kopieren der cfg irgendwas schief gegangen und weil man selber "nichts gemacht hat" muss ein FHEM Fehler vor liegen. Nach 2 Tagen dann die Erkenntnis daß wenn man die Konfig über FHEMWEB einträgt es auf einmal geht.

.. ja, ok. Habs selbst über sftp gelöst, ich schreibe also direkt und mache keinen Umweg übers manuelle kopieren. Ersparrt Scherereien .. aber verstehe was du meinst.

Interessant wird es ja wenn du 2 Jahre config editiert hast und nur rudimentär mit FHEMWEB klar kommst und dann Intresse an condigDB findest. Wieder von vorn anfangen zu lernen. Dann lieber gleich vernünftig.

Aha, gut zu wissen. Mit der configDB hab ich mich noch nicht auseinandergesetzt weil ich das Prinzip "alles ist eine Datei" bevorzuge. DB ist ein höherer Aufwand bei der Korrektur als eine Datei. (Wenn ich vom Namen her richtig verstanden hab, was die ConfigDB macht)

Sortieren der IODev Geräte ist mit Reihenfolge gemeint.
Du hast eine include EDV und du hast eine include kueche, unter EDV ist dein Homematic LAN Adapter in kueche der Homematic Lichtschalter und Thermostat.
Was passiert wohl wenn zu erst kueche includet wird und dann EDV?

Hm, naja ein wenig den Kopf sollte man schon einschalten, ist manchmal von Vorteil.

> wer dann noch Geistig umnachtet save gemacht hat, hatte Spaß.
Es schaltet nicht .. hm .. warum .. Ah, na klar, vlt erstmal das Maindevice includen, bevor ich dessen angesteuerte Subdevices ansprechen kann. Sonst kennt hom_licht nicht hom_lan (oder so )
Ist das damit gemeint ?

> Dann lieber gleich vernünftig.

Sehe ich auch so. Nach ner gewissen Zeit festzustellen, das es grundsätzliche Denkfehler gab, kann sonst ziemlich frustrierend sein. Außerdem finde ich es nicht besonders prickelnd, die gleichen Dinge mehrmals zu machen.

[Morgennebel]

Ich war überzeugter fhem.cfg Direkteditierer mit vielen schön zu lesenden Includes wie in der Unix-Tradition...

Inzwischen nutze ich die ConfigDB. Nicht 100% glücklich, trotzdem mein Rat: folge den Experten hier und nutze nur das Webfrontend.

Ciao, -MN

[CQuadrat]

Als Freund der Kommandozeile nutze ich intensiv telnet.
In Verbindung mit rlwrap kann man da sogar Kommandozeilen editieren und es gibt eine Befehlshistorie (nützlich, wenn man sich vertippt und den Befehl nur kurz abändern will). Mit list schaue ich mir dann da auch gerne die Devices näher an.
Ist deutlich komfortabler als die Eingabezeile im FHEMWEB.
In einem zweiten Tab läuft dann noch zusätzlich das FHEM-Systemlog.

Aber wie gesagt, ich bin auch Freund der Kommandozeile. Das direkte Bearbeiten der fhem.cfg würde ich auch vermeiden.

[Otto123]

Wenn man nicht erst zu telnet will -> Raw Definition .

[Wernieman]

@CQuadrat
Du editierst also per telnet und nicht per FrontEnd ... und geht damit in die gleiche Richtig. Denn ob ich im Web in der Eingabe-Zeile etwas reinschreibe oder per telnet ...

Auch wenn es OT wird, habe so schon eine FHEM-Migration durchgefürt. Ins neue FHEM die Daten über telnet (bzw. nc) reingepustet (nachdem sie vorher bearbeitet wurden). Lief super.

War früher auch ein Freund von Includes, bis es zu unübersichtlich wurde. Es wird nur noch in der fhem.cfg gearbeitet, wenn sich ein iodev Verwschobe hat (z.B. sispm macht dieses (selten) manchmal bei mir)

[CQuadrat]

@CQuadrat
Du editierst also per telnet und nicht per FrontEnd ... und geht damit in die gleiche Richtig. Denn ob ich im Web in der Eingabe-Zeile etwas reinschreibe oder per telnet ...

Das ist mir klar. Nur habe ich dort (bei richtiger Konfiguration) noch ein paar Komfortfunktionen.

Auch "puste" ich dort gelegentlich längere Defines (inkl. Attribute) rein. Funzt super.

[ftsinuglarity]

Ich war überzeugter fhem.cfg Direkteditierer mit vielen schön zu lesenden Includes wie in der Unix-Tradition...

Inzwischen nutze ich die ConfigDB. Nicht 100% glücklich, trotzdem mein Rat: folge den Experten hier und nutze nur das Webfrontend.

Ciao, -MN

Ich freue mich über deinen Beitrag, auf so eine Antwort habe ich gehofft. Magst du sagen, Was dich bewogen hat, aufs frontend umzusteigen?

[ftsinuglarity]

Ich habe den Betreff mal eingeschränkt auf die Bearbeitung der fhem.cfg.
Die Frage mit setstate werde ich einzeln stellen.

Ich hoffe, das diese Diskussion, so nervig sie vlt auch für die Entwickler ist (tut mir leid), anderen einen Anhaltspunkt gibt, und somit euch Entwickler damit ein wenig entlasten. Wie man an der Anzahl der Lesenden der Disk. sieht, ist dies eine Frage, die nicht nur mich beschäftigt ... aus sicher vielfältigen Gründen. Allen voran den aus der Unix Welt kommenden Menschen, die direktes Editieren gewohnt sind, und alles andere lästiges Beiwerk ist, das meist zu mehr Problemen führt als löst  genauso wie der Fakt, sich dann nicht nur in das Programm selbst, sondern zusätzlich auch noch in ein Interface einarbeiten zu müssen, dessen Wert fraglich ist. (ich rede hier nicht von fhem),

Ebenfalls wichtig finde ich, das ich weiß wo was steht, wie es definiert ist etc.
Ich habe ein wenig Sorge, das eine (aus Menschensicht) wild zusammengeschriebene fhem.cfg, wenn sie denn mal zu Problemen führt, sehr aufwändig in der Korrektur und Fehlerfindung wird, gerade dann, wenn es komplizierter wird.
Nach jahrelanger Erfahrung mit frontends ist diese Denke schwer aus meinem Kopf zu bekommen und braucht Argumente, bzw. die Erfahrung anderer mit den Vor-und Nachteilen.