configDB als Standard für Speicherung der FHEM Konfiguration

Begonnen von CoolTux, 31 Juli 2017, 09:26:28

Vorheriges Thema - Nächstes Thema

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

papa

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.

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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

CoolTux

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.

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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

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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

CoolTux

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?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

herrmannj

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 !

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?

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

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Morgennebel

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.
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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

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, ....
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

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.

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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Morgennebel

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
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

papa

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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

betateilchen

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...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

waschbaerbauch

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

KölnSolar

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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Benni

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.

KölnSolar

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...
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig