Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[sinemeter]

Hi, hier das Log des Fhem Containers um 13:47 nach Finish.

Code Auswählen Erweitern


2023.02.08 13:47:25.819 3: [echo] [echodevice_NPMLoginRefresh] alexa-cookie modul not found
2023.02.08 13:47:35.665 3: DbRep DBLogging_DbRep - 6425118 records inserted (size of backupfile: 1379.23 MB)
2023.02.08 13:47:35.667 3: DbRep DBLogging_DbRep - Deleting old dumpfile 'fhem_2023_02_08_09_40.sql'
2023.02.08 13:47:35.756 3: DbRep DBLogging_DbRep - Finished backup of database fhem - total time used (hh:mm:ss): 00:39:10
2023.02.08 13:47:35.759 4: DbRep DBLogging_DbRep - execute command after dump: '{backupSqlFiles("DBLogging_DbRep")}'
2023.02.08 13:47:35.772 3: DbRep DBLogging_DbRep - Database dump finished successfully.
2023.02.08 13:48:25.822 3: [echo] [echodevice_LoginStart] Alter COOKIE=2827040/6000 Refresh Cookie!
2023.02.08 13:48:25.822 3: [echo] [echodevice_NPMLoginRefresh] alexa-cookie modul not found


Ich kann damit aber leider nicht ersehen das was schief gelaufen ist.
Das Kommando wurde ausgeführt aber es wurde weder die Telegram Nachricht verschickt noch das File kopiert

[DS_Starter]

Jetzt ist mir der Grund klar geworden.
executeAfterProc  führt das Script aus wenn die Funktion erledigt ist, aber noch bevor die Readings angelegt werden.
Hinterlege dein Script in dem Attr userExitFn leicht abgewandelt in dieser Form:

Code Auswählen Erweitern


############################################################################################################
########       Aktion nach einem Backup     
############################################################################################################
sub doafterdump {
my ($name,$reading,$value) = @_;
my $hash   = $defs{$name};
my $dbname = $hash->{DATABASE};

   return if($reading ne "state" || ($reading eq "state" && ReadingsVal($name,"state",'') =~ /Dump is running/));
   
   if ($reading  = "state" && ReadingsVal($name,"state",'') !~ m/Database.*backup.*(finished|timed.*)/) {

my $file = ReadingsVal($devspec, "DumpFileCreated", "");
if ($file ne "") {
system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

return 1;
}

return 0;
   }

return;
}


Ich werde prüfen ob ich executeAfterProc  nebenwirkungsfrei auch nach der Readingserstellung ausführen kann. Aber es gab sicherlich einen Grund es so zu machen wie es jetzt ist. Muß ich schauen ...

[RalfRog]

Würde ich auch drauf reinfallen. Würde vermutlich jedem passieren der nicht so tief drinsteckt.

Das Problem ist als "Anwender" vermutlich auch schwierig zu erkennen - man (ich) geht davon aus, dass executeAfterProc gestartet wird wenn DBRep fertig ist.
Vielleicht könnte man es über diverse LOG temporär zum Debuggen in 99_myutil fangen.

So hatte ich mich ja auch mal über die mehrfache Ausführung der Kommandos in userExitFn gewundert - bis du mir erklärt hast, das es mehrfach getriggert werden kann.

...insofern fänd ich eine solche Änderung begrüßenswert

Gruß Ralf

[DS_Starter]

Ja, verstehe ich Ralf.
Ich schaue es mir an. Betrifft im Prinzip alle "done" Routinen.
Aber ich muß in mich gehen, meistens gab es einen bestimmten Grund es so und nicht anders zu machen.
Manchmal habe ich aber auch nur den Tunnelblick. 

[sinemeter]

Hi zusammen,


Vielen lieben Dank schonmal für die tolle Unterstützung!

Wenn ich Deinen Code speichere bekomme ich
beim Save in MyUtils den Fehler:

ERROR:
Global symbol "$devspec" requires explicit package name (did you forget to declare "my $devspec"?) at ./FHEM/99_myUtils.pm line 44.

Zeile 44:
s. Screenshot.

Da ich Perl noch zu wenig verstehe:
Wie genau muss das Attrib in UserExitFn aussehen um Deine Funktion aufzurufen?
Muss ich Argumente übergeben?

[DS_Starter]

Hi,

naja, war von mir nur schnell "zusammengklöppelt".
Das geht auch einfacher:

Code Auswählen Erweitern


sub doafterdump {
 my ($name, $reading, $value) = @_;
 my $hash   = $defs{$name};
   
   if ($reading  eq "DumpFileCreated")  {
my $file = $value;
if ($file ne "") {
system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

return 1;
}
   }
 
return 0;
}


Die Angabe im Attribut erfolgt mindestens mit dem Namen der Routine und optional mit einem Regex. Das ist in der Commandref genau beschrieben. Variablen übergibst du nicht, das passiert intern und ist auch in der Comref beschrieben.
Bei dir würde ich raten es so zu definieren:

Code Auswählen Erweitern

attr userExitFn doafterdump DumpFileCreated:.*

Dadurch wird nur das Reading "DumpFileCreated" an die sub doafterdump übergeben. Theoretisch könnte man dadurch die äußere if-Bedingung noch weglassen, also die sub z.B. so definieren:

Code Auswählen Erweitern


sub doafterdump {
  my $name    = shift;
  my $reading = shift;
  my $file       = shift;

  if ($file ne "") {
      system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
      fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

      return 1;
  }
 
return 0;
}


Es gibt also wie immer verschiedene Möglichkeiten.

[DS_Starter]

@all,

in meinem contrib liegt eine neue V 8.51.6.
Nun wird executeAfterProc erst nach der Readinggenerierung ausgeführt.
Der Umbau war nicht ganz trivial, da eventuelle Error-State, die sich aus einem Funktionsproblem heraus ergeben nicht durch Fehler im executeAfterProc überschrieben werden sollen. Das war auch der Grund für die bis dato eingebaute Funktionsweise.

Deswegen erstmal im contrib für Tests über das WE.

LG,
Heiko

[m.zielinski]

Nutzt hier jemand das SQLSpecial 50mostFreqLogsLast2days ?
Irgendwas stimmt da mit dem timestamp nicht - ich bekomme statt der letzten 2 tage die gesamtanzahl in meiner DB...

Auch wenn ich die DB runterlade und mit DB Browser die SQL ausführen bekomme ich viel zu hohe Trefferzahlen:  select Device, reading, count(0) AS `countA` from history where ( TIMESTAMP > ('now' - '2 days')) group by DEVICE, READING order by countA desc, DEVICE limit 50

Nur wenn ich die Timestamp-Berechnung manuell mache bekomme ich plausible werte:  select Device, reading, count(0) AS `countA` from history where ( TIMESTAMP > '2023-02-09 00:00:00') group by DEVICE, READING order by countA desc, DEVICE limit 150

ALternativ scheint auch zu funktionieren: datetime('now' ,'-2 days')

Mit diese Funktion gucke ich, ob manche Geräte viel zu geschwätzig sind...

[DS_Starter]

Ich habe das SQL für MySQL angepasst und ins contrib geladen zum Test.
Ausgerollt wird es mit dem kommenden check in.

[DS_Starter]

Neue V ist eingecheckt und morgen früh im Update enthalten.

LG

[m.zielinski]

Neue V ist eingecheckt und morgen früh im Update enthalten.

Hi - falls sich deine Antwort auf mein Problem mit dem 50mostFreqLogsLast2days-sql bezog - ich nutze SQLite Und eben nach updatefhem ist der Fehler noch immer da.

Hast du das evtl bei den recentReadingsOfDevice geändert ?
Lg

[DS_Starter]

Hi - falls sich deine Antwort auf mein Problem mit dem 50mostFreqLogsLast2days-sql bezog - ich nutze SQLite ...

Ah ok.
Nein, hatte es tatsächlich für MySQL geändert. Da war es mir jetzt auch aufgefallen.
Ich ändere es auch für SQLite und checke eine neue V wahrscheinlich schon heute Abend ein.

Es kommt mit dieser Version auch ein neuer Setter "migrateCollation" hinzu um den Zeichensatz einer MySQL/MariaDB nebst Tabellen umzustellen.
Gilt nicht für SQLite.

[DS_Starter]

Morgen früh wird eine neue DbRep Version ausgeliefert.
Neben kleineren Fixes ist der Support für den Zeichensatz utf8mb4 eingebaut, um die neue DbLog Version entsprechend zu unterstützen.

Um eine bestehende MySQL/MariaDB-Datenbank einfach nach utf8mb4 zu migrieren, kann jetzt der neue Setter "migrateCollation" genutzt werden.
Die Hintergründe bzgl. utf8mb4 könnt ihr in diesem Thread lesen:
https://forum.fhem.de/index.php/topic,132163.0.html

LG

[ch.eick]

Moin,
beim executeAfterProc ist die Hilfe durcheinander.
VG   Christian

[DS_Starter]

Hmm, bei mir nicht.....