fhem configuration in sql-DB ablegen - besteht Interesse?

[betateilchen]

Irgendwie nervt mich das Rumgehampel mit den cfg-Dateien. Deshalb habe ich mich hingesetzt und die gesamte Konfiguration in eine sql-Datenbank (bei mir: sqlite) gepackt.

Dazu habe ich die fhem.pl durchforstet und an den entsprechenden Stellen angepaßt. Der Aufwand dafür ist überschaubar, Anpassungen werden benötigt

• beim fhem Start
• beim Setzen der globalen Attribute
• beim save
• beim rereadcfg

Derzeit starte ich mein fhem mit

Code Auswählen Erweitern

perl fhem.pl configDB

und das funktioniert auch prima ("configDB" ist als Schlüsselwort zu verstehen) und parallel zur bisherigen Funktionsweise (es kann immer noch mit fhem.cfg gestartet werden, dann bleibt die Datenbank komplett unberücksichtigt). Die Datenbankverbindung ist derzeit noch hartverdrahtet, die müsste man natürlich noch konfigurierbar machen.
Desweiteren muss das Editieren der Konfiguration im Frontend (Edit Files) noch angepaßt werden.

Grundsätzliche Frage: Besteht Interesse, diesen Ansatz weiterzuverfolgen und zu einer richtigen Lösung auszubauen?

Ich würde dann eine entsprechende pm-Datei erstellen, in der die notwendigen Funktionen außerhalb der fhem.pl liegen und die von fhem.pl benutzt wird, falls die Konfiguration per Datenbank angefordert wird.

Die notwendigen Anpassungen in der fhem.pl bestehen dann lediglich darin, an den entsprechenden Stellen anstatt der vorhandenen Abläufe die configDB Funktionen zu verwenden. Damit wäre die ganze Lösung abwärtskompatibel und niemand wird gezwungen, eine Datenbank zu verwenden.

Offen ist derzeit auch noch die Frage der Tabellenstrukturen, im Moment verwende ich einfach ein langes Feld und schreibe die bisherige Konfiguration zeilenweise in die Tabelle. Selbst das erlaubt mir schon eine sehr viel einfacher Handhabung der Konfiguration. Und JA, es gibt bereits zwei Tabellen, eine für die Konfiguration und eine für die States.

Das Schöne an sqlite ist, dass es auf nahezu allen Plattformen problemlos verfügbar ist.

Aus Performancegründen könnte man dann 93_DbLog irgendwann dahingehend anpassen, bei aktivierter configDB die gleiche Datenbank zu verwenden und die Logtabellen dort zu schreiben, anstatt zwei Datenbanken zu verwenden.

Das Ganze ist derzeit als proof-of-concept zu verstehen und stellt eine reine Diskussionsgrundlage dar.
Ich freue mich auf regen Ideenaustausch.

[rudolfkoenig]

Falls allgemeine Interesse besteht, dann werde ich Patches fuer fhem.pl/FHEMWEB uebernehmen.
Eine Loesung mit moeglichst wenig if oder unless in fhem.pl wuerde ich bevorzugen.

[betateilchen]

Eine Loesung mit moeglichst wenig if oder unless in fhem.pl wuerde ich bevorzugen.

Ich auch. Aber um künftig beide Konfigurationsvarianten zu ermöglichen, werden wir um eine geringe Anzahl Fallunterscheidungen (an den genannten Stellen) nicht rumkommen.

[svenson08]

Grundsätzliche Frage: Besteht Interesse, diesen Ansatz weiterzuverfolgen und zu einer richtigen Lösung auszubauen?

Vom meiner Seite besteht daran Interesse. Wenn das Ablegen der configs als default angesehen wird und irgendwann die cfgs Dateien komplett wegfallen. Hier fallen einem evlt. noch andere Ansätze ein (Log per Default in DB, Module in die DB und nicht ins Dateisystem, o.ä.).

Offen ist derzeit auch noch die Frage der Tabellenstrukturen

Sollte besprochen werden, aber in meinen Augen von den Main-Developer. Bei dem Thema würde ich mich durch mein FHEM Fehlwissen raushalten. Das von betateilchen vorgestellte Konstrukt wird sicherlich funktionieren, der Einsatz einer Datenbank sollte aber mehr als nur das schreiben der Configs in ein Datenbankfeld sein.

Wie sehen die Nachteile aus, das sollte auch abgesprochen werden. Auf die ein oder andere minimal Konfiguration sollte dazu geschaut werden.

Bleibt die Frage ob man diese "Baustelle" aufmacht. Je nach dem ist das eine gewaltige Aktion.

P.S.: An vielen Stellen wird immer wieder auf wichtigere Baustellen verwiesen, aber ich kann nur raten welche das sein sollten. Es wäre zu überlegen ob man diese "Baustellen" benennt und mal eine Übersicht erstellt.

Gruß svenson

[betateilchen]

und irgendwann die cfgs Dateien komplett wegfallen.

Meine fhem.cfg ist inzwischen komplett leer.

der Einsatz einer Datenbank sollte aber mehr als nur das schreiben der Configs in ein Datenbankfeld sein.

Logisch. Mir ging es in meinem ersten Schritt nur darum, herauszufinden, wie groß der Aufwand für die Einbindung überhaupt ist. Die Strukturen der Tabellen betrachte ich schon als "Feinarbeit".

die config-Tabelle könnte beispielsweise aus vier Feldern bestehen:

Code Auswählen Erweitern


CMD    DEVICE PARAMETER VALUE
define grmpf  abcmodul  DEF-string
attr   grmpf  verbose   3


[rudolfkoenig]

werden wir um eine geringe Anzahl Fallunterscheidungen (an den genannten Stellen) nicht rumkommen.

Es sei denn, man modularisiert diese auch. Bin aber z.Zt. eher fuer die if's

irgendwann die cfgs Dateien komplett wegfallen.

Das sehe ich noch nicht, weil damit eine sqlite/etc Bibliothek Voraussetzung fuer die Installation waere.

[betateilchen]

Es sei denn, man modularisiert diese auch.

dazu müsstes Du aber die fhem.pl tiefgreifend umbauen

Das sehe ich noch nicht

Das sehe ich auch noch in weiter Ferne, wobei ich die Abhängigkeit von einer db-Library nicht unbedingt als das größte Hindernis ansehe.

[betateilchen]

Ich bin jetzt bei insgesamt fünf if-Abfragen in der fhem.pl und (funktional) fertig mit der Implementierung, basierend auf dieser fhem.pl:

Code Auswählen Erweitern

# $Id: fhem.pl 4891 2014-02-12 09:10:01Z rudolfkoenig $

Es funktioniert grundsätzlich alles wie geplant, aber ein paar Feinarbeiten sind noch zu erledigen. Wer hat Lust zum Testen? Ich würde dann im Testbereich des Forums einen entsprechenden Thread eröffnen, um Files und Anleitung bereitzustellen und technische Fragen zu beantworten.

Noch einige grundsätzliche Anmerkungen:

• Die Umsetzung ist für den Anwender absolut transparent, d.h. an den Befehlen ändert sich nichts. "save" und "rereadcfg" funktionieren exakt wie vorher.
• Die Änderung für den Anwender besteht lediglich im Starten von fhem: Anstatt "perl fhem.pl fhem.cfg" wird mit "perl fhem.pl configDB" gestartet.
• Die Migration einer bestehenden Konfiguration ist ebenfalls implementiert.

@Rudi:

Könntest Du mal bitte über den Patch schauen, ob ich etwas grundlegendes falschgemacht habe?

[Tobias]

Hi betateilchen,
ich finde die Idee echt super... !!!
ich bin aber auch dafür als Voraussetzung der ConfigDB das Modul DbLog zu machen. Damit kann man alles in diesem Modul kapseln was irgendwie nach Datenbank riecht.
Nicht alle wollen sqlite. Und DbLog ist nunmal DAS fhem-Datenbankmodul

[betateilchen]

Code Auswählen Erweitern

Und DbLog ist nunmal DAS fhem-Datenbankmodul

Nein, ist es nicht. Es ist einfach "nur" ein Modul, das für einen bestimmten Zweck mit einer Datenbank arbeitet.
Das Problem bei 93_DbLog ist zudem, dass dieses Modul viel zu spät ins Spiel kommt, um für die Konfiguration von fhem in Betracht zu kommen.

Ich würde 93_DbLog niemals als Abhängigkeit ansehen - das wäre völlig kontraproduktiv. Es gibt auch noch ein paar ganz andere, technische, Gründe, die dagegensprechen. Für die Konfiguration brauche ich zum Beispiel weder eine gecachte, noch eine permanent bestehende Datenbankverbindung.

Und meine Konfigurationsdatenbank ist - genau wie das DbLog - nicht auf sqlite begrenzt. Es kann die gleichen Datenbanktypen verwenden wie DbLog auch.

Hier kannst Du nachlesen und testen: http://forum.fhem.de/index.php/topic,20194.0.html

[betateilchen]

für FHEMWEb ist nur eine einzige Änderung vorgesehen, das Abschalten der Edit-Möglichkeit für fhem.cfg.

Code Auswählen Erweitern



Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 4920)
+++ 01_FHEMWEB.pm (working copy)
@@ -1507,7 +1507,7 @@

     $attr{global}{configfile} =~ m,([^/]*)$,;
     my $cfgFileName = $1;
-    FW_displayFileList("config file", $cfgFileName);
+    FW_displayFileList("config file", $cfgFileName) unless $attr{global}{configfile} eq 'configDB';
     FW_displayFileList("Own modules and helper files",
         FW_fileList("$MW_dir/^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday".
                                   "|.*layout)\$"));



[betateilchen]

Wieso überschreibt eigentlich eine per update erhaltene Datei "fhem.pl" gleichzeitig auch eine vorhandene Date "fhem.dev.pl" im gleichen Verzeichnis?

[betateilchen]

Hallo Rudi,

hast Du schon darüber nachgedacht, die von mir vorgeschlagene "Schnittstelle" in Deine fhem.pl einzubauen? Ich würde gerne die Weiterentwicklung der fhem.pl mit nutzen, ohne jedesmal meine Fallunterscheidungen lokal nachziehen zu müssen.

Mein Vorschlag: Die perl-Erweiterungen in configDB.pm würde ich vorläufig in ./contrib einchecken, falls jemand testen möchte.
Für alle User, die weiter mit der fhem.cfg (oder einer anderen Konfigdatei) arbeiten, sollten sich keinerlei Auswirkungen ergeben.

Die Konfiguration per Datenbank läuft bei mir seit Donnerstag störungsfrei durch

Es sei denn, man modularisiert diese auch. Bin aber z.Zt. eher fuer die if's

Das mit dem modularisieren habe ich mir im Rahmen der Entwicklung auch überlegt. Ansatzweise ist das ja schon in der fhem.pl vorhanden, z.B. in der sub WriteStatefile()

Wenn man mal überlegt, was eigentlich für die Konfiguration überhaupt gebraucht wird, kommt ja an sich nicht viel raus:

• globalDef
• globalAttrBeforeFork (oder so ähnlich)
• cfg lesen
• states lesen
• cfg schreiben
• states schreiben

globalDef ist in beiden Fällen identisch.

Die anderen fünf Funktionen habe ich für die Konfiguration per Datenbank nachprogrammiert und somit schon komplett gekapselt. Aufgrund der derzeitigen Struktur der fhem.pl kam ich nicht umhin, einige dieser Funktionen in Deine subs() zu intergrieren, z.B. in der WriteStatefile und bei den globalen Attributen.

Speziell bei WriteStatefile war das notwendig, weil die an verschiedenen Stellen in der fhem.cfg aufgerufen wird.

Wenn man diese fünf Funktionen auch für die Verwendung mit einer Konfigurationsdatei kapseln würde, wäre man schon ein ganzes Stück weiter - und m.E. auch übersichtlicher.

Viele Grüße
Udo

[rudolfkoenig]

hast Du schon darüber nachgedacht

Sicher, ich wollte nur abwarten, dass deine Baustelle sich beruhigt. Ich kann auch die erwaehnten Funktionen irgendwie Kapseln, dauert aber vermutlich noch ein paar Tage.

Woran merkst du, dass die Config-Daten aus der DB zu holen sind?
Und hat ausser dir sonst jemand diese Erweiterung schon getestet?

[betateilchen]

Hallo Rudi,

Woran merkst du, dass die Config-Daten aus der DB zu holen sind?

Das hatte ich schon irgendwo beschrieben:  fhem wird nicht mit "perl fhem.pl fhem.cfg" gestartet, sondern mit "perl fhem.pl configDB"

configDB ist quasi das festgelegte Schlüsselwort für die Unterscheidung.

Dieses Schlüsselwort wird beim fhem-Start

Code Auswählen Erweitern


###################################################
# Server initialization
doGlobalDef($ARGV[0]);


von der unangetasteten doGlobalDef als Attributwert in das Attribut "configfile" übernommen, und anhand dieses Attributs arbeiten alle Fallunterscheidungen.

Das mit dem Kapseln Deiner Funktionen ist für mich nicht oberste Priorität, das können wir gerne irgendwann gemeinsam angehen, um uns dabei nicht gegenseitig abzuschießen.

Ob es andere Tester gibt? Ja. Zumindest wurde das Variante aus dem Test-Thread schon mehrmals runtergeladen (die letzte Version zwei Mal) und einer der User hat sich auch per email bei mir gemeldet. Allerdings weiß ich von dem User nur seine email-Adresse und nicht seinen Usernamen (die emails aus dem Forum hier enthalten immer noch keinen Hinweis auf den Absender, siehe auch hier: http://forum.fhem.de/index.php/topic,19327.0.html ) somit kann ich Dir nicht sagen, WEM man den "Tester"-Status zuweisen müsste.

[Wzut]

Variante aus dem Test-Thread schon mehrmals runtergeladen (die letzte Version zwei Mal)

Also wenns recht ist wären es heute Abend dann drei Downloads, da ich an dem Thema grossses Interessse habe.
Ich möchte allerdings nicht sql-lite benutzen sondern wie bisher bei allen meinen Projekten mysql.

[betateilchen]

Welchen Datenbanktyp Du verwendest, ist meiner Erweiterung eigentlich egal, Postgresql, Sqlite, MySQL - solange Du das entsprechende perl-DBD Modul auf Deinem System hast und die Konfig-Datei für die DB-Connection stimmt, sollte es funktionieren.

für MySQL muss der Verbindungseintrag so aussehen:

Code Auswählen Erweitern


%dbconfig= (
connection => "mysql:database=<datenbankName>;host=<hostAdresse>db;port=3306",
user => "datenbankUser",
password => "datenbanUserkPasswort",
);


[Wzut]

ging alles nach deiner Anleitung im Testforum problemlos , alle .cfg Zeilen wurden in die Tabelle übernommen und nach einem save verdoppelt :

Code Auswählen Erweitern


Datensätze COMMAND
             1 #
             2 #created
         342 attr
         183 define


[betateilchen]

Ist doch perfekt

Mach mal ein {cfgDB_Info} dann siehst Du noch ein bißchen mehr.

Code Auswählen Erweitern


--------------------------------------------------------------------------------
configDB Database Information
--------------------------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
--------------------------------------------------------------------------------
fhemconfig: 11908 entries

Ver 0 saved: Tue Feb 18 22:05:52 2014 def: 286 attr: 1202
Ver 1 saved: Tue Feb 18 21:41:09 2014 def: 286 attr: 1202
Ver 2 saved: Tue Feb 18 21:40:01 2014 def: 286 attr: 1202
Ver 3 saved: Tue Feb 18 20:16:41 2014 def: 286 attr: 1202
Ver 4 saved: Tue Feb 18 20:15:13 2014 def: 286 attr: 1201
Ver 5 saved: Tue Feb 18 20:08:09 2014 def: 286 attr: 1201
Ver 6 saved: Tue Feb 18 18:39:49 2014 def: 286 attr: 1201
Ver 7 saved: Tue Feb 18 07:52:07 2014 def: 286 attr: 1201
--------------------------------------------------------------------------------
fhemstate: 1520 entries saved: Tue Feb 18 22:05:52 2014
--------------------------------------------------------------------------------


[betateilchen]

Sicher, ich wollte nur abwarten, dass deine Baustelle sich beruhigt.
...
Und hat ausser dir sonst jemand diese Erweiterung schon getestet?

Meine Baustelle hat sich beruhigt und die Konfiguration aus der Datenbank läuft hier ohne jeder Änderung/Korrektur seit zwei Wochen störungsfrei auf insgesamt drei fhem Installationen (zwei mit SQLITE, eine mit MySQL) auf unterschiedlichen Plattformen (Mac OSX, RaspberryPi und Beaglebone Black)

Und von Testern wurden mir bisher auch keinerlei Probleme gemeldet.

[rudolfkoenig]

Kannst du mir bitte zusammenfassen, welche Aenderungen ich wo einbauen soll? Ich will nichts uebersehen.

[betateilchen]

ja, mach ich gerne. Ich werde eine Patchdatei bauen, dann kannst Du Dir das nochmal anschauen.

[betateilchen]

Hier die diff für die fhem.pl. Das Prinzip ist eigentlich immer das gleiche: Feststellen, ob configDB gesetzt ist, wenn ja, die zugehörige Funktion ausführen, wenn nein, das originale Coding verwenden.

Code Auswählen Erweitern



Index: fhem.pl
===================================================================
--- fhem.pl (revision 4891)
+++ fhem.pl (working copy)
@@ -37,6 +37,21 @@


##################################################
+# We need the forward declarations in case of
+# configDB.pm can not be loaded.
+
+sub cfgDB_Init;
+sub cfgDB_ReadAll($);
+sub cfgDB_SaveState;
+sub cfgDB_SaveCfg;
+sub cfgDB_GlobalAttr;
+eval "use configDB";
+
+#
+##################################################
+
+
+##################################################
# Forward declarations
#
sub AddDuplicate($$);
@@ -365,6 +380,8 @@
# Server initialization
doGlobalDef($ARGV[0]);

+cfgDB_Init if $attr{global}{configfile} eq 'configDB';
+
# As newer Linux versions reset serial parameters after fork, we parse the
# config file after the fork. But we need some global attr parameters before, so we
# read them here.
@@ -389,14 +406,17 @@
   sleep(5);
}

-my $ret = CommandInclude(undef, $attr{global}{configfile});
-Log 1, "configfile: $ret" if($ret);
+if($attr{global}{configfile} eq 'configDB') {
+ cfgDB_ReadAll(undef);
+} else {
+ my $ret = CommandInclude(undef, $attr{global}{configfile});
+ Log 1, "configfile: $ret" if($ret);

-if($attr{global}{statefile} && -r $attr{global}{statefile}) {
-  $ret = CommandInclude(undef, $attr{global}{statefile});
-  Log 1, "statefile: $ret" if($ret);
+ if($attr{global}{statefile} && -r $attr{global}{statefile}) {
+ $ret = CommandInclude(undef, $attr{global}{statefile});
+ Log 1, "statefile: $ret" if($ret);
+ }
}
-
SignalHandling();

my $pfn = $attr{global}{pidfilename};
@@ -1068,7 +1088,7 @@
   my ($cl, $param) = @_;
   my $name = ($cl ? $cl->{NAME} : "__anonymous__");
   my $cfgfile = ($param ? $param : $attr{global}{configfile});
-  return "Cannot open $cfgfile: $!" if(! -f $cfgfile);
+  return "Cannot open $cfgfile: $!" if(! -f $cfgfile && $attr{global}{configfile} ne 'configDB');

   $attr{global}{configfile} = $cfgfile;
   WriteStatefile();
@@ -1090,20 +1110,27 @@
   %readyfnlist = ();
   %inform = ();

-  doGlobalDef($cfgfile);
-  setGlobalAttrBeforeFork($cfgfile);
+ doGlobalDef($cfgfile);
+ my $ret;
+
+ if($attr{global}{configfile} eq 'configDB') {
+ cfgDB_ReadAll($cl);
+ } else {
+ setGlobalAttrBeforeFork($cfgfile);

-  my $ret = CommandInclude($cl, $cfgfile);
-  if($attr{global}{statefile} && -r $attr{global}{statefile}) {
-    my $ret2 = CommandInclude($cl, $attr{global}{statefile});
-    $ret = (defined($ret) ? "$ret\n$ret2" : $ret2) if(defined($ret2));
-  }
-  DoTrigger("global", "REREADCFG", 1);
-  $defs{$name} = $selectlist{$name} = $cl if($name && $name ne "__anonymous__");
+ $ret = CommandInclude($cl, $cfgfile);
+ if($attr{global}{statefile} && -r $attr{global}{statefile}) {
+ my $ret2 = CommandInclude($cl, $attr{global}{statefile});
+ $ret = (defined($ret) ? "$ret\n$ret2" : $ret2) if(defined($ret2));
+ }
+ }

-  $init_done = 1;
-  $reread_active=0;
-  return $ret;
+ DoTrigger("global", "REREADCFG", 1);
+ $defs{$name} = $selectlist{$name} = $cl if($name && $name ne "__anonymous__");
+
+ $init_done = 1;
+ $reread_active=0;
+ return $ret;
}

#####################################
@@ -1125,6 +1152,9 @@
sub
WriteStatefile()
{
+ if($attr{global}{configfile} eq 'configDB') {
+ cfgDB_SaveState;
+ } else {
   return "No statefile specified" if(!$attr{global}{statefile});
   if(!open(SFH, ">$attr{global}{statefile}")) {
     my $msg = "WriteStateFile: Cannot open $attr{global}{statefile}: $!";
@@ -1175,6 +1205,7 @@
   }

   close(SFH);
+ }
   return "";
}

@@ -1190,6 +1221,11 @@
   WriteStatefile();

   $param = $attr{global}{configfile} if(!$param);
+
+ if($attr{global}{configfile} eq 'configDB') {
+ $ret = cfgDB_SaveCfg;
+ } else {
+
   return "No configfile attribute set and no argument specified" if(!$param);
   if(!open(SFH, ">$param")) {
     return "Cannot open $param: $!";
@@ -1257,6 +1293,7 @@
   foreach my $fh (values %fh) {
     close($fh) if($fh ne "1");
   }
+ } # if !configDB
   return ($ret ? $ret : "Wrote configuration to $param");
}

@@ -1591,7 +1628,7 @@
       delete($defs{$sdev}{'.userReadings'});
     }

-    $ret = CallFn($sdev, "AttrFn", "del", @a);
+    my $ret = CallFn($sdev, "AttrFn", "del", @a);
     if($ret) {
       push @rets, $ret;
       next;
@@ -3036,17 +3073,21 @@
sub
setGlobalAttrBeforeFork($)
{
-  my ($f) = @_;
-  open(FH, $f) || die("Cant open $f: $!\n");
-  while(my $l = <FH>) {
-    $l =~ s/[\r\n]//g;
-    next if($l !~ m/^attr\s+global\s+([^\s]+)\s+(.*)$/);
-    my ($n,$v) = ($1,$2);
-    $v =~ s/#.*//;
-    $v =~ s/ .*$//;
-    $attr{global}{$n} = $v;
-  }
-  close(FH);
+ my ($f) = @_;
+ if($f eq 'configDB') {
+ cfgDB_GlobalAttr;
+ } else {
+ open(FH, $f) || die("Cant open $f: $!\n");
+ while(my $l = <FH>) {
+ $l =~ s/[\r\n]//g;
+ next if($l !~ m/^attr\s+global\s+([^\s]+)\s+(.*)$/);
+ my ($n,$v) = ($1,$2);
+ $v =~ s/#.*//;
+ $v =~ s/ .*$//;
+ $attr{global}{$n} = $v;
+ }
+ close(FH);
+ }
}




Hier noch die einzige Änderung in der 01_FHEMWEB, da wird lediglich in "Edit files" die fhem.cfg komplett ausgeblendet.

Code Auswählen Erweitern



Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 4920)
+++ 01_FHEMWEB.pm (working copy)
@@ -1507,7 +1507,7 @@

     $attr{global}{configfile} =~ m,([^/]*)$,;
     my $cfgFileName = $1;
-    FW_displayFileList("config file", $cfgFileName);
+    FW_displayFileList("config file", $cfgFileName) unless $attr{global}{configfile} eq 'configDB';
     FW_displayFileList("Own modules and helper files",
         FW_fileList("$MW_dir/^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday".
                                   "|.*layout)\$"));



Sämtliche Konfigurationsfunktionen sind in die Datei configDB.pm ausgelagert, was den Vorteil hat, dass für Änderungen an diesen Funktionen die fhem.pl nicht angefasst werden muss.

Diese Erweiterungsdatei muss derzeit im gleichen Verzeichnis liegen wie fhem.pl, da es zum Startzeitpunkt noch keinen modpath gibt und der Pfad ./FHEM im Gegensatz zum aktuellen Pfad nicht in @INC enthalten ist.

Unabhängig davon habe ich die Funktionsfähigkeit von fhem in Kombination mit der bisherigen fhem.cfg auch komplett ohne diese Datei getestet und keine Probleme festgestellt.

Wenn ich die Doku als pod in die configDB.pm schreibe, wird die dann von commandref_join berücksichtigt?

Viele Grüße
Udo

[rudolfkoenig]

Habs etwas umformatiert und eingecheckt. Bemerkungen:
- das eval habe ich verschoben, damit es nur dann ausgefuehrt wird, falls noetig ist. Bitte testen.
- cfgDB_ReadAll() usw. sollten die gesammelten Fehlermeldungen zurueckliefern. Danach muessen wir fhem.pl wieder anpassen.
- doku kommt zwar nicht automatisch ins commandref, ich kann aber commandref_join.pl entsprechend erweitern
- ich gehe davon aus, dass die doku auch bootstrapping enthaelt.
- configDB.pm bitte in MAINTAINER.txt eintragen und auch einchecken.

[betateilchen]

Habs etwas umformatiert und eingecheckt.

danke!

- das eval habe ich verschoben, damit es nur dann ausgefuehrt wird, falls noetig ist. Bitte testen.

ich werde testen und berichten.

- cfgDB_ReadAll() usw. sollten die gesammelten Fehlermeldungen zurueckliefern. Danach muessen wir fhem.pl wieder anpassen.

schau ich mir an.

- doku kommt zwar nicht automatisch ins commandref, ich kann aber commandref_join.pl entsprechend erweitern

Wenn Du einen anderen Weg, die Doku bereitzustellen hast, können wir das gerne auch anders machen.

- ich gehe davon aus, dass die doku auch bootstrapping enthaelt.

was meinst Du damit genau?

- configDB.pm bitte in MAINTAINER.txt eintragen und auch einchecken.

sowieso

[rudolfkoenig]

Wenn Du einen anderen Weg, die Doku bereitzustellen hast, können wir das gerne auch anders machen.

Ich habe keine besseren Alternativen, deswegen bleibt es erstmal so.

Mit bootstrapping meine ich die Erstinstallation, was jemand machen muss, um nach "configDB" umzuziehen.

[betateilchen]

Mit bootstrapping meine ich die Erstinstallation, was jemand machen muss, um nach "configDB" umzuziehen.

Ok, da werde ich die Installationsanleitung aus dem "Tester"-Thread übernehmen, die hat sich bewährt.

Die Tests der letzten halben Stunde haben ergeben, dass die eingebauten Änderungen alle funktionieren. Die noch offenen Punkte sind in Arbeit.

[betateilchen]

• configDB.pm eingecheckt, Doku (englisch) enthalten
• MAINTAINER.txt ergänzt
• CHANGED ergänzt
• commandref_frame angepasst, um die Doku in den helper modules zu verankern

Vielleicht kann mal jemand die Doku in der commandref querlesen, ob das einigermaßen verständlich beschrieben ist.

[rudolfkoenig]

Ja, es ist einigermassen verstaendlich
Habe commandref_join.pl modifiziert, und die Doku online gestellt.

[betateilchen]

Danke.

Man könnte für SQLITE die gesamte Installation sogar noch soweit vereinfachen, dass der Anwender, abgesehen von der Installation der Datenbanksoftware nebst passendem DBI überhaupt keinen Aufwand mehr hat, indem man eine leere Datenbankdatei und eine passende Verbindungsdatei mit ausliefert. Dadurch entfielen die beiden größten Fehlerquellen bei der Installation. Ich denke, ich werde diese Dateien in ./contrib bereitstellen.

Gibt es eigentlich Plattformen, für die sqlite nicht zur Verfügung steht?

[rudolfkoenig]

Ja, FRITZ!Box.

[betateilchen]

äh... abgesehen davon, dass das für mich bekanntermaßen keine ernstzunehmende Hardware abseits von Telefonie und Netzwerk (und nichtmal das netzwerken kann sie vernünftig) ist, stellt sich mir folgende Frage:

Bist Du Dir sicher, dass da sqlite nicht schon ab Werk in der Firmware enthalten ist?

[rudolfkoenig]

Doof, wenn man was zugeben muss:
# cd /
# find . -print | grep -i sql
./lib/libsqlite3-3.7.14.1.so.0
./lib/libsqlite3-3.7.14.1.so.0.8.6
./lib/libsqlite3.so

[betateilchen]

*g*

Ich bin übrigens eher durch einen logischen Denkansatz draufgekommen, als ich mir überlegt hatte, dass für die Anruflisten, Mediaserver und FritzNAS irgendeine Datenbank auf der Kiste vorhanden sein muss. Und da drängelt sich sqlite einfach auf.

[betateilchen]

Hallo Rudi!

- das eval habe ich verschoben, damit es nur dann ausgefuehrt wird, falls noetig ist. Bitte testen.

Das funktioniert so nicht. Für die Migration einer bestehenden Konfiguration wird die Library gebraucht, obwohl fhem in diesem Fall noch nicht mit der Datenbank-Option gestartet wurde. Jetzt weiß ich auch wieder, warum ich das eval damals mit zu den Forward-Deklarationen gepackt hatte...

Ausserdem ist mir noch aufgefallen:

• die $id wird in "version" nicht angezeigt (dafür gibts nen patch, siehe unten)
• configDB.pm wird von "update" nicht nicht berücksichtigt
• das Verzeichnis contrib/configDB wird von update nicht berücksichtigt

Viele Grüße
Udo

Code Auswählen Erweitern



Index: fhem.pl
===================================================================
--- fhem.pl (revision 5106)
+++ fhem.pl (working copy)
@@ -129,6 +129,8 @@
sub cfgDB_SaveState;
sub cfgDB_SaveCfg;
sub cfgDB_GlobalAttr;
+sub cfgDB_svnId;
+eval "use configDB";

##################################################
# Variables:
@@ -373,8 +375,8 @@
doGlobalDef($ARGV[0]);

if($attr{global}{configfile} eq 'configDB') {
-  eval "use configDB";
-  Log 1, $@ if($@);
+#  eval "use configDB";
+#  Log 1, $@ if($@);
   cfgDB_Init();
}

@@ -2327,6 +2329,7 @@
   my ($cl, $param) = @_;

   my @ret = ("# $cvsid");
+  push @ret, cfgDB_svnId if $attr{global}{configfile} eq 'configDB';
   foreach my $m (sort keys %modules) {
     next if(!$modules{$m}{LOADED} || $modules{$m}{ORDER} < 0);
     my $fn = "$attr{global}{modpath}/FHEM/".$modules{$m}{ORDER}."_$m.pm";



dann klappts auch mit der Versionsanzeige:

(http://up.picr.de/17535949nn.png)

[rudolfkoenig]

Für die Migration einer bestehenden Konfiguration wird die Library gebraucht,

Ist immer noch kein Grund es bei 99% der FHEM Benutzer auszufuehren, und damit auch das DBI Modul zu laden. Nur die Anweisung fuer die Migration muss geaendert werden:

Code Auswählen Erweitern

{use configDB;; cfgDB_Migrate()}

Die zwei cfgDB_svnId Zeilen habe ich hinzugefuegt.

[betateilchen]

Nur die Anweisung fuer die Migration muss geaendert werden:

Auch eine Variante, danke. Werde ich so in die Doku übernehmen.

[betateilchen]

- cfgDB_ReadAll() usw. sollten die gesammelten Fehlermeldungen zurueckliefern. Danach muessen wir fhem.pl wieder anpassen.

In #5111 eingebaut, cfgDB_ReadAll() liefert jetzt die gesammelten $ret von AnalyzeCommandChain() zurück.

[rudolfkoenig]

Habe fhem.pl angepasst und eingecheckt.

[betateilchen]

danke!

hast Du update auch schon angepasst?

[betateilchen]

klopf klopf klopf...

Gibt es irgendwelche Gründe oder von mir unerfüllte Aufgaben, die das Einbinden der configDB.pm in den regulären Update-Prozeß verhindern?

[rudolfkoenig]

Nur meine Vergesslichkeit. Habe configDB.pm zu fhemupdate.pl hinzugefuegt, und fhemupdate.pl ausgefuehrt. Ab sofort wird configDB.pm per upload geliefert.

[betateilchen]

Danke.

edit: wenn irgendwann noch das template-Verzeichnis ./contrib/configDB ... *ganz-fest-wünsch*

[betateilchen]

Hallo Rudi,

ich brauche bitte Deine Hilfe, da Du das 98_backup.pm besser kennst als ich.

Da passieren momentan komische Dinge, wenn jemand configDB nutzt und beim update ein backup gemacht werden soll.
Da wird dann versucht, 1.) ein configfile namens "configDB" in das tar zu schicken und 2.) das configfile zu parsen.

Kannst Du Dir das bei Gelegenheit mal anschauen? Mir war das noch nicht aufgefallen, da es bei mir vor einem update kein Backup gibt.
Aber die Anwender sind da drüber gestolpert.

http://forum.fhem.de/index.php/topic,21183.0.html


Viele Grüße
Udo

[rudolfkoenig]

edit: wenn irgendwann noch das template-Verzeichnis ./contrib/configDB ... *ganz-fest-wünsch*

Erstens weiss nicht genau was du wuenscht, aber contrib wird nicht per update ausgeliefert, und das bleibt so.
Zweitens bitte beachten bei edits: diese werden per email nicht ausgeliefert, und ich reagiere nur zufaellig darauf, diesmal wg. dem neuen Beitrag.

... komische Dinge, wenn jemand configDB nutzt und beim update ein backup gemacht werden soll.

Ich habe update modifiziert, so dass ohne gesetztes backup_before_update und configDB kein backup gemacht wird.

backup liefert ab sofort bei configDB eine Fehlermeldung zurueck, da ich auf die schnelle kein generisches Datenbank-Backup programmieren wollte, und ohne die FHEM Konfiguration ein Backup mAn sinnlos ist.

[betateilchen]

aber contrib wird nicht per update ausgeliefert, und das bleibt so.

ok, das war mir nicht bewusst.

Zweitens bitte beachten bei edits: diese werden per email nicht ausgeliefert,

Das weiss ich sehr wohl. Wer sich auf die email-Benachrichtigung einer Forumsoftware (egal welcher) verlässt, darf nie davon ausgehen, alles mitzukriegen. Dafür kann aber die Software nix, und daraus kann man auch einem User keinen Vorwurf machen. Das ist ein typisches Problem von Anwendern, die irgendwann von Newsgroup zu Forumsoftware umsteigen mussten und gedanklich an ihren alten Zöpfen festhalten. Aber irgendwann lernt das erfahrungsgemäß auch der letzte Umsteiger. Die email-Benachrichtigung ist für mich wie ein goldenes Fußkettchen: hübsch, aber nutzlos. Deshalb nutze ich die seit Ewigkeiten in keinem Forum mehr.

da ich auf die schnelle kein generisches Datenbank-Backup programmieren wollte,

Niemand hat von Dir verlangt, dass Du ein Datenbank-Backup programmieren sollst.

Ich habe update modifiziert, so dass ohne gesetztes backup_before_update und configDB kein backup gemacht wird.
...
backup liefert ab sofort bei configDB eine Fehlermeldung zurueck,  und ohne die FHEM Konfiguration ein Backup mAn sinnlos ist.

Dass nun aber gar kein Backup mehr gemacht wird, halte ich aber auch nicht für die richtige Lösung.
Hätten wir nicht besser erstmal über eine sinnvolle Lösung reden können, bevor irgendwelche Schnellschüsse passieren?

Mein Lösungsansatz wäre folgender:

• fhem.cfg und das statefile werden nicht mehr gesichert, das parsing der fhem.cfg entfällt
• stattdessen wird die Konfigurationsdatei configDB.conf mitgesichert
• falls als Datenbank sqlite verwendet wird, kann die Datenbankdatei (da es nur ein einziges File ist) natürlich mitgesichert werden. Die Information dazu (Ort und Name der Datei sowie das Datenbankmodell) kann ich Dir aus configDB.pm liefern.
• alles andere wird genau so gesichert wie bisher auch

Hintergrund:

Das Backup einer fhem Installation macht auch völlig ohne die zugehörige Konfiguration durchaus Sinn, z.B. wenn man nach einem Update feststellt, dass sich einige Module nicht mehr so verhält wie man es möchte. Und wenn Du im Forum nachliest, wirst Du sehr schnell feststellen, dass von sehr vielen Usern DIESE Variante der Backupnutzung viel häufiger genutzt wird als zur Wiederherstellung einer Konfigurationsdatei. Es ist deshalb völlig egal, ob die Konfiguration per fhem.cfg oder configDB erfolgt, wichtig ist, dass die "alten" Modulversionen gesichert werden.

Bei der Entwicklung von configDB habe ich darauf geachtet, dass für den Benutzer so wenig wie möglich Änderungen passieren und dass fhem sich weiterhin genau so verhält, wie er es bisher gewohnt war. Ich denke, diesen Grundsatz sollten wir auch beim Thema Backup einhalten, was ich jetzt aber nicht als gegeben ansehe.

Ich hatte Dich um Hilfe gebeten, weil ich gestern aus dem backup-Modul nicht so richtig schlau wurde, wie Du Dir den Backupprozess genau vorgestellt hattest und im Modul auch zu wenig Doku dazu enthalten ist. Ansonsten hätte ich nämlich schon einen Lösungsvorschlag inkl. patch vorschlagen können.

[justme1968]

damit das sichern der sqlite db über das db file zuverlässig funktioniert sollten zu dem zeitpunkt keine db connections offen sein. falls es ein wal file gibt muss das mit gesichert werden.

wenn das backup beim update auch im hintergrund passiert muss natürlich auch die connection  das vordergrund prozesses geschlossen sein.

gruss
  andre

[betateilchen]

Alles richtig, aber es ist viel einfacher. Die Konfigurationsdatenbank ist nur dann geöffnet (= bestehende Verbindung) wenn sie auch benutzt/gebraucht wird, und das ist beim/während des backup nicht der Fall.

[betateilchen]

Das ist eigentich alles, was ich erwartet hatte:

Code Auswählen Erweitern



Index: 98_backup.pm
===================================================================
--- 98_backup.pm (revision 5166)
+++ 98_backup.pm (working copy)
@@ -78,12 +78,24 @@
     }
   }

-  # get pathnames to archiv
-  push @pathname, $configfile;
-  Log 4, "backup include: '$configfile'";
-  $ret = parseConfig($configfile);
-  push @pathname, $statefile;
-  Log 4, "backup include: '$statefile'";
+  if($attr{global}{configfile} eq 'configDB') {
+    # add configDB configuration file
+    push @pathname, 'configDB.conf';
+    Log 4, "backup include: 'configDB.conf'";
+    my ($dbtype,$dbpath) = _cfgDB_backupdata;
+    Log 4, "backup data from configDB: $dbtype - $dbpath";
+    if($dbtype eq 'SQLITE') {
+      push @pathname, $dbpath;
+      Log 4, "backup include: '$dbpath'";
+    }
+  } else {
+    # get pathnames to archiv
+    push @pathname, $configfile;
+    Log 4, "backup include: '$configfile'";
+    $ret = parseConfig($configfile);
+    push @pathname, $statefile;
+    Log 4, "backup include: '$statefile'";
+  }
   $ret = readModpath($modpath,$backupdir);

   # create archiv



ergibt:

Code Auswählen Erweitern



2014-03-09 12:44:45 Global global Backup with command:
tar -cf - configDB.conf /Users/udo/SVN/fhem.55/fhem/configDB.db ./CHANGED ./configDB.conf ./configDB.db ./configDB.pm
./contrib ./COPYING ./demolog ./docs ./FHEM ./fhem.cfg ./fhem.cfg.demo ./fhem.db ./fhem.db.template ./fhem.pl ./HISTORY
./log ./MAINTAINER.txt ./Makefile ./README.SVN ./README_DEMO.txt ./webfrontend ./www
|gzip > ./backup/FHEM-20140309_124445.tar.gz



[rudolfkoenig]

@betateilchen: ich hatte deine Argumente auch alle im Kopf, aber die sind mit so viel wenn und aber verknuepft, dass kein "einfacher" Anwender es verstehen wird oder will. Die, die es verstehen, sind auch in der Lage selbst ein Backup zu erstellen, ist ja keine Hexerei.

Es ist mir auch bewusst, dass man jede Datenbank irgendwie sichern kann (hab selber etliche DB-Backups in perl gebaut), aber ich finde es nicht richtig, dass FHEM per default bei einigen Datenbanktypen was sichert, bei anderen nicht. Es ist eine der "ja, aber"s, was
normale Anwender nicht lesen oder merken.
Statt die DB zu sichern schlage ich vor, dass ihr eine eine Methode fuers Erstellen einer fhem.cfg baut, dieser kann im Backup aufgerufen und damit gesichert werden. Beim Restaurieren verwendet man migrate. Hat den Vorteil, dass es DB-Unabhaengig funktioniert.

Ich hatte Dich um Hilfe gebeten, weil ich gestern aus dem backup-Modul nicht so richtig schlau wurde,

Und ich habe reagiert, weil ich z.Zt den Martin (den Autor) vertrete. Du kannst natuerlich bessere Loesungen vorschlagen, aber ich hielt es wichtig zu reagieren, damit Benutzer keine falschen Hoffnungen machen.

[betateilchen]

@betateilchen: ich hatte deine Argumente auch alle im Kopf, aber die sind mit so viel wenn und aber verknuepft, dass kein "einfacher" Anwender es verstehen wird oder will. Die, die es verstehen, sind auch in der Lage selbst ein Backup zu erstellen, ist ja keine Hexerei.

Da sind keine wenn und aber. Du hast mal wieder einen Weg völlig am Anwender vorbei umgesetzt, obwohl es mit einfachen Mitteln anders (besser) zu lösen gewesen wäre. Einen funktionierenden Vorschlag habe ich oben bereits angefügt.

Statt die DB zu sichern schlage ich vor, dass ihr eine eine Methode fuers Erstellen einer fhem.cfg baut

Nö. Ich betreibe den ganzen Aufwand die fhem.cfg in die Tonne zu treten sicherlich nicht, um mit meinem eigenen Tool dann diesen Schrott wieder zu generieren.
Für SQLITE steht eine einfache Funktion bereits in meinem obigen Vorschlag zur Verfügung (wird einfach mit gesichert) und wer eine andere Datenbank einsetzt, ist - wie Du selbst anmerkst - durchaus in der Lage, seine Datenbank eigenverantwortlich zu sichern. Auf meiner TODO-Liste steht ohnehin noch eine Backup- und Restore-Funktionalität. Das hat aber mit dem fhem-update & backup Prozess nichts zu tun.

ich habe reagiert, weil ich z.Zt den Martin (den Autor) vertrete.

Das war für mich aus dem Modul heraus nicht erkennbar.

kannst natuerlich bessere Loesungen vorschlagen

Das habe ich bereits getan.

[betateilchen]

Statt die DB zu sichern schlage ich vor, dass ihr eine eine Methode ... baut

Mich brauchst Du nicht in der Mehrzahl ansprechen, ich bin nicht der König hier

[rudolfkoenig]

Mich brauchst Du nicht in der Mehrzahl ansprechen, ich bin nicht der König hier (http://forum.fhem.de/Smileys/default/wink.gif)

Sehr originell...
Du bist nicht alleine in der Lage sowas zu bauen, und ich wollte dich nicht direkt mit eine Aufgabe ueberrennen.

Das habe ich bereits getan.

Nach meinem Kommentar

ich finde es nicht richtig, dass FHEM per default bei einigen Datenbanktypen was sichert, bei anderen nicht.

muesste dir auch klar sein, warum mir das nicht passt.

[betateilchen]

Es gibt weder einen Grund, noch eine Notwendigkeit, fhem Benutzer, die mit configDB arbeiten, die Nutzung er standardmäßigen Backupmöglichkeit zu verweigern, wie Du das nach Deinem Kahlschlag jetzt tust.

Ausser vielleicht Deiner Willkür, die für mich inzwischen zwar berechenbar ist, aber deren Sinnhaftigkeit sich mir nie erschließen wird.

Deine Argumentation "für ein Datenbanksystem ist die Sicherung eingebaut, für die andere nicht" zieht für mich nicht. Denn für SQLITE muss ich dafür überhaupt nichts extra einbauen, weil es lediglich eine Datei mehr ist, die bei der Sicherung berücksichtigt wird. Insofern werden MySQL Benutzer nicht durch Nichtimplementation benachteiligt, sondern Sqlite Benutzer profitieren von einem automatisch vorhandenen Vorteil, den dieses Datenbanksystem von Haus aus mitbringt.

Nimm bitte Deine diskriminierenden Änderungen an den beiden Modulen update.pm und backup.pm zurück. Einen funktionierenden Patch, der das beschriebene Grundproblem, nämlich eine Fehlermeldung beim update bzw. backup, beseitigt, hatte ich weiter oben schon gepostet. Nur um diese Fehlermeldungen ging es mir eigentlich.

Über backup- und restore-Strategien der configDB kümmere ich mich schon noch. Darüber musst Du Dir nicht den Kopf zerbrechen, die configDB hat Dich meines Erachtens auch bisher nicht sonderlich interessiert.

[rudolfkoenig]

Auch wenn Du es umformulierst, bleibt es dabei: fuer manche Datenbanken bietet dein Patch eine Sicherung an, fuer andere nicht.
Und nach deine Aussage zu urteilen bist Du auch nicht an einer allgemeingueltigen Loesung interessiert, es reicht, wenn die von dir favorisierte Datenbank abgedeckt ist. Ich kann aber keinem Benutzer zumuten, dass FHEM zwar eine Sicherungsdatei erstellt, aber das was er nirgendwo sonst herunterladen kann (die Konfig) in dieser Sicherung nicht enthalten ist. 

Viele die eine Aenderung haben wollen, sehen nur ihr eigenes Beduerfnis, meine Aufgabe als Maintainer ist, auch an die anderen Benutzer zu denken.

Noch ein Vorschlag, um zu zeigen dass ich nicht bockig bin: Du streichst den Support fuer andere Datenbanken in configDB, dann werde ich dein Patch einbauen (vorausgesetzt es ist getestet und funktioniert).

[betateilchen]

Ich persönlich habe überhaupt kein präferiertes Datenbanksystem. Sqlite finde ich einfach charmant, weil es für die Nutzer das am einfachsten zu nutzende Datenbanksystem ist wäre.

Ich kann aber keinem Benutzer zumuten, dass FHEM zwar eine Sicherungsdatei erstellt, aber das was er nirgendwo sonst herunterladen kann (die Konfig) in dieser Sicherung nicht enthalten ist. 

und ohne die FHEM Konfiguration ein Backup mAn sinnlos ist.

Diese Aussagen können doch nur in Deinem eingefahrenen fhem.cfg-Denken begründet liegen, denn

• Ein fhem ohne fhem.cfg ist in der Tat sinnlos.
• Ein fhem mit configDB lässt sich aber selbst mit komplett fehlender Konfiguration zumindest noch starten und bietet dem Anwender ein nutzbares/vollständig funktionsfähiges Frontend. Insofern macht das Sichern des gesamten fhem (wie bisher) selbst ohne eine enthaltene Konfigurationsdatenbank durchaus Sinn.

Ich schlage vor, wie entfernen die automatische Sicherung im Falle von SQLITE einfach durch Änderung des patches wie folgt:

Code Auswählen Erweitern



Index: 98_backup.pm
===================================================================
--- 98_backup.pm (revision 5166)
+++ 98_backup.pm (working copy)
@@ -78,12 +78,24 @@
     }
   }

-  # get pathnames to archiv
-  push @pathname, $configfile;
-  Log 4, "backup include: '$configfile'";
-  $ret = parseConfig($configfile);
-  push @pathname, $statefile;
-  Log 4, "backup include: '$statefile'";
+  if($attr{global}{configfile} eq 'configDB') {
+    # add configDB configuration file
+    push @pathname, 'configDB.conf';
+    Log 4, "backup include: 'configDB.conf'";
+   # my ($dbtype,$dbpath) = _cfgDB_backupdata;
+   # Log 4, "backup data from configDB: $dbtype - $dbpath";
+   # if($dbtype eq 'SQLITE') {
+   #   push @pathname, $dbpath;
+   #   Log 4, "backup include: '$dbpath'";
+   # }
+  } else {
+    # get pathnames to archiv
+    push @pathname, $configfile;
+    Log 4, "backup include: '$configfile'";
+    $ret = parseConfig($configfile);
+    push @pathname, $statefile;
+    Log 4, "backup include: '$statefile'";
+  }
   $ret = readModpath($modpath,$backupdir);

   # create archiv



Damit werden wieder alle unterstützten Datenbanksystem gleich schlecht behandelt.

Warum hast Du Dir eigentlich im Falle "Datenbanknutzung für DbLog" noch nie solche Gedanken gemacht?

[rudolfkoenig]

fhem mit configDB lässt sich aber selbst mit komplett fehlender Konfiguration zumindest noch starten

Das kann ich nicht nachvollziehen. Vmtl. gehst du davon aus, dass die DB mit der Konfig nicht kaputt ist, das zaehlt aber nicht.

Ich schlage vor, wie entfernen die automatische Sicherung im Falle von SQLITE einfach durch Änderung des patches wie folgt:

Damit hat aber der configDB Benutzer eine Sicherungsdatei ohne Sicherung der Konfiguration, das ist fuer mich aber sinnlos.

[betateilchen]

Rudi, zum wievielten Male soll ich es noch erklären?

Auch wenn Du es nicht nachvollziehen kannst: ein per Backup gesichertes fhem, das mit configDB arbeitet, lässt sich tatsächlich ohne jeglichen Inhalt in der Konfigurationsdatenbank starten und nutzen. Ob dabei mit sqlite, mysql oder postgresql gearbeitet wird, ist völlig belanglos.

Genau deshalb möchte ich den backup-Befehl genau so nutzbar haben wie bisher, nur ohne die Fehlermeldung, die darauf beruht, dass das Schlüsselwort "configDB" in $attr{global}{configfile} eben keine tatsächlich zu sichernde Datei ist. Nichts anderes macht mein vorgeschlagener Patch: Er vermeidet den Versuch, "configDB" als Datei sichern zu wollen.

[betateilchen]

*stups*

[rudolfkoenig]

Es gibt nix zum stupsen. Du ignorierst, dass ich ein Backup ohne Konfig als sinnlos erachte, und hast schon zwei komplett unterschiedliche Vorschlaege ausgeschlagen. Mehr faellt mir nicht ein, bzw. ich will meine Zeit produktiver nutzen.

[betateilchen]

Es gibt nix zum stupsen. Du ignorierst, dass ich ein Backup ohne Konfig als sinnlos erachte,

Du ignorierst, dass Deine falsche Behauptung auch dadurch nicht richtig wird, dass Du sie hier noch zehnmal hinschreibst.

und hast schon zwei komplett unterschiedliche Vorschlaege ausgeschlagen.

Du hast meine Vorschläge und mein Eingehen/Entgegenkommen auf Deine Vorschläge völlig ignoriert. Ich bin Dir schon soweit entgegengekommen, die ursprünglich vorgeschlagene Unterscheidung auf SQLITE wieder auszubauen und alle Datenbanksysteme gleich zu behandeln.

Eine Fehlermeldung bei der Ausführung eines Befehles dadurch zu verhindern,
dass man dem User die Benutzung des Befehls komplett untersagt,
ist für mich jedenfalls keine Lösung!

[betateilchen]

Bei Vernunft gegen Willkür kann die Vernunft nur verlieren.
Schade für die Anwender...

Mehr faellt mir nicht ein, bzw. ich will meine Zeit produktiver nutzen.

Geht mir inzwischen eigentlich genauso.
Deshalb ist hier jetzt geschlossen und ich werde meine Zeit nutzen,
den Anwendern eine funktionierende Lösung für die gestellte Aufgabe zu schaffen.