configDB als Standard für Speicherung der FHEM Konfiguration

[CoolTux]

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

[papa]

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.

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.

[CoolTux]

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.

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

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!!!

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

[herrmannj]

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

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

[papa]

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.

[CoolTux]

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

[Morgennebel]

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

[CoolTux]

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

[Morgennebel]

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

[CoolTux]

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.

[Morgennebel]

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

[CoolTux]

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?

[Morgennebel]

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

[Morgennebel]

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

[CoolTux]

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.