93_DbLog - Vorschläge zur Weiterentwicklung

[betateilchen]

Doch, das ist so. Die Verbindungen werden wegen plotfork generiert.

Vermutlich, weil sonst die vielen Handles durcheinanderkommen.

[justme1968]

sobald plotfork gesetzt ist wird pro prozess eine eigene db connection aufgemacht. das muss so sein weil sich die prozesse sonst auf der einen connection in die quere kommen. es zeigt also kein problem sonder ganz im gegenteil das alles richtig arbeitet.

die meldung könnte man aber inzwischen auf level 4 oder sogar 5 schieben. die war nur aus debug gründen anfangs auf level 3.

gruss
  andre

[betateilchen]

Ja, das mit dem "in die Quere kommen" ist mir inzwischen auch klar geworden. Gibt lustige Plots, wenn man versucht, das zu ändern

die meldung könnte man aber inzwischen auf level 4 oder sogar 5 schieben.

Das hatte ich zwischenzeitlich bei mir auch schon so gemacht.

[justme1968]

ich hab das schließlich nicht ohne grund eingebaut

[Tobias]

Alles klar. Also Kein bug. Kam nicht von mir deswegen war es mir auch nicht gleich bewusst ohne in den  Code geschaut zu haben.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

es ist auch nicht ganz einfach nachzuvollziehen, was von wem in dem Modul stammt

[justme1968]

der patch und der kommentar beim einchecken sagt aber ganz klar fix for plotfork.

[betateilchen]

jaja... ich meinte jetzt, im Modul erkennbar, nicht in SVN.

[betateilchen]

es scheint mit dem plotfork in dblog auch an anderen Stellen Probleme zu geben...

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

[justme1968]

da gibt es tatsächlich ein problem. hier gab es keins .

gruss
  andre

[betateilchen]

Im Anhang eine Modulversion, die auch bei nicht existierenden Datenbankverbindungen das Logdevice anlegt und in diesem Fall alle 5 Sekunden versucht, die Verbindung aufzubauen.

Bitte um Tests und Rückmeldungen.

[betateilchen]

Hallo Tobias,

könntest Du bitte diese Änderung einbauen

Code Auswählen Erweitern


################################################################
#
# Verbindung zur DB aufbauen
#
################################################################
sub DbLog_Connect($)
{
  my ($hash)= @_;

  my $configfilename= $hash->{CONFIGURATION};
  my @config;
  my %dbconfig;

  if(configDBUsed()) {
    my $c  = _cfgDB_Readfile($configfilename);
    if(! $c) {
      Log3 $hash->{NAME}, 1, "Cannot open database configuration file $configfilename.";
      return 0;
    }
    @config = split(/\n/,$c);
  } else {
    if(!open(CONFIG, $configfilename)) {
      Log3 $hash->{NAME}, 1, "Cannot open database configuration file $configfilename.";
      return 0;
    }
    @config=<CONFIG>;
    close(CONFIG);
  }

  eval join("", @config);


damit künftig die Verbindungsdateien auch aus einem in der configDB gespeicherten Konfigurationsfile gelesen werden können. Sonst ändert sich nicht, das define wird genau so durchgeführt wie bisher, nur dass das Konfigurationsfile nicht mehr im lokalen Dateisystem sondern in der configDB gesucht wird. Dazu reicht es aus, eine bestehende Konfigurationsdatei einmalig in die Datenbank zu importieren.

Code Auswählen Erweitern

configdb fileimport ./FHEM/logDB.cfg

Wobei ich an dieser Stelle die grundsätzliche Frage in den Raum stellen möchte, ob es wirklich Sinn macht, bei jedem Verbindungsaufbau die komplette Konfiguration neu zu lesen (die sich in einem laufenden fhem besser niemals ändern sollte!) oder ob man das Lesen nicht in das DEFINE verlagern sollte.

Viele Grüße
Udo

[Tobias]

ist eingebaut...

[betateilchen]

aber noch nicht eingecheckt?

[Tobias]

doch, gestern abend 20Uhr