Die commandref zu http://fhem.de/commandref.html#include bzw. http://fhem.de/commandref_DE.html#include vermittelt für mich den Eindruck als sei include sehr sinnvoll quasi notwendig, um die .cfg zu strukturieren. Dass es dabei viele Abhängigkeiten zu beachten gibt, wird in der commandref jedoch nicht erwähnt. Zudem animiert dies zum direkten Editieren der .cfg. Gerade Einsteiger/Anfänger werden so mMn in eine falsche Richtung geschickt und nutzen dann intensiv include ohne Kenntnis der Probleme/Abhängigkeiten. (aktuell: https://forum.fhem.de/index.php/topic,54009.0.html)
Wäre es nicht sinnvoll in der commandref darauf hinzuweisen, dass include eine Expertenfunktion ist und grundsätzlich keinerlei Notwenigkeit zur Nutzung und manuellen Bearbeitung der .cfg besteht?
Gruß, Christian
Ich wäre sogar dafür diese Passagen komplett zu entfernen.
Entfernen ist natürlich nicht nötig. Es gibt schon auch Gründe für sehr fortgeschrittene User, include zu verwenden (ich denke da an Testsysteme bei Entwicklern). Hinweise auf die "Gefahren" bzw. der klare Hinweise darauf, dass include UND die Strukturierung der config nicht notwendig ist, halte ich jedoch für angebracht.
Man sollte es tief in der Commandref verstecken. Fett rot Expertenfunktion schreiben und dazu das es keinerlei Support bei Verwendung gibt. Meine Meinung.
Grüße
Habe die Beschreibung verkuerzt, und mit "Dieses Befehl sollte nur von Experten verwendet werden." ergaenzt.
Bin noch unentschlossen, wie man ein System baut, was sowohl von Neulingen, wie auch von Erfahrenen verwendet werden kann. Eigentlich tendiere ich zu "du hast alle Freiheiten, auch das System kaputtzukonfigurieren", was fuer Neulinge ein Problem ist. "attr global expert" ist sinnlos, wie wir das bei der Einfuehrung von editConfig gesehen haben.
Textbasierte Konfigurationsdateien abschaffen.
Zustimmung
Nach dieser Logik ist das Registry dem /etc/* eindeutig ueberlegen :)
Sehe ich nicht so. Es kommt auf das Umfeld und die Gegebenheiten an. Im Gegensatz zu FHEM bietet Linux schon ein komplexeren Einstieg wenn man nicht gerade mit Ubuntu oder SuSe arbeitet. Hier ist man gezwungen vom Start er sich mit der Grundmaterie zu beschäftigen. Bei FHEM muss man kein Perl lernen und auch nicht die cfg kennen. Man kann wunderbar ohne arbeiten. Und muss den Umgang mit cfg auch nicht lernen zum arbeiten.
Aber genau das wäre Voraussetzungen wenn man mit include arbeiten will. Man sollte die Abhängigkeiten lernen und erkennen.
Ich wäre für eine Umstellung auf configDB von Start weg.
ZitatHabe die Beschreibung verkuerzt, und mit "Dieses Befehl sollte nur von Experten verwendet werden." ergaenzt.
Danke!
Zitat von: rudolfkoenig am 31 Mai 2016, 11:07:20
Eigentlich tendiere ich zu "du hast alle Freiheiten, auch das System kaputtzukonfigurieren", was fuer Neulinge ein Problem ist.
Ja.
Aber wir können Anfängern per Doku eine Richtung zeigen, wie man einfacher starten kann und "include" gehört mMn eben nicht (mehr?) dazu.
Btw: der hilfreiche codemirror ist auch recht gut in der Doku versteckt.
zum Offtopic: ich möchte meine textbasierte Konfig und nichts anderes... :)
Darfst und kannst Du ja gerne haben. So wie configDB gerade Optional ist und cfg File default kann man es ja dann umdrehen. configDB default und wer es anders mag cfg File Optional.
Das ist meine Meinung, nicht meine Religion ;D
Diese Diskussion kommt mir bekannt vor, gehört aber hier ggf. nicht wirklich hin. Im Grunde ist es völlig egal, was verwendet wird. Das Nachdenken wird nicht ersetzt und das ist es, woran es in der Regel liegt, dass die Dinge nicht funktionieren bzw. auch die Hilfe schwer ist, weil die Infos dementsprechend nicht geliefert werden.
Genau das mit dem Umdrehen meine ich auch.
Lasst uns doch mal (und das ist ernstgemeint) darüber nachdenken, ob man fhem in einer der nächsten Versionen (meinetwegen ab Release 6) mit der configDB als default unters Volk bringt. Die aktuellen Installationspakete bringen bereits alles mit, was dazu nötig ist, es müssen nur zwei Dateien aus ./contrib umkopiert werden.
Zitat von: krikan am 31 Mai 2016, 11:45:22
zum Offtopic: ich möchte meine textbasierte Konfig und nichts anderes...
@krikan: Warum? Hast Du das Arbeiten mit der Konfigurationsdatenbank jemals getestet? Welche Schwierigkeiten erwartest Du?
Zitat von: rudolfkoenig am 31 Mai 2016, 11:07:20
Bin noch unentschlossen, wie man ein System baut, was sowohl von Neulingen, wie auch von Erfahrenen verwendet werden kann.
Mal aus der Sicht eines Normalusers und ehemaligen Neulings:
Auf den ersten Blick fand ich bei Start mit FHEM (totaler Newbie) die Option der includes EXTREM ATTRAKTIV.
Nach wie vor verwende ich sie, und zwar gerne!
Die große Skepsis der includes gegenüber von eurer Seite (Entwicklerperspektive) kann ich andererseits auch sehr gut nachvollziehen ;), da es eben deutlich etwas anderes ist, als nur eine fhem.cfg zu haben (ich habe damit zwar niemandes Zeit mit diesbezüglichen selbstverursachten Fragstellungen gestohlen, bin aber näherungsweise verzweifelt, bis ich verstanden habe, dass man dabei peinlich genau die Reihenfolge planen sollte, in der die einzelnen Bausteine geladen werden!!!).
"Damals" (das ist die Ewigkeit von ca. 30 Monate her) gab es (zumindest aus meiner möglicherweise beschränkten Perspektive) nur die Option, die config direkt zu bearbeiten - was ja aus durchaus berechtigten Gründen mittlerweile ebenfalls unerwünscht ist (im
aktuellen Einsteiger-pdf aber noch als
muss drin ist (S. 20/21!!!- und ja, das pdf ist super!)). Das hatte allerdings zwei sehr große Haken:
- ab einer gewissen Anzahl von Devices wird die fhem.cfg sehr unübersichtlich, insbesondere um sie zu editieren (bin HW-seitig wg. einer Renovierung gleich mit ca. 8 HM-Rolläden und diversen Dimmern usw. gestartet).
- eine gewisse Versionierung geht auch nur, wenn man die Kommentierungsfunktion nutzt, um "alte" Fassungen als Datenbasis verfügbar zu halten. Ich nutze das vor allem für das Basteln komplexerer Dinge wie DOIF's usw., und ja, configDB kann das sicher besser, Betateilchen, ich weiß. codemirror höre ich eben zum ersten Mal...
Rudolf ist nur beizupflichten, dass es unendlich schwierig ist, hier die "richtige" Balance zu finden, vor allem um Unerfahrene/Interessierte sinnvoll zu leiten und trotzdem Experten (oder denen, die ihre Erfahrungen gemacht haben) alle Möglichkeiten offen zu lassen. Ich wäre als zwischenzeitlich überzeugter fhem-User wahrscheinlich beigedreht, wenn mir damals jemand gesagt hätte, ich müsse vorneweg erst mal einen Datenbankserver aufsetzen, um fhem testen zu können (ich hatte (m)eine Fritzbox für meine ersten Versuche genutzt und ja, ich habe vorher auch schon Linux-Erfahrung und auch schon mal anderweitig eine MySQL-DB aufgesetzt).
Langer Rede kurzer Sinn:
Gerne bringe ich bei Interesse meine persönlichen Erfahrungen und Ideen ein, um anderen FHEM schmackhaft zu machen.
Anmerkungen in diese Richtung dazu noch:
V.a. am Anfang ist es schwer, sich überhaupt zu orientieren um einen Ansatzpunkt zu haben, wie man sinnvollerweise vorgeht bzw. was es benötigt. Weder das Einsteigerdokument noch das Wiki geben dazu so richtig Auskunft.
Etwas überspritzt formuliert würde ich es für Interessierte in die Richtung sagen:
FHEM ist etwas für Leute, die
- eine Möglichkeit suchen, über ihr Smartphone ihre Haustechnik zu steuern
- Informationen rund um's Haus zentral erfassen und auswerten können wollen
- eine vorhandene Hausautomatisierung grafisch anders darstellen wollen oder
- allgemein: im IoT nicht auf einen Hersteller oder eine bestimmte Lösungsmöglichkeit angewiesen sein wollen
Für FHEM braucht es:
- Freude am Experimentieren und Dazulernen
- einen 24/7 Server
- Schnittstellen für die Kommunikation mit der realen Welt
- Entscheidungsfreude: Für fast alle Dinge, die man mit einer Hausautomatisierung tun könnte, gibt es mindestens 2 Wege! Also: Einlesen und Entscheiden!!!!
Was tue ich, wenn ich noch keinen 24/7-Server betreibe?
-
Kauf einen RPi, laß Deine FB wie sie ist! (Oder such' dir andere Server-HW, aber die 50€ sind mindestens für erste Versuche gut investiert!)
Welche Schnittstellen brauche ich?
- Welche HW willst Du steuern bzw. hast Du???
(Orientierungshilfe....)
Zitat von: joe_re am 31 Mai 2016, 12:14:02
Mal aus der Sicht eines Normalusers und ehemaligen Neulings:
...
wenn mir damals jemand gesagt hätte, ich müsse vorneweg erst mal einen Datenbankserver aufsetzen, um fhem testen zu können (ich hatte (m)eine Fritzbox für meine ersten Versuche genutzt und ja, ich habe vorher auch schon Linux-Erfahrung und auch schon mal anderweitig eine MySQL-DB aufgesetzt).
Niemand muss vorneweg einen mysql Server aufsetzen, um ein datenbankbasiertes fhem zu testen. Das vorhandene .deb Paket enthält heute schon alles, was man braucht, um damit sofort anzufangen. Es werden lediglich zwei zusätzliche perl Pakete benötigt, die aber auch bereits heute im controlfile enthalten sind, das die .deb Installation steuert.
Und das Thema Fritzbox sollte für uns irgendwann nicht mehr Entscheidungsgrundlage sein. Mein Vorschlag mit der Umstellung würde sich nur auf Neuinstallationen auswirken.
AVM selbst hat zur Beerdigung von FHEM auf Fritzboxen beigetragen. Ich denke mal irgendwann sollte man da den Deckel zu machen und gut ist.
Zitat von: betateilchen am 31 Mai 2016, 14:06:16
Niemand muss vorneweg einen mysql Server aufsetzen, um ein datenbankbasiertes fhem zu testen.
Das ist beruhigend.
Wäre das damals so gewesen, dass die Installationsroutine von FHEM angeboten hätte, z.B. eine/die benötigten sqlite-Datenbank(en) anzulegen (ohne dass ich mich um die Details hätte kümmern müssen), hätte ich vermutlich "ok"/"yes" gewählt und wäre heute glücklicher Datenbank-user, der wüßte, wie man DOIFs mit FHEMWEB definiert... ::)
Allerdings zögere ich im Moment noch, zu den datenbankbasierten Versionen umzusteigen, obwohl v.A. meine vielen Logfiles echt nervig sind. Gründe:
- Angst, dass das eine One-Way-Street ist, die mich überfordert (never change a running system & der WAF wäre negativ, sollte was schiefgehen...)
- Die Duko zum Umstieg auf dblog@sqlite (z.B.) ist zwar nachvollziehbar und nicht übermäßig kompliziert, allerdings kommt mir das Umstellen meiner plots und der Umzug der ganzen Daten so vor, als benötigt man dafür doch ordentlich Zeit, wenn man es halbwegs sinnvoll machen will; nicht ganz klar wäre mir dabei, wie/ob ich meinen ganzen Datenwust da mit reinschießen will... (bzw. bei Nichtgefallen jemals wieder rausbringe; mit Datenbankdumps habe ich wenige, aber schlechte Erfahrungen). Ob das die angenommenen Vorteile bei Geschwindigkeit (?) und Schreibzugriffen (?)
- Was configDB angeht, sehe ich sehr wohl die Vorteile; andererseits
- bin ich zu doof, irgendein neues DOIF über FHEMWEB anzulegen;
- kenne ich die Stolperstellen beim direkten Editieren zwischenzeitlich einigermaßen
- ich schraube auch nicht mehr so häufig an der config, dass eine Versionsverwaltung lohnenswert wäre
- manchmal ist ein richtiges "delete" beruhigender wie unbeabsichtigte Reste, die vielleicht irgendwas irgendwann durcheinanderbringen (bitte keine Kommentare wie "Das ist Quatsch")
- und meine ca. 10 includes sind so strukturiert, dass jedenfalls ich mich zurechtfinde.
Zitat von: CoolTux am 31 Mai 2016, 14:10:30
AVM selbst hat zur Beerdigung von FHEM auf Fritzboxen beigetragen. Ich denke mal irgendwann sollte man da den Deckel zu machen und gut ist.
+1 :)
Ich bin sehr froh, dass ich mit FHEM nicht mehr auf der FB bin, allerdings war es für mich damals als Testumgebung attraktiv und diese Option ist immer noch Bestandteil der Einsteigerdoku usw. Vielleicht sollte man wenigstens beim entsprechenden Board den sticky-Warnhinweis anbringen, dass das eine Sch..Idee sein könnte 8). Andererseits habe ich seit mehr als 10 Jahren immer mindestens eine Linux-Kiste irgendwo stehen; hätte ich damals gewußt, dass es ganz simpel und ungefährlich ist, FHEM auf praktisch jedem beliebigen Rechner zu installieren, hätte ich vermutlich nicht gerade die blödeste aller Optionen gezogen.
Zitat von: joe_re am 31 Mai 2016, 15:11:13
- Angst, dass das eine One-Way-Street ist,
Ist es nicht. Die bestehende Konfiguration wird bei der Migration nicht angetastet.
Zitat von: joe_re am 31 Mai 2016, 15:11:13
allerdings kommt mir das Umstellen meiner plots und der Umzug der ganzen Daten so vor, als benötigt man dafür doch ordentlich Zeit, wenn man es halbwegs sinnvoll machen will;
Ich glaube, Du verwechselt gerade die Umstellung von FileLog auf DbLog mit der Umstellung von fhem.cfg auf configDB. Die .gplot Dateien werden bei der Migration automatisch
unverändert in die Datenbank abgelegt.
Zitat von: joe_re am 31 Mai 2016, 15:11:13
- bin ich zu doof, irgendein neues DOIF über FHEMWEB anzulegen;
ein "leeres" DOIF anlegen, dann auf DEF klicken und mit codemirror den Ausführungsteil bearbeiten, genau wie jetzt im configfile auch. Vorteil: Syntaxhighlighting etc.
Zitat von: joe_re am 31 Mai 2016, 15:11:13
- manchmal ist ein richtiges "delete" beruhigender wie unbeabsichtigte Reste,
Stimmt. Darum gibt es das auch in der Datenbank.
Alle Punkte, die Du hier als Gründe fürs Zweifeln anführst, höre ich immer wieder. Aber sie kommen ausnahmslos immer von Leuten, die eine Migration noch nie ausprobiert haben.
Ich mache Dir einen Vorschlag: Auf dem nächsten großen Usertreffen in Karlsruhe (falls eines stattfindet) machen wir aus Deiner Installation ein Thema und zeigen die Migration Deiner Installation auf configDB als Präsentation, meinetwegen auch live.
Zitat von: joe_re am 31 Mai 2016, 15:11:13
Wäre das damals so gewesen, dass die Installationsroutine von FHEM angeboten hätte, z.B. eine/die benötigten sqlite-Datenbank(en) anzulegen (ohne dass ich mich um die Details hätte kümmern müssen), hätte ich vermutlich "ok"/"yes" gewählt und wäre heute glücklicher Datenbank-user
Probiers einfach aus: https://forum.fhem.de/index.php/topic,54055.0.html
Und heute abend produziere ich noch einen Workshop mit Screenshots für joe_re in dem gezeigt wird, wie man DOIF im Frontend anlegt. Das kann ich von dem PC hier aus nicht machen.
Zitat von: betateilchen am 31 Mai 2016, 15:24:46
Ist es nicht. Die bestehende Konfiguration wird bei der Migration nicht angetastet.
Ist schon klar, zumal man immer hergehen kann und die derzeitige textbasierte Konfiguration wegspeichern. Um es klarer zu sagen: Ich ändere zwar nicht viel, aber doch hin und wieder was, daher ging es mir eher um die zwischenzeitlichen Änderungen, die bei einer "Rückkehr" weg sein könnten.
Oder gibt es einen einfachen Weg, eine aktuelle lauffähige fhem.conf aus der Datenbank zu extrahieren und dann bei Nichtgefallen der DB-Lösung mit der wieder weiterzumachen?
Zitat von: betateilchen am 31 Mai 2016, 15:24:46
Ich glaube, Du verwechselt gerade die Umstellung von FileLog auf DbLog mit der Umstellung von fhem.cfg auf configDB. Die .gplot Dateien werden bei der Migration automatisch unverändert in die Datenbank abgelegt.
Auch hier sorry, dass ich das nicht klar genug zum Ausdruck gebracht habe: Mir ist schon bewußt, dass es um zwei Paar Schuhe geht, und man nicht entweder beides oder nichts haben muß. Meine persönliche Prio zum Einsatz einer Datenbank als solcher wäre aber performanceorientiert. Das hieße konkret, erst mal meine logs umzustellen. Und da müssen die gplots doch angepaßt werden, oder?
Zitat von: betateilchen am 31 Mai 2016, 15:24:46
Alle Punkte, die Du hier als Gründe fürs Zweifeln anführst, höre ich immer wieder. Aber sie kommen ausnahmslos immer von Leuten, die eine Migration noch nie ausprobiert haben.
Der Punkt geht an Dich; zu meiner Entschuldigung: Ich neige dazu, meine Systeme nur dann in wichtigen Bereichen umzukonfigurieren, wenn ich einen Nutzen sehen kann und
glaube, die Folgen überblicken zu können. für dbconf kann ich meinen persönlichen Nutzen noch nicht so richtig erkennen und allgemein empfinde ich Datenbanksysteme als relative black box; das letztere ist zwar kein Naturgesetz, sondern eine Frage des persönlichen Geschmacks, aber halt meines...
Zitat von: betateilchen am 31 Mai 2016, 15:24:46
Ich mache Dir einen Vorschlag: Auf dem nächsten großen Usertreffen in Karlsruhe (falls eines stattfindet) machen wir aus Deiner Installation ein Thema und zeigen die Migration Deiner Installation auf configDB als Präsentation, meinetwegen auch live.
Danke für's Angebot. Wenn ich kann, würde ich andere FHEMler tatsächlich gerne mal kennenlernen. Es ist echt interessant, wer sich hier so alles Dinge ausdenkt, die den "Will-haben"-Reflex auslösen ;). Ich wollte doch eigentlich auch nur meine Paar Rolläden zentral und ggf. zeitgesteuert steuern und komme mir (und anderen manchmal auch) mittlerweile vor wie der Freak...
Zitat von: betateilchen am 31 Mai 2016, 15:42:43
Probiers einfach aus: https://forum.fhem.de/index.php/topic,54055.0.html
Danke für die Mühe, das ist auf dem "Hinweg" ziemlich klar und definitiv auch für einen DAU wie mich kein Hexenwerk. Was mir persönlich wichtig ist/wäre und die zitierte "Angst" minimieren könnte:
Wie verträgt sich das mit meiner Backup - bzw. Notfall-Strategie?!? Will heißen:
Alles wesentliche muß auch ohne RPi bedienbar sein und laufen. Einen mehrtätigen Ausfall des RPi kann ich (bzw. auch meine Family) verkraften, Löcher in den Logs sind (jedenfalls im Moment) nicht schön, aber auch nicht tragisch. Ich sichere also nur hin und wieder meine Config-files und logs. Fällt mein RPi aus, würde ich einen neuen/anderen aufsetzen (bzw. nur die SD-Karte, je nachdem halt), fhem installieren, alles updaten und dann wieder meine files reinkopieren (und ggf. chown etc), fertig ist die Laube. Das gibt es sicher Verbesserungspotential, aber ich weiß, was ich wie zu tun habe (meine dd-Versuche waren da nicht so erfolgreich wie dieser Weg). Daher lasse ich auch die Finger von den GPIOs und sonstigen Features des RPi und stöpsel möglichst alle Schnittstellen über USB an und belasse den PI sonst (mit wenigen netzwerkbezogenen Ausnahmen) in der Grundkonfiguration.
Sobald ich gedanklich eine Datenbank dazwischenschalte, wird das Vorgehen um (min.) einen Schritt komplizierter. Das ist evtl. für die logs verkraftbar, wenn das einfache file-Kopieren nicht mehr klappt, für die fhem.conf wäre es verheerend.
Also (klar, sqlite usw. müßten ebenfalls schon installiert sein): Könnte ich die betreffende Datenbank-file einfach wieder von einem anderen Rechner rüberkopieren (und ggf. die Rechte anpassen) und es läuft dann, oder wie ist das?
Zitat von: betateilchen am 31 Mai 2016, 15:42:43
Und heute abend produziere ich noch einen Workshop mit Screenshots für joe_re in dem gezeigt wird, wie man DOIF im Frontend anlegt. Das kann ich von dem PC hier aus nicht machen.
Danke, war eigentlich eher als Witz gemeint ;) (obwohl ich tatsächlich mal über dieses "Problem" gestolpert bin).
Zitat von: joe_re am 31 Mai 2016, 16:47:29
Ich ändere zwar nicht viel, aber doch hin und wieder was, daher ging es mir eher um die zwischenzeitlichen Änderungen, die bei einer "Rückkehr" weg sein könnten.
Auch das sollte kein Grund sein, denn auch der Rückweg (quasi eine Rückmigration) mit allen in der configDB enthaltenen aktuellen Änderungen auf eine fhem.cfg ist jederzeit in weniger als 1 Minute möglich.
Zitat von: joe_re am 31 Mai 2016, 16:47:29
Könnte ich die betreffende Datenbank-file einfach wieder von einem anderen Rechner rüberkopieren (und ggf. die Rechte anpassen) und es läuft dann, oder wie ist das?
Ja! Im Falle von sqlite schon, da gibt es dann nur ein einziges Datenbankfile und wenn das, wie im default vorgesehen im fhem-verzeichnis liegt, ändert sich im Vergleich zum sichern und wiederherstellen einer fhem.cfg eigentlich gar nichts.
Zitat von: Benni am 31 Mai 2016, 17:28:16
Ja! Im Falle von sqlite schon, da gibt es dann nur ein einziges Datenbankfile und wenn das, wie im default vorgesehen im fhem-verzeichnis liegt, ändert sich im Vergleich zum sichern und wiederherstellen einer fhem.cfg eigentlich gar nichts.
Und es hat - im Gegensatz zur fhem.cfg - den Vorteil, dass in diesem einzigen File auch sämtliche gplot-Dateien und andere modulspezifische Konfigurationsdaten, z.B. layout Dateien für RSS und InfoPanel, holiday-Dateien etc. enthalten sind und sofort wieder zur Verfügung stehen.
Wird zwar immer mehr Offtopic aber eine Frage zu configdb habe ich noch:
Ist es möglich Dateien zu exportieren, um sie mit einem externen Editor zu bearbeiten, und trotzdem die exportierte Datei in FHEM zu benutzen?
Ich hatte bereits mal cofigdb und das war etwas das mir gefehlt hat.
Kommt auf die Datei an.
Das Vorhaben macht aber nicht soviel Sinn, da fhem ja bereits einen fuer Computerlaien relativ guten Editor mitbringt, der mit den Dateien korrekt umgeht und sie nach dem Editieren wieder genau dort abspeichert, wo sie hingehören.
Beschreibe doch mal genauer, um welche Dateien es bei Deiner Frage geht.
Du kannst die Frage aber auch gerne im Workshop-Thread stellen, den ich heute geschrieben habe.
Zitat von: betateilchen am 31 Mai 2016, 15:42:43
Und heute abend produziere ich noch einen Workshop mit Screenshots für joe_re in dem gezeigt wird, wie man DOIF im Frontend anlegt.
wie versprochen: https://forum.fhem.de/index.php/topic,54063.0.html
Zitatfhem ja bereits einen relativ guten Editor mitbringt
Da muss ich protestieren. Ich lasse hoechstens folgendes durchgehen:
"fhem ja bereits einen
fuer Computerlaien relativ guten Editor mitbringt"
Und damit waeren wir bei den Editor-Wars angekommen, und voellig off-topic. :)
ok, ich hab Deine vorgeschlagene Änderung im obigen Beitrag eingecheckt :D
Alles ist relativ...
Dass ich mal einen Workshop zum Thema DOIF machen würde, hätte ich mir auch nie träumen lassen.
Bevor ich jetzt noch anfange, Windoof zu installieren, gehe ich mal eine Flasche Wein aus dem Kühlschrank holen. Das hilft gegen solche blöden Gedanken.
ich hätte da mal eine frage zu config gb / migration. ich habe es mir zwar vorgenommen aber es noch nicht durchgeführt.
wie sieht die datenbank intern aus? wird stumpf alles in eine table geschrieben oder gibt es schon so etwas wie eine richtige struktur mit mehreren tabellen, verknüpfungen, normalisierung in der db selbst?
falscher Thread.
Bitte hier: https://forum.fhem.de/index.php/topic,54055.0.html
Zitat von: betateilchen am 31 Mai 2016, 19:31:47
Dass ich mal einen Workshop zum Thema DOIF machen würde, hätte ich mir auch nie träumen lassen.
Ich hatte schon bei der Ankündigung heute Mittag sorge, dass demnächst vielleicht noch die Hölle zu friert ;D
Die nicht-DOIF-freie Zone meldet:
Spieltrieb wurde angeregt, vor allem, weil scheinbar mehrere Leute an der Ergebnissen Interesse hatten. Ob es geklappt hat, sollten wir wohl an anderer Stelle diskutieren.
@Benni
Zitat von: Benni am 31 Mai 2016, 17:28:16
Auch das sollte kein Grund sein, denn auch der Rückweg (quasi eine Rückmigration) mit allen in der configDB enthaltenen aktuellen Änderungen auf eine fhem.cfg ist jederzeit in weniger als 1 Minute möglich.
Du könntest mir der Vollständigkeit halber verraten, wie die zugehörigen Befehle wären....
Nur für den Fall der Fälle....
@betateilchen
Danke für's Zitieren, dann mal Prost! Und: wo Windoof draufsteht, ist auch Windoof drin, da braucht es mehr als eine einzige Flasche, bis man das vergessen hat...
Zitat von: joe_re am 31 Mai 2016, 22:05:28
@BenniDu könntest mir der Vollständigkeit halber verraten, wie die zugehörigen Befehle wären....
Das steht doch schon x-Mal hier im Forum...
attr global configfile ./fhem.cfg
save config
shutdown
Zitat von: betateilchen am 31 Mai 2016, 22:07:39
attr global configfile ./fhem.cfg
save config
shutdown
Ich hätte an der Stelle eher einen ausdrücklichen Export-Befehl für die "aktualisierte" fhem.cfg (die ja in der Form nicht mehr exisitert, oder?) erwartet. Es ging mir um zwischenzeitliche Änderungen der Konfiguration.
Das "save config" sichert immer die aktuell laufende fhem Konfiguration.
Woher die ursprünglich kommt, ist dem "save"-Befehl in diesem Fall völlig egal.
Zitat von: betateilchen am 31 Mai 2016, 22:25:25
Das "save config" sichert immer die aktuell laufende fhem Konfiguration.
Woher die ursprünglich kommt, ist dem "save"-Befehl in diesem Fall völlig egal.
...und wieder was gelernt, Danke!
Hallo
ich hatte configDB getestet, und bin wieder zurück auf fhem.cfg gegangen.
Hatte alles schnell, einfach und fehlerfrei funktioniert.
Meine Gründe für die Zurückstellung:
-Save war mit configDB etwas langsamer
-Ich editiere nie in der fhem.cfg
(D.h. Es ist mir egal in welchem File die Config gespeichert wird)
-Ich sichere automatisch inkrementell Alle Config Files cfg gplot 99_... und sehe chronologisch alle Änderungen in einer einfachen Filestruktur, und muss mich nicht auf eine Anzahl von Versionen beschränken
(wäre z. B. noch eine Idee dies automatisch in fhem zu machen, wenn save gedrückt wird oder ein File im internen Editor gespeichert wird, bei Update wird es schon sehr gut gemacht)
-Im Fehlerfall oder bei vergleichen ist die Suche in Text Files schneller
-fhem.cfg ist kleiner
Wie gesagt ist Geschmackssache.
Gruß Hannes
Gesendet von meinem SM-T715 mit Tapatalk