Ich (wünsche mir|stelle zur Diskussion) das FHEM in Zukunft configDB als Standardspeichervariante der FHEM Konfiguration verwendet. Am WE habe ich mir mal den Spaß gemacht und einfach so, ohne weiteres zutun mit Ausnahme der Abhängigkeitsauflösung auf configDB umgestellt. Klappte super einfach und Reibungslos. Default empfehle ich sqlite.
Begründung:
Ich sehe in fhem.cfg im Gegensatz zu configDB keinen wirklichen Mehrwert, aber jede Menge Probleme wenn die User der Meinung sind sie müssen mit einem externen Editor die cfg bearbeiten oder mit cfg includes arbeiten.
Grüße
Leon
Zitat von: CoolTux am 31 Juli 2017, 09:26:28
Ich (wünsche mir|stelle zur Diskussion) das FHEM in Zukunft configDB als Standardspeichervariante der FHEM Konfiguration verwendet. Am WE habe ich mir mal den Spaß gemacht und einfach so, ohne weiteres zutun mit Ausnahme der Abhängigkeitsauflösung auf configDB umgestellt. Klappte super einfach und Reibungslos. Default empfehle ich sqlite.
Begründung:
Ich sehe in fhem.cfg im Gegensatz zu configDB keinen wirklichen Mehrwert, aber jede Menge Probleme wenn die User der Meinung sind sie müssen mit einem externen Editor die cfg bearbeiten oder mit cfg includes arbeiten.
Ich bin dagegen, weil eine Config-Datei einen entscheidenden Vorteil zu einer Datenbanklösung hat:
Eine Textdatei kann einfach mal mit jedem x-beliebigen Editor bearbeitet werden. Das ist besonders wichtig, wenn FHEM nicht mehr startet (Linux update, ....), weil irgendein Modul nicht mehr geht. Ich kann dann einfach in der Datei das Gerät auskommentieren und gut. Das ist mit der DB nicht so einfach möglich und führt im schlimmsten Fall zum kompletten Neuaufsetzen des Systems wie z.B. hier (https://forum.fhem.de/index.php/topic,71938.msg635059.html#msg635059).
Aus Softwarearchitektursicht ist die Verwendung der ConfigDB eine zyklische Abhängigkeit, die verhindert werden sollte. Ich benötige ein lauffähiges System, um die Config-Daten zu bearbeiten, die wiederum für den Start des Systems benötigt werden. Mir ist vollkommen bewusst, dass die Daten in der DB auch ohne FHEM bearbeitet werden können, aber das können nur Leute mit SQL-Erfahrung. Das dürften die wenigsten FHEM-User sein.
Die DB bietet technisch keinen Vorteil für die Config-Daten. Die Verwendung der DB schafft nur zusätzliche Komplexität.
Wo Du natürlich Recht hast, ist das gerade Neueinsteiger nicht in der Configdatei editieren sollten. Hierfür wurde ja auch schon das Bearbeiten innerhalb von FHEM unterbunden.
Als sehr nützlich hat sich bei mir auch die Datei beim Umzug auf ein neues System erwiesen. Ich konnte nach dem Anlegen der IOs einfach die Geräte per Copy&Paste + Textersetzung umziehen.
Zitat von: papa am 31 Juli 2017, 11:02:47
Ich bin dagegen, weil eine Config-Datei einen entscheidenden Vorteil zu einer Datenbanklösung hat:
Eine Textdatei kann einfach mal mit jedem x-beliebigen Editor bearbeitet werden. Das ist besonders wichtig, wenn FHEM nicht mehr startet (Linux update, ....), weil irgendein Modul nicht mehr geht. Ich kann dann einfach in der Datei das Gerät auskommentieren und gut. Das ist mit der DB nicht so einfach möglich und führt im schlimmsten Fall zum kompletten Neuaufsetzen des Systems wie z.B. hier (https://forum.fhem.de/index.php/topic,71938.msg635059.html#msg635059).
Vor jedem Update ist es möglich automatisch ein Backup anfertigen zu lassen. Bereitet ein Modul in der neuen Version ein Problem, so ist das Modul zu restoren und nicht die Konfiguration zu entfernen
Zitat von: papa am 31 Juli 2017, 11:02:47
Aus Softwarearchitektursicht ist die Verwendung der ConfigDB eine zyklische Abhängigkeit, die verhindert werden sollte. Ich benötige ein lauffähiges System, um die Config-Daten zu bearbeiten, die wiederum für den Start des Systems benötigt werden. Mir ist vollkommen bewusst, dass die Daten in der DB auch ohne FHEM bearbeitet werden können, aber das können nur Leute mit SQL-Erfahrung. Das dürften die wenigsten FHEM-User sein.
Es ist ohne weiteres Möglich FHEM mit configDB in einem rescueMode zu starten in dem ich ein lauffähiges FHEM besitze. Danach kann man eine ältere Konfigurationsversion laden.
configDB besitzt ein Versionierungssystem!!!
Zitat von: papa am 31 Juli 2017, 11:02:47
Die DB bietet technisch keinen Vorteil für die Config-Daten. Die Verwendung der DB schafft nur zusätzliche Komplexität.
configDB besitzt ein Versionierungssystem!!! Von Hause aus
Grüße
bin auch dagegen:
Eine zwangsweise DB stellt einen zusätzlichen Layer der Komplexität dar.
Hier https://forum.fhem.de/index.php/topic,74774.0.html kann man gut nachlesen das dies lange keine Allheilmittel ist (mit text cfg könnte ich helfen, so nicht)
Zitat der Begründung war
ZitatI... aber jede Menge Probleme wenn die User der Meinung sind sie müssen mit einem externen Editor die cfg bearbeiten oder mit cfg includes arbeiten.
Ist mMn schon komplett falscher Ansatz: User "erziehen" wollen ist gegenüber allen anderen Argumenten immer das schlechteste.
So wie es jetzt ist, ist alles in Ordnung. Wer mag kann sich dbconfig einrichten. je mehr das modul im Lauf zukünftiger Entwicklungen bekommt umso besser.
vg
joerg
Hattest Du den verlinkten Beitrag gelesen. Keiner der existierenden Mechanismen konnte das System wiederbeleben.
Der Auslöser war auch nicht ein FHEM-Update sondern ein Linux-Update, womit dann irgendwas in der FHEM-Installation nicht mehr klar kam. Da nutzen FHEM-Backups und Config-Versionen gar nichts.
Da auch nicht einfach mal einzelne Module ausgeschaltet werden konnten, war es nicht mal möglich das Problem zu lokalisieren. Eine Datei hätte hier zumindest mehr Möglichkeiten geboten.
Zitat von: herrmannj am 31 Juli 2017, 11:56:18
Hier https://forum.fhem.de/index.php/topic,74774.0.html kann man gut nachlesen das dies lange keine Allheilmittel ist (mit text cfg könnte ich helfen, so nicht)
vg
joerg
Hallo Jörg
Wobei ich bei diesem Problem denke, das es nicht die Konfiguration an sich ist. Tippe immer noch auf eine externe Komponente
Man müsste sich die Hilfesuchenden nicht erziehen, wenn sie sich in solchen Fällen wie include cfg selber zu helfen wüssten. Leider ist das oft nicht der Fall.
Aber das ist ein anderes leidvolles Thema.
Grüße
Dagegen.
Um es klar auszudrücken: ein Zwang zu ConfigDB wäre für mich Grund genug, FHEM den Rücken zu kehren (muß Euch nicht kümmern, ich weiß ;-).
Für mich sind Text-Konfigurationsdateien die zugrundeliegende Arbeitsweise eines Linux-Systems. Die kann ich sichern (mit tar), die kann ich versionieren, die kann ich leicht vergleichen, die kann ich kopieren, während das System läuft.
Eine DB welcher Art auch immer fügt eine Abhängigkeit hinzu, macht das Debugging schwieriger. Ich muß mehr Befehle lernen und im Notfall mich an diese erinnern. Das ist am Ende wie Windows mit seiner Registry-DB - da kann man was machen, oft aber nicht. Und dann kommen Abhängigkeiten in Updates hinzu, in DB-Treibern, in Perl-Version zum eingesetzen FHEM usw.
Macht Dinge nicht komplizierter, als sie sein müssen. Und haltet einfach zu wartende Lösungen einfach.
Ciao, -MN
Zitat von: papa am 31 Juli 2017, 12:07:31
Hattest Du den verlinkten Beitrag gelesen. Keiner der existierenden Mechanismen konnte das System wiederbeleben.
Der Auslöser war auch nicht ein FHEM-Update sondern ein Linux-Update, womit dann irgendwas in der FHEM-Installation nicht mehr klar kam. Da nutzen FHEM-Backups und Config-Versionen gar nichts.
Da auch nicht einfach mal einzelne Module ausgeschaltet werden konnten, war es nicht mal möglich das Problem zu lokalisieren. Eine Datei hätte hier zumindest mehr Möglichkeiten geboten.
Nun so etwas sollte die Ausnahme bleiben. Quasi Einzelfall.
In der Note kann man aber aus einer condigDB ohne FHEM auch eine cfg machen. Gebe aber zu das dazu weiterreichende Kenntnisse von Nöten sind.
Ich habe bis gestern noch nie mit sqlite gearbeitet, war aber recht schnell in der Lage mir mittels sqlite Syntax die DB Namen und Tabellen ausgeben zu lassen, ausserdem die Tabelleneigenschaften und select Statements ab zu setzen.
Ja es ist mehr Aufwand als eine cfg zu bearbeiten. Dessen bin ich mir bewusst. Aber wie gesagt, sollte sowas die Ausnahme bleiben.
Grüße
Zitat von: papa am 31 Juli 2017, 11:02:47
Wo Du natürlich Recht hast, ist das gerade Neueinsteiger nicht in der Configdatei editieren sollten. Hierfür wurde ja auch schon das Bearbeiten innerhalb von FHEM unterbunden.
Dem stimme ich ja zu. Wie wäre es denn mit einem global Attribut ExpertLevel mit den Werten:
- 0: Kein Edit-Button für alle Dateien, include in der fhem.cfg wird deaktiviert (Default)
- 1: Edit-Button für fhem.cfg, include in der fhem.cfg wird deaktiviert
- 2: Edit-Button für alle Dateien, include in der fhem.cfg wird aktiviert
Analog zu dem "expert"-Attribut bei meinen HM-Geräten.
Ciao, -MN
Zitat von: Morgennebel am 31 Juli 2017, 12:20:07
Dagegen.
Um es klar auszudrücken: ein Zwang zu ConfigDB wäre für mich Grund genug, FHEM den Rücken zu kehren (muß Euch nicht kümmern, ich weiß ;-).
Für mich sind Text-Konfigurationsdateien die zugrundeliegende Arbeitsweise eines Linux-Systems. Die kann ich sichern (mit tar), die kann ich versionieren, die kann ich leicht vergleichen, die kann ich kopieren, während das System läuft.
Eine DB welcher Art auch immer fügt eine Abhängigkeit hinzu, macht das Debugging schwieriger. Ich muß mehr Befehle lernen und im Notfall mich an diese erinnern. Das ist am Ende wie Windows mit seiner Registry-DB - da kann man was machen, oft aber nicht. Und dann kommen Abhängigkeiten in Updates hinzu, in DB-Treibern, in Perl-Version zum eingesetzen FHEM usw.
Macht Dinge nicht komplizierter, als sie sein müssen. Und haltet einfach zu wartende Lösungen einfach.
Ciao, -MN
Würde ich mitgehen wenn es sich um ein Betriebssystem handeln würde. Da bin ich auch ein Verfechter von Konfigurationsdateien. Bei Programmen sieht es schon etwas anders aus.
Zitat von: CoolTux am 31 Juli 2017, 12:21:22
Ich habe bis gestern noch nie mit sqlite gearbeitet, war aber recht schnell in der Lage mir mittels sqlite Syntax die DB Namen und Tabellen ausgeben zu lassen, ausserdem die Tabelleneigenschaften und select Statements ab zu setzen.
Ja es ist mehr Aufwand als eine cfg zu bearbeiten. Dessen bin ich mir bewusst. Aber wie gesagt, sollte sowas die Ausnahme bleiben.
Solche Ausnahmen passieren eigentlich nach meiner Erfahrung in dieser Situation:
Frau hochschwanger auf dem Sofa, größere Kinder lärmen im Zimmer, Mann auf Geschäftsreise in Indien mit mangelhaftem Internet, VPN nicht möglich, hochgenervte Frau am Telephon ihren Mann verfluchend und zeternd, droht mit Scheidung. Aber eigentlich steht das Meeting an....
Eine Textdatei kann ich über EDGE am Telephon mit VPN bearbeiten. Super!
Ciao, -MN
Zitat von: Morgennebel am 31 Juli 2017, 12:28:24
Eine Textdatei kann ich über EDGE am Telephon mit VPN bearbeiten. Super!
Ciao, -MN
Rein aus Interesse da ich das gerade nicht zuordnen kann. Du kannst eine Textdatei auf einem Linuxsystem über einen Webbrowser editieren?
Oder meintest Du jetzt aus FHEMWEB heraus?
Zitat von: CoolTux am 31 Juli 2017, 12:25:42
Würde ich mitgehen wenn es sich um ein Betriebssystem handeln würde. Da bin ich auch ein Verfechter von Konfigurationsdateien. Bei Programmen sieht es schon etwas anders aus.
Ich zähle mal nützliche Programme aus dem Unix-Umfeld mit textbasierender Konfiguration auf: Apache, Sendmail, Squid, SSH, Bind.
Dies sind alle essentielle Programme für Backend-Dienste, die eigentlich nie ausfallen sollten. 70% des Internet läuft auf der Basis dieser vier Programme (Bauch*Pi*Daumen).
Im Gegenzu kenne ich nur zwei Programme, die eine DB verwenden: Roxen (tot) und MythTV (Backend). Und das ist im Zusammenhang mit systemd und einem nicht-deterministischen Startverhalten "zur Beschleunigung" totale Katastrophe.
Ciao, -MN
Zitat von: CoolTux am 31 Juli 2017, 12:31:00
Rein aus Interesse da ich das gerade nicht zuordnen kann. Du kannst eine Textdatei auf einem Linuxsystem über einen Webbrowser editieren?
*hust* EDGE wie GPRS oder 2G. Telephon-Geschwindigkeit. Kein MS-Produkt.
Ciao, -MN
Zitat von: Morgennebel am 31 Juli 2017, 12:32:41
Ich zähle mal nützliche Programme aus dem Unix-Umfeld mit textbasierender Konfiguration auf: Apache, Sendmail, Squid, SSH, Bind.
Dies sind alle essentielle Programme für Backend-Dienste, die eigentlich nie ausfallen sollten. 70% des Internet läuft auf der Basis dieser vier Programme (Bauch*Pi*Daumen).
Im Gegenzu kenne ich nur zwei Programme, die eine DB verwenden: Roxen (tot) und MythTV (Backend). Und das ist im Zusammenhang mit systemd und einem nicht-deterministischen Startverhalten "zur Beschleunigung" totale Katastrophe.
Ciao, -MN
Finde ich gut das Beispiel. Denn hier sieht man wo man trennen kann/"sollte".
Die Grundkonfiguration ist in der Tat immer eine Textdatei. Erweiterte Konfigurationen kann man aber auch DB basiert ablegen (bind,sendmail). Und das macht durchaus Sinn. Denn gerade bei bind kann die erweiterte Konfig sehr dynamisch sein. Daher lege ich hier die Konfigurationen in ein LDAP/eDirectory ab. DB basiertes Backend.
Meine persönliche Sicht ist hier, Programme die eine Grundkonfiguration haben brauchen auch kein DB Konfig.
FHEM ist aber wachsend in der Konfiguration. Und es ist eine Anwenderkonfiguration. Ich muss ein HM Gerät nicht definieren damit FHEM als Programm lauffähig ist. Nur wenn ich HM verwenden möchte. Sowas ist Anwenderspezifisch.
Zitat von: papa am 31 Juli 2017, 12:07:31
Hattest Du den verlinkten Beitrag gelesen. Keiner der existierenden Mechanismen konnte das System wiederbeleben.
Der Auslöser war auch nicht ein FHEM-Update sondern ein Linux-Update, womit dann irgendwas in der FHEM-Installation nicht mehr klar kam. Da nutzen FHEM-Backups und Config-Versionen gar nichts.
Da auch nicht einfach mal einzelne Module ausgeschaltet werden konnten, war es nicht mal möglich das Problem zu lokalisieren. Eine Datei hätte hier zumindest mehr Möglichkeiten geboten.
Wenn das an mich ging: ja. Dann habe ich mich wohl falsch ausgedrückt denn ich sehe das genauso !
Bin auch dagegen. Erhöht einfach die Komplexität des Gesamtsystems zu sehr und den Nutzen halte ich für überschaubar.
Ich halte es generell für nachteilig, diese ganze Versionierungsthematik überhaupt zu einem FHEM-Thema zu machen. Textdateien sind als Schnittstelle super easy. Jeder Nutzer kann eine Datei kopieren um ein Backup zu erstellen und die Dateien sind mit jedem Textviewer zu betrachten. Es gibt außerdem seit Jahren bzw. Jahrzehnten etablierte Versionierungssystem wie SVN oder GIT, die genau für diesen Zweck gemacht worden sind. Warum das Rad an der Stelle mit einer eigenen FHEM-Versionierung neu erfinden?
Begründung:
Ich sehe in fhem.cfg im Gegensatz zu configDB keinen wirklichen Mehrwert, aber jede Menge Probleme wenn die User der Meinung sind sie müssen mit einem externen Editor die cfg bearbeiten oder mit cfg includes arbeiten.
Die Einfachheit der Config-Dateien (wie sie praktisch jeder Linux-Dienst nutzt) ist für mich gerade _kein_ Nachteil, sondern sogar Vorteil. Die Motivation auf ConfigDB zu wechseln, darf doch wohl nicht sein, die Configs so hinter Komplextität verstecken zu wollen, dass der normale Nutzer keinen direkten Zugriff mehr darauf hat, oder?
Zitat von: vbs am 31 Juli 2017, 12:51:16
Jeder Nutzer kann eine Datei kopieren um ein Backup zu erstellen und die Dateien sind mit jedem Textviewer zu betrachten. Es gibt außerdem seit Jahren bzw. Jahrzehnten etablierte Versionierungssystem wie SVN oder GIT, die genau für diesen Zweck gemacht worden sind. Warum das Rad an der Stelle mit einer eigenen FHEM-Versionierung neu erfinden?
Ich muss immer wieder miterleben wie gerade diese Einfachheit dafür sorgt das die User von Hand irgendwelche Konfigurationszeilen kopiert in ihre cfg einfügen und dann mit dem dadurch entstandenen Problem ins Forum kommen.
Manchmal ist ein kleiner Stolperstein und das damit auf die Nase fallen ganz gut damit die User noch mal darüber nachdenken was sie da gerade machen wollen.
Das wäre gegeben wenn sie sanft zur Verwendung von FHEMWEB zur Konfiguration ihres FHEM gezwungen würden. Hier würde zu mindest eine Grundprüfung statt finden.
Zitat von: CoolTux am 31 Juli 2017, 12:43:04
Finde ich gut das Beispiel. Denn hier sieht man wo man trennen kann/"sollte".
Die Grundkonfiguration ist in der Tat immer eine Textdatei. Erweiterte Konfigurationen kann man aber auch DB basiert ablegen (bind,sendmail). Und das macht durchaus Sinn. Denn gerade bei bind kann die erweiterte Konfig sehr dynamisch sein. Daher lege ich hier die Konfigurationen in ein LDAP/eDirectory ab. DB basiertes Backend.
Prima. Dann haben wir doch Einigkeit: configDB für die professionalle/erweiterte Konfiguration als Option. Die Textdatei bleibt als Ausgangslösung.
Ciao, -MN
PS FHEM mag wachsend sein in dem Konfigurationsumfang - aber es gibt nur endliche Komplexität und die Konfig-Datei nähert sich einem Häufungspunkt an, da die Menge der noch zusätzlich umsetzbaren Dinge mit Implementierungsfortschritt eigentlich immer weniger wird.
Zitat von: Morgennebel am 31 Juli 2017, 13:13:28
PS FHEM mag wachsend sein in dem Konfigurationsumfang - aber es gibt nur endliche Komplexität und die Konfig-Datei nähert sich einem Häufungspunkt an, da die Menge der noch zusätzlich umsetzbaren Dinge mit Implementierungsfortschritt eigentlich immer weniger wird.
Aber dennoch nie gegen null laufen wird ;D
Obwohl ich selbst configDB nutze bin ich dennoch dagegen es anderen aufzwingen zu wollen.
Den Teil mit dem Support für kaputt gespielte Konfigurationsdateien kann ich ja nachvollziehen, aber hey - niemand zwingt dich doch dazu diesen zu leisten?!
Ich könnte nun auch behaupten, erst wenn die Schmerzen groß genug gewesen sind setzt ein Lerneffekt ein und man überlegt sich als Anwender ob man a) sich vorher besser über das Produkt informiert was man einsetzen möchte oder b) sich überlegt ob man sich nicht eher ein Testsystem anschafft um Änderungen zu implementieren/testen. Ob das nun Einplatinencomputer, virtuelle Instanzen, Docker Container oder oder oder sind bleibt ja jedem selbst überlassen.
FHEM ist halt FHEM und nicht 'iOS', also ist und bleibt keine Klicki-Bunti Lösung die ohne den Willen Zeit und 'Arbeit' zu investieren laufen wird. Deswegen nun einen Weg als Verbesserungsvorschlag zu gehen die Anwender zu 'entmündigen' halte ich für grundverkehrt. Wie gesagt - ich nutze die configDB weil ich sie mag und es mir zutraue darin Änderungen vorzunehmen (auch das hat Zeit, Arbeit und Willen erfordert) mit den Dingen die ich mir in den letzten Monaten/Jahren angeeignet habe und von denen ich auch immer mal wieder was vergesse und wieder anlesen muss ;)
Sicherlich haben auch viele (Achtung Vermutung) sehr kleine und einfache Konfigurationen die nicht über ein paar Heizungen und Steckdosen hinaus gehen. Ob man sowas alles mit einer SQL Datenbank erschlagen muss wage ich auch zu bezweifeln..
Just my 2cents
Zitat von: herrmannj am 31 Juli 2017, 12:43:46
Wenn das an mich ging: ja. Dann habe ich mich wohl falsch ausgedrückt denn ich sehe das genauso !
Nein , an CoolTux. Dein Beitrag ist dazwischengerutscht. Wir haben ja im Prinzip die gleichen Argumente - wie die Mehrheit hier :)
Ich denke, wir können die Diskussion hier beenden. Textdateien sind einfach unschlagbar für Konfigurationen. Alles bleibt wie es ist. Wer will kann mit vertretbaren Aufwand auf ConfigDB wechseln.
Eine neue Baustelle wäre, wie man dem Nutzer bessere Alternativen zum Ändern der Config
-Datei anbieten kann, z.B. Wizards, Templates, Scripte, Drag&Drop, ....
Diese Diskussion ist müssig. Hier "argumentieren" in der Mehrzahl Menschen gegen etwas, womit sie sich selbst noch nie in der Praxis (!) auseinandergesetzt haben.
Zitat von: waschbaerbauch am 31 Juli 2017, 13:57:22
bin ich dennoch dagegen es anderen aufzwingen zu wollen.
Die fhem.cfg wird den Anwendern auch aufgezwungen...
Aber es geht nicht um aufzwingen, sondern darum, was für die Anwender geeignet ist. Und wenn ich mir hier im Forum umschaue, finde ich definitiv mehr Threads, bei denen die Probleme aus der Verwendung von fhem.cfg stammen als aus der Verwendung von configDB.
Wenn ein Problem innerhalb einer Installation seine Ursache ausserhalb von FHEM hat, ist es eigentlich völlig egal, ob man FHEM mit fhem.cfg oder configDB betreibt. Das Problem muss ausserhalb von FHEM gelöst werden. Dazu hilft oft schon ein Blick in die Logs des Betriebssystems.
Zitat von: betateilchen am 31 Juli 2017, 14:16:22
Aber es geht nicht um aufzwingen, sondern darum, was für die Anwender geeignet ist. Und wenn ich mir hier im Forum umschaue, finde ich definitiv mehr Threads, bei denen die Probleme aus der Verwendung von fhem.cfg stammen als aus der Verwendung von configDB.
Ist ja auch irgendwie logisch, oder?
100% der FHEM-Installationen kommen mit fhem.cfg. Geschätzt 1% der Anwender nutzt configDB, die dafür Expertenwissen brauchen.
Natürlich tauchen dann die Probleme eher im Bereich fhem.cfg auf.
Ciao, -MN
Zitat von: betateilchen am 31 Juli 2017, 14:16:22
Wenn ein Problem innerhalb einer Installation seine Ursache ausserhalb von FHEM hat, ist es eigentlich völlig egal, ob man FHEM mit fhem.cfg oder configDB betreibt. Das Problem muss ausserhalb von FHEM gelöst werden. Dazu hilft oft schon ein Blick in die Logs des Betriebssystems.
Ja, genau. Und hier sind viele unserer Anfragen im Supportforum zu sehen. Anwender ohne Linux/Unix-Kenntnisse, die nur FHEM von einem SDCARD-Image nutzen und dann den "apt-get upgrade"-Befehl eintippen. Das macht dann irgendwas kaputt, aber die Linux-Kenntnisse zur Fehleranalyse fehlen.
Oder anders gesagt: mit wachsender Bekanntheit von FHEM sind die Anwender keine IT-Vollprofis mehr, sondern mehr und mehr normale Sterbliche, die sonst ihre Micky-Mouse-Oberfläche zum Mausschubsen nutzen (nicht böse gemeint) und lernen.
Die Aufmerksamkeitsspanne ist nur zu kurz, um alles zu lesen und auszuprobieren. Der Wille zum lernen nicht ausgeprägt. Während wir IT-Vollprofis und Bastler gewohnt sind, Stunden über Stunden auszuprobieren, zu lesen, zu experimentieren - will das dieser Anwenderkreis gar nicht.
Es soll halt laufen. Und wenn es nicht geht, schreit man um Hilfe...
Wie wäre denn innnerhalb von FHEM ein "CheckServerHealth"-Modul, daß die üblichen Dinge prüft - wie z.B. ist DNS erreichbar, ist der Router erreichbar, ist die Platte voll, sind die Besitzer aller Dateien richtig - Basistests wie der Fehlerbehebungs-Wizard von M$. Das Logfile liesse sich entsprechend in das Forum kopieren und dann wird die Fehleranalyse einfacher.
Ciao, -MN
Zitat von: Morgennebel am 31 Juli 2017, 14:41:07
100% der FHEM-Installationen kommen mit fhem.cfg. Geschätzt 1% der Anwender nutzt configDB, die dafür Expertenwissen brauchen.
1.
Man braucht dafür kein Expertenwissen. Ich bin alles andere als ein Datenbankexperte (oder IT-Profi), nutze ConfigDB aber problemfrei sei ca. einem Jahr. Ich war zunächst auch skeptisch, ob diese weitere Komplexität für mich Sinn macht, und: Ich habe neulich einen neuen Server aufgezogen und gleich wieder auf configDB umgestellt. Mir gefällt die Versionierung, und es ist mir (im Ggs. zu fhem.cfg) noch nie passiert, dass ich "versehentlich" durch ein "Save" Geräte gelöscht habe. Das war mir mit einigen OWX-Devices gelegentlich passiert, die hin und wieder aus irgendwelchen Gründen weg waren.
2. Backups aus configDB in Form einer fhem.cfg anzufertigen ist auch kein Hexenwerk. Es ist (nach meiner Kenntnis, kann zwischenzeitlich auch anders sein) nur nicht sauber dokumentiert. Wen's interessiert: save, damit nichts verlorengeht, dann global-attribut für config ändern, speichern (es wird die config in den angegebene Datei gespeichert, Neustart wieder mit configDB; das war's, jedenfalls so aus dem Kopf). Vermutlich ginge das ähnlich mit den aktuellen states.
3. Aufzwängen finde ich auch grenzwertig, aber:
a) man kann fhem auch weiter mit cfg's nutzen, es würde nur den Standard ändern
b) Wer FHEM dann dereinst nur mit configDB kennt, wird keine cfg's vermissen
Trotzdem würde ich das gerne nicht entscheiden müssen: Ich habe noch nie einen rescue-Modus gebraucht, und das Reihenfolgethema beim Laden, das nur noch bei manchen Modulen ein Problem darzustellen scheint, habe ich auf andere Weise im Griff...
Just my2ct.
Zitat von: Beta-User am 31 Juli 2017, 14:59:48
1. Man braucht dafür kein Expertenwissen.
Doch, denn:
- wiki.fhem.de Artikel verweist nur auf die Commandref
- Commandref liegt nur in Englisch vor
- 3 DB-Arten angeboten, aber nur eine Erläuterung für sqllite bei den Perl-Modulen (und wie installiert man die gleich?)
- 15 neue Befehle zur Administration der configDB
Und das für User, die nicht ein Linux bedienen können.
Ich glaube Dir, daß Du das alles für trivial einfach hälst. Aber der Großteil der FHEM-Anwender hat nicht Deine Kenntnisse zur Computeradministration, zu Linux und zu Datenbanken.
Und im Fehlerfall, im Panikmodus, ohne Internet, ohne Konsole, ohne VPN - ist das ein Problem.
Ciao, -MN
1. ist es m.E. ok, wenn es eine Doku gibt, und man ladet von allen genannten Stellen zielgerichtet dort, wo alles wesentliche zu finden ist. Dass es in Englisch und reichlich technisch ist, mag man als Nachteil empfinden. Aber der, der's wirklich braucht, wird es zu schätzen wissen, dass nicht überall irgendwelche Halbwahrheiten stehen.
2. Korrekterweise sprechen wir für Anfänger nur von configDB@sqlite. Wenn das standardmäßig mitinstalliert und eingerichtet würde, würde sich der "einfache" Anwender sicher gar nicht erst damit auseinandersetzen müssen. Es würde trotzdem ootb funktionieren.
3. Er würde sich dann auf der anderen Seite im Fehlerfall auch nicht ohne Anleitung zutrauen, das selbst zu fixen. Und bei gefühlt 10 Fragen pro Jahr im Forum, die mit unverstandenen Rechtefragen zu tun haben, wäre das vermutlich auch besser, dieser Nutzerkreis würde vorher überlegen, was er überhaupt tut bzw. tun muß. Dann hätten wir weniger wirklich kaputte Installationen; dazu kommen die vielen Beiträge, denen fehlerhaftes Editieren zugrundeliegt, die könnten wir uns auch (weitgehend) ersparen.
4. Ich halte weder für trivial einfach, was im Hintergrund abläuft, noch das, was man an Kenntnissen (eigentlich) haben sollte, um sinnvoll mit Werkzeugen wie FHEM umzugehen; dabei ist mir klar, dass ich deutlich mehr weis, wie der "übliche Windoof-Nutzer". Trotzdem ist das eben nur ein kleiner Ausschnitt, und manches ist erarbeitet mit Erfahrungen, die man nicht unbedingt gemacht haben muß.
Daher sollten wie (FHEM/Linux) Anfängern gerne auch eine Art Cookbook an die Hand geben, wie sie sinnvolle Backups etc. machen können. Wer damit nicht klarkommt, dem sollte man derart mächtige Werkzeuge schlicht nicht an die Hand geben bzw. hier ist es insgesamt evtl. besser, er läßt die Finger ganz von seiner Hausinstallation.
Just my2ct.
Zitat von: Morgennebel am 31 Juli 2017, 15:09:59
- 15 neue Befehle zur Administration der configDB
Die configDB an sich muss von FHEM aus nicht administriert werden, um zu funktionieren. Das zeigt sich schon daran, dass die "15 neuen Befehle" in einem eigenen Modul liegen, das standardmäßig gar nicht geladen ist.
Zitat von: Morgennebel am 31 Juli 2017, 15:09:59
- 3 DB-Arten angeboten, aber nur eine Erläuterung für sqllite
Wer es schafft, auf seiner Plattform einen Datenbankserver (mysql oder postgresql) zum Laufen zu bringen, der schafft es auch, eine leere Datenbank und einen Benutzer dazu anzulegen.
Zitat von: Morgennebel am 31 Juli 2017, 15:09:59
- Commandref liegt nur in Englisch vor
Ja, und? Das entspricht 100% den Entwicklungsvorgaben von FHEM.
Zitat von: Beta-User am 31 Juli 2017, 15:44:35
2. Korrekterweise sprechen wir für Anfänger nur von configDB@sqlite. Wenn das standardmäßig mitinstalliert und eingerichtet würde, würde sich der "einfache" Anwender sicher gar nicht erst damit auseinandersetzen müssen. Es würde trotzdem ootb funktionieren.
sqlite3 ist inzwischen als Voraussetzung zur Installation von FHEM aus einem debian Paket festgelegt.
Ausserdem wird die ganze Diskussion zu den Datenbankarten bei DbLog komischerweise nie geführt. Und dort ist das um einiges komplexer.
Zitat von: betateilchen am 31 Juli 2017, 15:51:21
Ausserdem wird die ganze Diskussion zu den Datenbankarten bei DbLog komischerweise nie geführt. Und dort ist das um einiges komplexer.
Weil hier auch die natürliche Aufgabe von Datenbanken genutzt wird - das Verwalten großer Datenmengen bzw. der schnelle Zugriff auf diese. Da erübrigt sich die Diskussion. Genau dafür wurden Datenbanken erfunden.
Nutzte ich allerdings ehrlich gesagt auch nicht. Ich finde eh das übermässige Loggen von Daten im privaten Bereich sehr grenzwertig. Gerade wenn es um so Sachen geht wie - da warst Du aber nicht zu Hause, da FHEM keine Anwesenheit / das Licht aus war / die Haustür seit 5 Stunden nicht geöffnet war / .... geloggt hat. Aber auch hier kann der User es ja einschalten, wenn er denn will. Das Basissystem kommt mit dem "einfacheren" FileLog aus.
Zitat von: papa am 31 Juli 2017, 16:03:55
Das Basissystem kommt mit dem "einfacheren" FileLog aus.
Ein Basissystem kommt sogar ganz ohne Log aus...
Zum Thema Datenmengen: Bei mir liegen aktuell ca. 300 zusätzliche von FHEM benötigte Dateien in der configDB (nicht nur gplot, holiday, und layout-Dateien, sondern auch images, die in InfoPanels verwendet werden). Das macht die Portierbarkeit auf neue Plattformen oder das Duplizieren von FHEM Systemen extrem einfach.
configDB tut durchaus etwas mehr, als nur die Textdatei "fhem.cfg" in Tabellenzeilen zu schreiben...
@betateilchen
Das hat doch auch gar keiner bestritten - es ging hier doch nur um die erfragte Meinung der Nutzer zum Thema 'Sollte man generell eine fhem.cfg durch eine configDB in einer Standard FHEM Installation ersetzen'. Die Entscheidung liegt sowieso beim FHEM Vater selbst.
[offtopic]
Wie ich schon schrieb, ich persönlich weiß deine Arbeit mit der configDB zu schätzen, setze sie hier produktiv in meinem Haus ein und komm auch immer mal wieder mit der Wartung klar, obwohl ich kein Datenbank Hero bin. Also Wartung = Aufräumarbeiten wenn ich 'autocreate' aktiv hatte, vergessen hab abzustellen und dann Monde später merke das sich 20+ PCA301 Dosen und anderes Zeugs eingeschmuggelt haben.
Ich für meinen Teil (vermutlich schon umständlich, aber ich kann es halt nicht besser) lade dann die configDB in den DB Browser für SQLite und werfe dann alles über die Suchmasken raus was da nicht rein gehört. Wenn 'autoshrink' nicht geht, dann muss das halt auch noch über die Kommandozeile erfolgen. Für mich passt das so, für Otto-Normal-Anwender vielleicht eher nicht, der bekommt vielleicht aber auch nicht diese Flut an Fremd-/Phantomgeräte ins FHEM und muss sie dann umständlich über das FHEM Webfrontend löschen..
[/offtopic]
Meiner Meinung nach ist es eh schwierig zu ermessen wie viele Probleme überhaupt hier aufschlagen von allen die mit der fhem.cfg auftreten. Ebenso wenig kann man (für die Masse) auch sagen wie nützlich die Funktion zum self-editing ist und wie viele Probleme auch ohne Forum mit einem Editieren der fhem.cfg gelöst wurden. Man sollte dem Nutzer einfach die Wahl lassen ob er fhem.cfg möchte oder configDB. Der Leitfaden zur Migration auf die configDB existiert ja, von daher würde ich persönlich keinen Grund zu einer Änderung sehen. Der kleinste gemeinsame Nenner würde da aus meiner Sicht Sinn machen und das ist nun mal die fhem.cfg ..
Ich schließe mich waschbaerbauch in Gänze an ! Lasst bloß bitte beide Alternativen ! Wie die Tage mal wieder(Fixel) zu sehen war, ist configDB eine Blackbox. Geht mal etwas nicht, warum auch immer, kann man die Blackbox schütteln und rütteln wie man will. Man starrt hilflos auf die Blackbox. Mit der .cfg lässt sich per trial and error in Nullkommanix die Fehlerstelle finden.
Zitat von: KölnSolar am 31 Juli 2017, 22:26:48
Wie die Tage mal wieder(Fixel) zu sehen war
Ich finde es ja nett, dass hier mehrfach dieser Fall als Beispiel angeführt wird, denn genau in diesem Fall hätte eine manuelle Bearbeitung der Konfiguration doch gar nicht weitergeholfen.
Hat ja auch niemand behauptet. ::)
Aber VIER Tage verzweifelte Fehlersuche, 84 Posts(die meisten von wirklichen FHEM-Experten), ein Testaufbau von Cooltux .....sind doch ein gutes Beispiel was an der configDB nachteilig ist...
Zitat von: KölnSolar am 01 August 2017, 06:44:50
Hat ja auch niemand behauptet. ::)
Aber VIER Tage verzweifelte Fehlersuche, 84 Posts(die meisten von wirklichen FHEM-Experten), ein Testaufbau von Cooltux .....sind doch ein gutes Beispiel was an der configDB nachteilig ist...
Würde ich so nicht sagen. Mein Testaufbau hatte weniger mit der Nachteiligkeit als mehr mit Lerneffekt zu tun. Ich habe mich schlicht und einfach mit sqlite noch nicht auseinander gesetzt gehabt.
Das man sich in so einem Fall auch mit der sqlite Syntax auseinander setzen muss ist doch normal. Da konnte man ja nun gar nichts mehr machen mit FHEM.
Aber mit einer cfg wäre das auch nicht besser gewesen. Man muss sich auch in vi oder nano einarbeiten.
Ich denke mal es wurde genug zum Thema beigetragen um zu sehen das mehrheitlich die User gegen configDB als default Konfigurationsspeicher sind.
Vielen Dank an alle für die Diskussionsteilnahme.
Grüße
fhem.cfg bleibt die Voreinstellung.