93_DbLog - Vorschläge zur Weiterentwicklung

[betateilchen]

Hallo Tobias,

wie per email gewünscht, hier der neue Thread zur Weiterentwicklung des Datenbank-Loggings.

Den Patch zur Implementierung diverser "set"-Kommandos habe ich Dir schon per email geschickt.
Er enthält im Moment folgende mögliche Kommandos:

Code Auswählen Erweitern



set <name> reopen

set <name> count

set <name> deleteOldDays <n>

set <name> userCommand <sqlStatement>



Die Beschreibung der Befehle ist im englischsprachigen pod der Moduldatei enthalten.

Viele Grüße
Udo

[betateilchen]

Fein, dass es die set-Erweiterung in den Standard geschafft hat Jetzt müsste nur noch jemand die deutsche commandref ergänzen.
Vielleicht mach ich das heute Nachmittag während meiner Bahnfahrt.

Und ich hab die Hoffnung noch nicht aufgegeben, dass auch das einfach Auslesen einzelner Werte wie hier beschrieben

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

es noch irgendwann in das Modul schafft 

[Tobias]

Hi Udo,
das mergen des Patches steht noch auf meiner Liste, keine Sorge... ist nur noch nicht im SVN

Und das einfache Abfragen funktioniert seit dem letzten commit auch schon:

my %myHash = DbLog_Get("CURRENT", "ARRAY", "", "", "KS300:temperature")

Achtung: nur aus dem Kopf heraus: Beispiel siehe Text2Speech-Modul

[betateilchen]

Hallo Tobias,

schon klar. Aber für  meinen Einsatzzweck viel zu umständlich.
Keine Sorge - ich hab ja mein gepatchtes 93_DbLog, da ist die Funktion schon drin und ich kann mich deshalb in Geduld üben.

Viele Grüße
Udo

[betateilchen]

Hier kommt die diff Datei für die deutsche commandref zu den SET Befehlen.

[Tobias]

Was ich noch nicht verstanden habe ist warum du current-werte auslesen willst. Kommst du mit ReadingsVal nicht weiter?

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Das habe ich doch im angegebenen Thread schon (meiner Meinung nach ausführlich) erklärt. Da wo ich die Werte plotten will, gibt es keine devices, ergo auch keine Readings.

[betateilchen]

ich hab hier grade schonmal geantwortet... komisch.

Warum ich das machen will, habe ich meiner Meinung nach im anderen Thread bereits ausführlich erklärt. Da wo ich die Daten brauche, gibt es keine devices und somit auch keine readings.

[Tobias]

Hallo Udo,
deinen Hauptpatch bekomme ich nicht eingespielt. Der 93_diff Patch lief ohne Probleme durch. Kannst du mir den Patch bitte nochmal neu erstellen?

[betateilchen]

klar, wenn Du mir nochmal genau beschreibst, welcher Patch nicht funktioniert. Der mit den Readings?

[Tobias]

Der erste den du mir per Mail geschickt hast.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

ok, die Set Funktionen sind ja schon eingebaut, die Doku dazu stand im vorigen Post.

Wenn Du auf der Suche nach der Readings-Funktion bist, habe ich hier nochmal einen Patch, da ist auch die commandref Doku für diese Funktion schon in beiden Sprachen drin.

Ich hoffe, das war das Gesuchte.

[Tobias]

eingecheckt... bitte mal testen...

[betateilchen]

Hallo Tobias,

sieht gut aus

Code Auswählen Erweitern


----------
Readings:
     2014-03-08 15:35:05   _dataSource     www.openweathermap.org
     2014-03-08 15:35:05   _decodedWith    XML
     2014-03-08 15:35:05   _httpResponse_c 200 OK
     2014-03-08 15:35:05   c_humidity      73
----------

get dbLog ReadingsVal owo c_humidity 77 liefert: 73

get dbLog ReadingsTimestamp owo c_humidity 77 liefert: 2014-03-08 15:35:05



Danke!

[betateilchen]

Hallo Tobias,

irgendwie existiert ein Problem beim Zusammenspiel zwischen DbLog und SVG

Code Auswählen Erweitern


2014.03.26 17:36:27.422 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:27.431 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2981
2014.03.26 17:36:27.506 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:27.528 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:27.544 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2982
2014.03.26 17:36:27.557 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2983
2014.03.26 17:36:27.595 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:27.624 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2984
2014.03.26 17:36:27.632 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:27.640 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2985
2014.03.26 17:36:27.686 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:27.714 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2986
2014.03.26 17:36:28.742 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:28.770 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2987
2014.03.26 17:36:28.833 3: Connecting to database SQLite:dbname=/opt/fhem/sqldb/logDB.db with user
2014.03.26 17:36:28.868 3: Connection to db SQLite:dbname=/opt/fhem/sqldb/logDB.db established for pid 2988


Die 8 Prozesse, die hier eine Verbindung zur Datenbank aufbauen, sind 8 SVG plots, die auf einer Seite in fhem dargestellt werden. Es sieht so aus, als würde jeder SVG Prozess eine eigene Verbindung zur Datenbank aufbauen, anstatt die ohnehin instanziierte Verbindung zu verwenden.

Warum ist das notwendig? Siehst Du eine Möglichkeit, an dieser Stelle etwas zu optimieren?

Edit: ok, ich weiss nun zumindest, dass ohne die vielen Verbindungen nicht korrekt funktioniert Bestimmt komme ich auch noch dahinter, warum das so sein muss (?)

[Tobias]

Sollte eigentlich nicht so sein. Nur eine connection. Ich pruef das mal in meinem log.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[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

[betateilchen]

ja, hatte ich gestern abend noch gesehen, danke.

Was meinst Du denn zu dem Vorschlag, die Verbindungsdaten nur einmal im define zu lesen, anstatt jedesmal bei einem Verbindungsaufbau? Letztendlich werden beispielsweise bei jedem plotfork und auch bei danach meist notwendigen Verbindungsaufbau die Konfigurationsparameter neu eingelesen, was meines Erachtens überhaupt nicht notwendig ist.

Ich könnte Dir dazu am Wochenende mal einen patch bauen, wie ich mir das konkret vorstelle.

[Tobias]

Hintergrund ist das die Daten NICHT im Klartext per List oder fhem.cfg sichtbar sind.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Also sorry - für mich ist diese Argumentation schlichter Unfug. Zumal Verbindungsdaten zu einem Logfile ja generell kein großartiges Geheimnis darstellen.

So zu Lasten der allgemeinen Performance zu arbeiten, finde ich absolut unsinnig. Wenn jemand seine Datenbank-Konfigurationsdatei in das Verzeichnis /FHEM legt und die Datei mit .cfg endet, wird sie sogar in FHEMWEB im Frontend zum Editieren angeboten - das kannst Du auch nicht verhindern.

[Tobias]

Die Datei liegt natürlich ausserhalb des fhem Verzeichnisses.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Das kannst Du als Modulautor doch gar nicht beeinflussen - die kann liegen, wo immer der Anwender das möchte und für richtig hält.

[Tobias]

Es muss eine Lösung gefunden werden das die connectdatei nur einmal einliest.
Ich möchte an der Auslagerung festhalten. Ist auch ein Überbleibsel vom Boris neubert. Verstehe aber auch dein Anliegen.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Ich habe ja nichts gegen die Auslagerung an sich - die macht durchaus Sinn.
Aber das unendlich oft erfolgende Einlesen immer wieder der gleichen Konfigurationsdatei (bzw. das Lesen immer wieder der gleichen Datenbankdaten) macht keinen Sinn.

[Tobias]

D.h. ins define verlagern.... und bei "set reopen" ebenfalls aufrufen.  kannst du einen Patch als Vorschlag machen?

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

patch Erstellen hatte ich ja weiter oben schon angeboten - ich werde mich am Wochenende mal dransetzen.

[betateilchen]

D.h. ins define verlagern....

erledigt.

und bei "set reopen" ebenfalls aufrufen.

Das macht im reopen keinen Sinn, denn das reopen macht nix weiter als "Verbindung zu. Verbindung auf."

Aber ich verstehe, was Du meinst: Du möchtest ein
"set <name> rereadcfg" - das wird genauso funktionieren wie das reopen, mit dem Unterschied, dass zwischen disconnect und connect ein readcfg durchgeführt wird.

kannst du einen Patch als Vorschlag machen?

Bereits in Arbeit (genauer: im Testbetrieb) Da ist übrigens auch die Änderung hier aus dem Thread enthalten, die dafür sorgt, dass bei (Noch-)Nichtverfügbarkeit der Datenbank kein Abbruch mehr erfolgt, sondern alle 5 Sekunden versucht wird, die Verbindung herzustellen (zur Umgehung der hier ausführlich diskutieren Bootreihenfolgeproblemaik).



Anmerkung:

Zu den durch plotfork verursachten Problemen mit dem Verbindungsverlust habe ich inzwischen auch einen eleganteren Lösungsansatz - den muss ich aber erst noch implementieren und ausführlich testen.

[betateilchen]

kannst du einen Patch als Vorschlag machen?

Der Patch ist fertig und befindet sich im Test gegen SQLITE und MySQL (Postgre kann ich nicht testen)

Hintergrund ist das die Daten NICHT im Klartext per List oder fhem.cfg sichtbar sind.

Schau mal, damit Du ruhig schlafen kannnst

So sieht das bei SQLITE aus:

(http://up.picr.de/18072664pq.png)

So sieht das bei MySQL aus:

(http://up.picr.de/18072719qb.png)

Da der connection-String und der User sogar im Log ausgegeben werden, habe ich kein Problem damit, die in den Internals zu sehen. Das Psaswort siehst Du da aber nicht

Zufrieden?

[betateilchen]

Um 21:06:20 wurde fhem gestartet, der MySQL Server lief zu diesem Zeitpunkt nicht.
Um 21:07:00 wurde auf einem anderen Rechner der MySQL Server gestartet.
Um 21:07:08 hat fhem automatisch die Datenbankverbindung hergestellt, nachdem der MySQL Server verfügbar war.

Code Auswählen Erweitern


2014.04.24 21:06:38 4: DbLog: Trying to connect to database
2014.04.24 21:06:38 4: Waiting for database connection
2014.04.24 21:06:43 3: Connecting to database mysql:database=fhemLog;host=rasp-nas;port=3306 with user fhem-dev
2014.04.24 21:06:43 4: DbLog: Trying to connect to database
2014.04.24 21:06:43 4: Waiting for database connection
2014.04.24 21:06:48 3: Connecting to database mysql:database=fhemLog;host=rasp-nas;port=3306 with user fhem-dev
2014.04.24 21:06:48 4: DbLog: Trying to connect to database
2014.04.24 21:06:48 4: Waiting for database connection
2014.04.24 21:06:53 3: Connecting to database mysql:database=fhemLog;host=rasp-nas;port=3306 with user fhem-dev
2014.04.24 21:06:53 4: DbLog: Trying to connect to database
2014.04.24 21:06:53 4: Waiting for database connection
2014.04.24 21:06:58 3: Connecting to database mysql:database=fhemLog;host=rasp-nas;port=3306 with user fhem-dev
2014.04.24 21:06:58 4: DbLog: Trying to connect to database
2014.04.24 21:06:58 4: Waiting for database connection
2014.04.24 21:07:03 3: Connecting to database mysql:database=fhemLog;host=rasp-nas;port=3306 with user fhem-dev
2014.04.24 21:07:03 4: DbLog: Trying to connect to database
2014.04.24 21:07:03 4: Waiting for database connection
2014.04.24 21:07:08 3: Connecting to database mysql:database=fhemLog;host=rasp-nas;port=3306 with user fhem-dev
2014.04.24 21:07:08 3: Connection to db mysql:database=fhemLog;host=rasp-nas;port=3306 established for pid 3501
2014.04.24 21:07:08 3: Connection to db mysql:database=fhemLog;host=rasp-nas;port=3306 established


[betateilchen]

Hier kommt der versprochene Patch. Erfolgreich getestet gegen SQLITE und MySQL.

[Tobias]

Hi Udo,
kannst du mir einen Gefallen tun und das Diff nochmal gegen die aktuelle DbLog VErsion von morgen erstellen? Ich würde es nächste Woche dann erstmal ins Contrib einchecken...

[betateilchen]

welches Diff? Und wieso plötzlich contrib? Dann haben wir plötzlich zwei DbLog Modul - das macht doch keinen Sinn.

[Tobias]

na der Patch von vorheriger Seite... Contrib nehme ich gerne um größere Änderungen vorher durch andere prüfen zu lassen ohne gleich auf Alle loszulassen. Nach 2-3 Wochen kommt es auch contrib wieder raus ins Main

[betateilchen]

Du wolltest von mir gestern einen patch haben und nun soll ich den morgen nochmal bauen.

Die Änderung bezüglich des wiederholten Verbindungsaufbau habe ich schon vor Wochen hier vorgeschlagen, ohne dass irgendwo aufgetaucht wäre - weder in contrib, noch in FHEM.

Wie oft eigentlich noch? Ich hab auch noch wichtigere FHEM Baustellen, als nun zum dritten Mal die gleiche Änderung zu diffen.

*FRUST*

[Tobias]

iss ja gut
ich pass ihn nächste Woche manuell an... hatte da nämlich schon andere Änderungend rin...

[betateilchen]

Irgendwann müssen wir das Modul trennen in den Daten-Teil und in den Datenbankverbindungs-Teil

Ich bau Dir den patch am Wochenende. Aber nur, wenn Du mir versprichst, dass ich es kein viertes Mal machen muss.

[betateilchen]

Ist denn die JETZT in SVN eingecheckte Version schon die aktuelle oder kommt da noch eine andere bis morgen?

[Tobias]

Hab den hotfix vorhin comitted. Mehr kommt nicht. Und versprochen. Den Patch Bau ich nächste Woche ein

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

ok, ich baue also den Patch jetzt gegen diese Version:

# $Id: 93_DbLog.pm 5646 2014-04-25 18:03:29Z tobiasfaust $

[betateilchen]

Da hast Du das Gesamtkunstwerk...

[Tobias]

Da hast Du das Gesamtkunstwerk...

Danke... bekomme es nicht gepatcht, nur Hunks... ich machs dann doch von Hand. Musst nicht nochmal bauen. Dachte ich kann es heute morgen noch mal eben schnell machen...

[betateilchen]

Warum kannst Du nicht einfach mal genau beschreiben, was Du eigentlich willst?
Ich hatte doch extra gefragt, ob die gestrige Version nun die aktuelle ist - was willst Du denn jetzt schon wieder rumpatchen?

Hier hast Du die reine diff-Datei.

Du kannst mir auch Deine Entwicklungsdatei per email schicken, dann baue ich die Änderungen zur Verbindungsverwaltung dort ein.

[betateilchen]

Wenn Du es Dir einfach machen willst:

Nimm die folgende Modulteile aus meiner gestern hier angehängten kompletten Moduldatei und kopiere sie in "Deine" Version:

• sub DbLog_Define($@)
• sub _DbLog_readCfg($)
• sub DbLog_Connect($)
• sub DbLog_Set($@)

Der Rest ist Kleinkram und meist nur "Optik". Den kann ich Dir dann nachreichen, wenn wir mal eine KLARE Modulversion haben.

[Tobias]

sorry, war heute morgen zu früh und schon im Urlaubs-Packstress...Hatte das pm fälschlicherweise als diff angesehen. KANN natürlich nicht funktionieren...
Habe die komplette pm Datei getestet und im MainStream commited. Meine nächsten größeren Änderungen kommen dann ins contrib zum Testen.
Es kommen 3 neue Attribute (host, gueltig_bis, agg_kz), da weiß ich aber noch nicht wie ich das beim Define automatisiert prüfen und hinzufügen kann.

[betateilchen]

Es kommen 3 neue Attribute (host, gueltig_bis, agg_kz), da weiß ich aber noch nicht wie ich das beim Define automatisiert prüfen und hinzufügen kann.

So ein ähnliches Problem hab ich aktuell auch in der configDB.
Geh erstmal in Ruhe in Urlaub, vielleicht fällt mir ein sinnvoller Weg ein, wie wir in fhem bei Bedarf Datenbanken migrieren können.

[Tobias]

Naja, das Wort "migrieren" hat meiner (beruflichen) Erfahrung nach etwas negatives was mit viel Daten schaufeln assoziiert wird. Ich habe über 15Mio Datensätze in meiner produktiven DbLog DB... Da möchte ich nur Metadatenänderungen durchführen......  (Naja, gegenüber den 20TB in meinem Beruflichen Umfeld ist das nichts...)

[betateilchen]

Naja, solange Du nur zusätzliche Spalten anfügen willst, ist das nicht so dramatisch. Richtig kompliziert wird es, wenn man bestehende Felder verändern will (z.B. die Länge des Devicenamen von 32 auf 64 verändern) zumal, wenn das gewünschte Feld auch noch in einem Index verwendet wird.