Anpassung commandref zu include / Hinweis Expertenfunktion

[CoolTux]

AVM selbst hat zur Beerdigung von FHEM auf Fritzboxen beigetragen. Ich denke mal irgendwann sollte man da den Deckel zu machen und gut ist.

[Beta-User]

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.

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

[betateilchen]

- Angst, dass das eine One-Way-Street ist,

Ist es nicht. Die bestehende Konfiguration wird bei der Migration nicht angetastet.

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.

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

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

[betateilchen]

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.

[Beta-User]

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?

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?

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

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

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?

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

[Benni]

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.

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.

[betateilchen]

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.

[igami]

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.

[betateilchen]

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.

[betateilchen]

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

[rudolfkoenig]

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

[betateilchen]

ok, ich hab Deine vorgeschlagene Änderung im obigen Beitrag eingecheckt

Alles ist relativ...

[betateilchen]

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.

[chris1284]

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?

[betateilchen]

falscher Thread.

Bitte hier: https://forum.fhem.de/index.php/topic,54055.0.html