configDB als Standard für Speicherung der FHEM Konfiguration

[papa]

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.

[betateilchen]

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

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

[Benni]

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

[CoolTux]

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.

[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

[rudolfkoenig]

fhem.cfg bleibt die Voreinstellung.