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.
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
ich geh mal Popcorn holen...
Zitat von: ftsinuglarity am 09 Oktober 2017, 21:36:17
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.
Zitat von: betateilchen am 09 Oktober 2017, 22:55:06
ich geh mal Popcorn holen...
:) ... da hab ich ja wieder was gefragt
Zitat von: CoolTux am 09 Oktober 2017, 23:07:08
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ß.
Zitat von: ftsinuglarity am 09 Oktober 2017, 23:35:22
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.
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ß.
Zitat von: CoolTux am 10 Oktober 2017, 07:15:59
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.
:D .. 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.
Zitat von: CoolTux am 10 Oktober 2017, 07:15:59
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)
Zitat von: CoolTux am 10 Oktober 2017, 07:15:59
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 :D)
Ist das damit gemeint ?
Zitat von: CoolTux am 10 Oktober 2017, 07:15:59
> 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.
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
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.
Wenn man nicht erst zu telnet will -> Raw Definition (https://wiki.fhem.de/wiki/Import_von_Code_Snippets) .
@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)
Zitat von: Wernieman am 11 Oktober 2017, 10:43:50
@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.
Zitat von: Morgennebel am 11 Oktober 2017, 07:35:20
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?
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.
Zitat von: ftsinuglarity am 11 Oktober 2017, 14:30:34
Ich freue mich über deinen Beitrag, auf so eine Antwort habe ich gehofft. Magst du sagen, Was dich bewogen hat, aufs frontend umzusteigen?
Der steigende Gerätepark.
Was mit 10-15 Geräten einer Produktfamilie noch überschaubar war, funktionierte mit 55-60 Geräten und 5 Produktfamilien nicht mehr. Man lernt dazu, probiert neue Dinge aus, neue Module aus den Foren, Experimente. Die fhem.cfg wurde immer unübersichtlicher und es kostete zuviel Zeit, diese zu pflegen.
Ich komme aus der Unix-Welt und liebe ASCII-Konfigurationsdateien. fhem.cfg erreicht aber inzwischen die Komplexität einer sendmail.cfg, und die wird auch nicht mehr per Hand, sondern per Makefile und Makros bearbeitet...
Warum mache ich eine ASCII-Konfigdatei hübsch, sortiert und strukturiert? Weil ich sie nach Wochen und Monaten verstehen will. Aber an FHEM bastelt man letztendlich doch beinahe täglich...
Ciao, -MN
Eine weitere Meinung eines Vor-FHEM-schon-Linux-Users:
Habe auch mit dem direkten Editieren und einigen #includes angefangen (stand ja so im Einsteigerdokument) und das auch über 2 Jahre so beibehalten (ssh+mcedit).
Dann bin ich mehr oder weniger aus Neugierde, was die Validität dieser Empfehlung diverser Exprten anging zu configDB (sqlite) gewechselt, was ein ziemlicher Schnitt war, da man da nicht einfach mit "suche+ersetze" usw. arbeiten kann. Mittlerweile finde ich es eigentlich einfacher, alles über FHEMWEB zu machen. Insbesondere das Wiederfinden einzelner Devices oder Gruppen geht mindestens so fix, jedenfalls, wenn man seine Räume sauber strukturiert und mit "list" und "FILTER=" arbeitet; offensichtliche Abhängigkeiten werden ja sowieso angzeigt.
Mit configDB hat man dann noch u.a. eine Versionierung, es gibt einen "Notfallmodus" und man kann sich eine aktuelle .cfg auch über eine kurzfristige Änderung eines globalen attr rausspeichern lassen. Dann gibt es für längere Code-Blöcke seit geraumer Zeit die RAW-Option, auf die Otto schon hingewiesen hat.
Dazu kann man tatschlich regelmäßig beobachten, dass v.a. Linux-Noobs dazu neigen, seltsame Dinge auszuprobieren und sich ihr FHEM damit abschießen, ohne einen Schimmer zu haben, wie das wieder zu beheben wäre. Da hilft die Syntaxprüfung, die z.B. auch RAW-Code nur akzeptiert, wenn nicht von vornherein irgendein bug drin ist.
Just my2ct
Gruß, Beta-User
Du kannst auch in configDB wunderbar suchen.
configdb search %KinZim%
Bedient Euch reichlich...
Was soll mir deine Antwort sagen Betateilchen? Das du das ganze amüsant findest ist ja schön, für andere sind das ernsthafte Fragen
(naja, lustiges Bild ists dennoch :D )
Amüsant ist, daß dieses Thema gefühlt jede zweite Woche von einem Anfänger/Einsteiger gestellt wird.
Alle Argumente für und wieder sind bis in die 200te Ebene ausdiskutiert.
Der Konsens, vor allem der älteren hier im Forum, die viel anderen Lesern helfen ist: Finger weg von der fhem.cfg.
Du kannst das ignorieren. Dann werden Dir aber bedeutend weniger Anwender hier im Forum helfen wollen...
Ciao, -MN
Wenn ich mal zusammenfassen darf: (danke für die Berücksichtigung meiner nicht zum ersten mal gestellten Frage und die vielen Antworten!)
- mit steigender Anzahl definierter Geräte wird es immer unübersichtlicher.
Der Vorteil bei geringer Anzahl in der config noch schneller zu bearbeitenden Einträge verschwindet mit steigender Anzahl .. nachvollziehbar.
- Hier macht es dann also Sinn, sich mehr in das Interface einzuarbeiten und dessen Möglichkeiten zu nutzen. Ich denke hier an Filtermöglichkeiten, die halt nicht per einfachem Klick erreichbar sind, um seine
Definitionen schneller zu finden. Gerade das ist mein Knackpunkt, das ewige Geklicke bis ich mal bei einer untergeordneten Definition ankomme, trotz möglichst gut angepasstem Interface.
- Wer's dennoch anders mag muß an einigen Stellen aufpassen und mitdenken. So zum Beispiel das sich, wie unten schon erwähnt, die Dummynamen des Notify's nicht anpassen, wenn ich manuell dessen
Namen verändere, automatisch gesetzte Einträge durch die struct's, die Reihenfolge der IODevs ... Prinzipiell ist es durchaus so machbar wenn man damit klarkommt, entsprechendes Grundwissen
und Aufmerksamkeit vorausgesetzt.
- Fragen über vermeintlich nicht funktionierende Definitionen sollte man dann dahingehend überprüfen, ob es wirklich an fhem liegt, oder man selbst irgendwelchen Mist mit falschen Textformatierungen etc
gemacht hat, bevor sich die Entwickler und alle anderen damit auseinandersetzen ... die Zeit möchte verständlicher Weise niemand opfern.
Zitat von: Morgennebel am 11 Oktober 2017, 16:55:25
Amüsant ist, daß dieses Thema gefühlt jede zweite Woche von einem Anfänger/Einsteiger gestellt wird.
Alle Argumente für und wieder sind bis in die 200te Ebene ausdiskutiert.
Der Konsens, vor allem der älteren hier im Forum, die viel anderen Lesern helfen ist: Finger weg von der fhem.cfg.
Du kannst das ignorieren. Dann werden Dir aber bedeutend weniger Anwender hier im Forum helfen wollen...
Ciao, -MN
Anfänger ist relativ, in fhem .. ja .. Unix und die damit gewohnte und in fhem übertagene Arbeitsweise .. nein.
Es sei Leuten auch mal zugestanden, das sie keine Volldeppen sind, sich eher fragen, warum sie eine "umständliche" Weboberfläche nutzen sollen, nur weil es empfohlen wird (das tut MS auch, mit bekannten Folgen .. will damit niemanden beleidigen ;) ) .. wenn es manuell eben viel schneller geht und, zumindest anfangs, mehr Übersichtlichkeit schafft .. Nach 2 Jahrzehnten Unix ist es nicht leicht dieses Konzept aus dem Kopf zu bekommen.
Der Punkt ist, es gibt Vor und Nachteile bei beidem. Allerdings ist es auch meiner Ignoranz geschuldet, wenn ich das Interface nicht vollständig nutze, um mir z.B., ohne über mein Menü zu gehen, per filter das Gesuchte direkt anzeigen lasse. DAS wiederum geht dann schneller und nervenschonender.
Bleibt mein Resüme:
mach was du vermeintlich besser in der cfg schneller hinbekommst, nur sei dir der möglichen Fehler bewußt bevor du Fragen stellst. (das Du bezieht sich auf mich)
Einarbeitung in die Weboberfläche macht Sinn, gerade bei steigender Geräteanzahl, das vermeintlich Geklicke läßt sich durch Filter abkürzen, so das der Vorteil der Direkteditierung wegfällt.
(Genau das werde ich tun)
Kann man das so sagen ?
Die Bedienung und Konfiguration von FHEM hat für mich nichts mit der Datei zu tun wo die Konfiguration abgelegt wird.
Es gibt jede Menge Schnittstellen und Interfaces über die die Konfiguration gemacht werden kann, ob klicken oder rein Textbasiert - ist alles dabei.
Wäre die Konfig Datei binär und verschlüsselt käme auch keiner auf die Idee sie mit dem Texteditor zu öffnen.
Auf zum nächsten Thread in gefühlt 2 Wochen ::)
Zitat von: Otto123 am 11 Oktober 2017, 17:30:10
Wäre die Konfig Datei binär und verschlüsselt käme auch keiner auf die Idee sie mit dem Texteditor zu öffnen.
Jup, damit hätte sich diese Frage dann erledigt :D
Zitat von: Otto123 am 11 Oktober 2017, 17:30:10
Die Bedienung und Konfiguration von FHEM hat für mich nichts mit der Datei zu tun wo die Konfiguration abgelegt wird.
Es gibt jede Menge Schnittstellen und Interfaces über die die Konfiguration gemacht werden kann, ob klicken oder rein Textbasiert - ist alles dabei.
Ich weiß nicht, ob wir aneinander vorbeireden. Mir gehts nicht darum, das ich unbedingt mal irgendwo direkten Code reinschreiben möchte, sondern um die Übersichtlichkeit, Verständlichkeit und eben das nicht enden wollende Geklicke das ich absolut nicht mag.
(Code schreiben -> Im Gegenteil, wie geil wäre es, meinem Rechner wortwörtlich zu sagen: "schalte morgen früh die Kaffeemaschine um 8 Uhr ein. Heiz mir dann auch gleich mal das Bad auf und schnür mir die Schuhe." Aber soweit ist die Technik leider noch nicht. Auf Codeschreiben könnte ich gut verzichten, vlt mal so zum Spaß)
Zitat von: Otto123 am 11 Oktober 2017, 17:30:10
Wäre die Konfig Datei binär und verschlüsselt käme auch keiner auf die Idee sie mit dem Texteditor zu öffnen.
Rudi wehrt sich bedauerlicherweise nach wie vor vehement gegen eine grundlegende Änderung der Konfigurationsablage und überläßt es lieber seinen Anwendern, alle zwei Wochen die gleiche Diskussion immer wieder aus dem Urschleim heraus führen zu müssen...
Zitat von: betateilchen am 11 Oktober 2017, 17:47:51
Rudi wehrt sich bedauerlicherweise nach wie vor vehement gegen eine grundlegende Änderung der Konfigurationsablage und überläßt es lieber seinen Anwendern, alle zwei Wochen die gleiche Diskussion immer wieder aus dem Urschleim heraus führen zu müssen...
Bin ich voll auf seiner Seite. Zumindest die Möglichkeit liefert mich nicht hilflos einem System aus.
Das diese Diskussion nervt verstehe ich total, und ich entschuldige mich dafür, das zum anscheinend 100. Mal anzustoßen.
Wäre es nicht vlt sinnvoll, genau dieses Thema mal prominent im Wiki zu plazieren, Vor und Nachteile, Gefahren aufzulisten ? Ersparrt vlt die ein oder andere Frage. Scheinen sich ja sehr viele Menschen zu fragen, wenn man mit fhem anfängt.
Zitat von: ftsinuglarity am 11 Oktober 2017, 17:51:01
Wäre es nicht vlt sinnvoll, genau dieses Thema mal prominent im Wiki zu plazieren
Nein.
Zitat von: ftsinuglarity am 11 Oktober 2017, 17:51:01
Bin ich voll auf seiner Seite.
Ich nicht. Die fhem.cfg ist übrigens das wirklich EINZIGE Thema in FHEM, bei dem in mir immer wieder der Hass gegen die seinerzeitig Entscheidung bei der "Erfindung" von FHEM hochkommt. Dieser Hass ist noch schlimmer als meine Aversion gegen javascript und Fritzkotz.
Und das will schon was heißen.
Zitat von: ftsinuglarity am 11 Oktober 2017, 17:35:12
sondern um die Übersichtlichkeit, Verständlichkeit und eben das nicht enden wollende Geklicke das ich absolut nicht mag.
Ich habe immer noch nicht verstanden, warum eine Config-Datei (meine hätte, wenn ich denn eine hätte, über 7000 Zeilen) in einem Texteditor übersichtlicher sein sollte, als in einer gut strukturierten FHEMWEB-Oberfläche, auch nicht, wenn das ganze über zig Includes verteilt ist.
FHEMWEB (oder für die Lowlevel-Puristen meinetwegen auch telnet) ist quasi der Editor zu FHEM.
Es mag ja auch keiner in MS-Office-Dateien in der zugrundeliegenden XML-Struktur per Notepad rum editieren, obwohl dies ja durchaus möglich wäre. Da kommt keiner auf die Idee zu sagen, das sei verständlicher und einfacher als das Geklicke in Word oder Excel.
Das waren meine 2Ct.
Ich gönn mir jetzt noch ne Hand voll von betateilchens Popcorn (danke dafür ;) )
Zitat von: Benni am 11 Oktober 2017, 17:55:33
Es mag ja auch keiner in MS-Office-Dateien in der zugrundeliegenden XML-Struktur per Notepad rum editieren, obwohl dies ja durchaus möglich wäre. Da kommt keiner auf die Idee zu sagen, das sei verständlicher und einfacher als das Geklicke in Word oder Excel.
Wohl wahr :)
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
Zitat von: ftsinuglarity am 11 Oktober 2017, 17:58:34
Auf die Gefahr hin, das du vollends genervt bist betateilchen, warum kein Wiki Eintrag
:o Uiih, jetzt nehm ich noch ne extra Hand voll Popcorn ;D
Zitat von: Benni am 11 Oktober 2017, 18:00:46
:o Uiih, jetzt nehm ich noch ne extra Hand voll Popcorn ;D
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.
Zitat von: ftsinuglarity am 11 Oktober 2017, 17:58:34
warum kein Wiki Eintrag, wenn das Thema so nervt
weil dieser Teil Deines Textes
Zitat von: ftsinuglarity am 11 Oktober 2017, 17:58:34
und damit abgekürzt werden könnte
ein völliger Irrglaube ist.
Zitat von: ftsinuglarity am 11 Oktober 2017, 18:02:37
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.
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.
Zitat von: betateilchen am 11 Oktober 2017, 18:24:37
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.
Zitat von: betateilchen am 11 Oktober 2017, 18:24:37
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!
Zitat von: ftsinuglarity am 11 Oktober 2017, 18:26:26
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.
OT! Bitte neuen Thread eröffnen! ;)
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?
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.
Zitat von: CoolTux am 11 Oktober 2017, 19:09:12
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 ? :D (rhetorische Frage)
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
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.
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
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)
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
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.
;D sehr gut
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
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 .. :D
Zitat von: Pfriemler am 11 Oktober 2017, 21:02:25
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.
Zitat von: Pfriemler am 11 Oktober 2017, 21:02:25
Und in diesem Zusammenhang danke ich allen Verantwortlichen, dass es das Configfile noch als Text gibt.
Volle Zustimmung meinerseits!
Zitat von: Pfriemler am 11 Oktober 2017, 21:02:25
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)
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
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.
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
- 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.
Zitat von: rudolfkoenig am 11 Oktober 2017, 21:55:06
- 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 8)
Zitat von: ftsinuglarity am 12 Oktober 2017, 02:08:33
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?
Sorry, aber die Nachteile wurden auch schon 200mal durchgekaut
ZitatWie wäre es, wenn Du vor dem Schreiben erstmal anfangen würdest zu Lesen?
Ich möchte damit Antworten:
"Mann fasse Sich vor solchen Aussagen am besten an die eigene Nase"
Deine Aussage ist beleidigend!
Zitat von: betateilchen am 11 Oktober 2017, 16:18:05
Bedient Euch reichlich...
...und vertragt Euch wieder 8) .
Jeder mag entscheiden, was für ihn "besser" ist.
Ich mag mein Popcorn gerne salzig!
Zitat von: Wernieman am 12 Oktober 2017, 12:15:16
Ich möchte damit Antworten:
und ich möchte damit antworten: "Steck Dir Dein völlig überflüssiges Fremdschämen sonstwo hin!
Ich "schäme mich nicht für Dich", sondern finde Dich ab heute "nur noch beleidigend" ... und wollte eigentlich etwas "beruhigend" einwirken ... aber wirkt nicht bei jedem ;o)
Aber scheinbar kapierst Du dieses nicht .....
P.S. Jetzt will ich auch kein Popcorn ..... Mitagessen ist mir lieber!
Zitat von: betateilchen am 12 Oktober 2017, 12:08:45
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 8)
Übrigens: warum macht das "backup" Kommando kein automatisches "configdb dump" im Vorfeld?
Zitat von: amenomade am 12 Oktober 2017, 13:19:23
Übrigens: warum macht das "backup" Kommando kein automatisches "configdb dump" im Vorfeld?
Weil es oft mals gar nicht das ist, was man haben möchte, bzw. für ein geeignetes Backup braucht!
Ich habe die ConfigDB-Datenbank bspw. in einer sqlite-Datenbank (für Config-Daten übrigens mehr als ausreichend, da brauchts kein großes DBS dazu). Das entsprechende File liegt, wie normalerweise die fhem.cfg auch, im modpath und wird so automatisch mit meinem normalen fhem-Backup mitgesichert.
Mehr braucht's da nicht! Das ist an der Stelle, vom Handling her genau gleich, wie bei der fhem.cfg!
Btw.: Das ist eigentlich schon wieder OT und führt, wie die letzten 200 mal auch zu nichts. Vielleicht wäre es daher nicht schlecht, wenn der TE, der den Thread ja für sich schon als "Gelöst" markiert hat, ihn nun noch schließen würde.
Gruß Benni.
Kann aber in die Hose gehen Benni. Du sicherst eine geöffnete Datenbank weg. Thema inkonsistenz. Wer weiß was sich da gerade noch im Speicher befindet und noch nicht geschrieben wurde.
Im Gegensatz zu DbLog ist die configDB zur Laufzeit von FHEM nicht permanent geöffnet.
Zitat von: betateilchen am 12 Oktober 2017, 12:08:45
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?
Man, betateilchen, hab das Gefühl du willst ein wenig stänkern.
Wenn du schon zitierst, dann vollständig. Geschrieben habe ich:
Zitat von: ftsinuglarity am 12 Oktober 2017, 02:08:33
Exakt. .. Wo liegt eigentlich der Vorteil der DB .. ist sie schneller als die *.cfg`s einzulesen? (rtfm wahrscheinlich)
Damit meinte ich ja, bitte erklärts mir jetzt nicht unbedingt, ich sollte dazu wohl das manual befragen.
Ein Backup ist doch nur so viel wert, wie der Zeitpunkt, an dem es gemacht wurde.
Bei nem Textfile schnell mal ne Kopie zu ziehen, kritische Teile rauszukopieren etc ist minimalster Aufwand. Vlt noch ne auto_backup funktion wie notepad++ es bietet wenn mans denn braucht.. damit kann man unkompliziert fahren.
Ein DB Dump ist da wesentlich aufwändiger, selbst wenn ich wie bei sqlite einfach den file wegkopieren kann weil der Zugriff auf die DB nicht permanent ist (wenn ich das richtig gelesen habe), .. es ist umständlicher.
Wenn ich jetzt mein Backup mache ... dann ne Stunde konfiguriere, irgendwas läuft worst case so schief, das noch nicht mal mehr fhem irgendwas anzeigen mag ... Dann hab ich zwar das Backup .. aber die letzte Stunde ist weg wenn ich Pech habe.
Sowas spukt mir bei DB's immer im Kopf rum.
Beim Textfile gehe ich dann rein, suche die Stelle, korrigiere .. das wars.
Zitat von: Benni am 12 Oktober 2017, 13:39:50
Btw.: Das ist eigentlich schon wieder OT und führt, wie die letzten 200 mal auch zu nichts. Vielleicht wäre es daher nicht schlecht, wenn der TE, der den Thread ja für sich schon als "Gelöst" markiert hat, ihn nun noch schließen würde.
Mache ich gern, halte mich aber an eure Vorgaben. In der Forum FAQ heißts: Thread als Gelöst markieren aber offen lassen, damit andere noch schreiben können (Jaha, hab die faq gelesen :D )
OT ist aber korrekt ...mittlerweile sowas von...
Wir kommen vom Thema ab. Ich bitte entweder zurück zum Thema zu kommen und dort zu bleiben, oder den TE das Thema zu schließen, sollte es sich für ihn erledigt haben.
Weiterhin bitte ich alle auf einer sachlichen Ebene zu bleiben und Beleidigungen, oder ähnliche Dinge zu unterlassen. Danke
Zitat von: ftsinuglarity am 12 Oktober 2017, 14:38:10
Ein Backup ist doch nur so viel wert, wie der Zeitpunkt, an dem es gemacht wurde.
Bei nem Textfile schnell mal ne Kopie zu ziehen, kritische Teile rauszukopieren etc ist minimalster Aufwand. Vlt noch ne auto_backup funktion wie notepad++ es bietet wenn mans denn braucht.. damit kann man unkompliziert fahren.
Ein DB Dump ist da wesentlich aufwändiger, selbst wenn ich wie bei sql einfach den file wegkopieren kann weil der Zugriff auf die DB nicht permanent ist (wenn ich das richtig gelesen habe), .. es ist umständlicher.
Wenn ich jetzt mein Backup mache ... dann ne Stunde konfiguriere, irgendwas läuft worst case so schief, das noch nicht mal mehr fhem irgendwas anzeigen mag ... Dann hab ich zwar das Backup .. aber die letzte Stunde ist weg wenn ich Pech habe.
Sowas spukt mir bei DB's immer im Kopf rum.
Beim Textfile gehe ich dann rein, suche die Stelle, korrigiere .. das wars.
Mache ich gern, halte mich aber an eure Vorgaben. In der Forum FAQ heißts: Thread als Gelöst markieren aber offen lassen, damit andere noch schreiben können (Jaha, hab die faq gelesen :D )
OT ist aber korrekt ...mittlerweile sowas von...
bla, bla, bla ....
... es riecht inzwischen hier irgendwie verdammt nach Troll! ::)
Ich schlage vor wir schließen den Thread.
Könnte das bitte der Threadersteller machen. DANKE
wird mir grad ein wenig zu blöd. Ich opfere auch meine Zeit, um den von mir erstellten Thread mit aus meiner Sicht sinnvollem Inhalt zu füllen. Das sind Argumente, kein Bla bla.
Also soll ich den Thread dann zumachen oder nich ?
ah, ok ... ja, mache ich
Danke für die zahlreichen Kommentare. Hat mir persönlich Klarheit gegeben, was die Vor und Nachteile der manuellen Konfiguration sind.
Frage gelöst, danke.
Edit:
Wie das hier am Ende lief, hat mich überrascht.
Ihr seid doch alle intelligente Menschen. Warum also ladet ihr eure Wut dann hier ab?
Wir sind, ohne jemandem auf die Füße treten zu wollen, ein ziemlich nerdiger Haufen .. Menschen mit ähnlichem Interesse. Viele von uns fallen sicher auch aus der Norm.(reine Vermutung)
Warum haut sich so eine besondere Gruppe gegenseitig die Köpfe ein, anstatt sich konstruktiv zu unterstützen und genau diesen sinnlosen Mist nicht zu machen?
Die Wut gehört definitiv woanders hin. Ist vielleicht sinnvoller, an dieser Front was zu machen, als sie hier abzuladen .. es trifft die falschen.