configDB als Standard für Speicherung der FHEM Konfiguration

[herrmannj]

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 !

[vbs]

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?

Code Auswählen Erweitern

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?

[CoolTux]

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.

[Morgennebel]

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.

[CoolTux]

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 

[waschbaerbauch]

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

[papa]

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, ....

[betateilchen]

Diese Diskussion ist müssig. Hier "argumentieren" in der Mehrzahl Menschen gegen etwas, womit sie sich selbst noch nie in der Praxis (!) auseinandergesetzt haben.

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.

[Morgennebel]

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

[Morgennebel]

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

[Beta-User]

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.

[Morgennebel]

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

[Beta-User]

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.

[betateilchen]

• 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.

• 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.

• Commandref liegt nur in Englisch vor

Ja, und? Das entspricht 100% den Entwicklungsvorgaben von FHEM.

[betateilchen]

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.