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

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

frober

Nochmal als Rückmeldung:
Heute 2x geschaltet, funktioniert einwandfrei.

Danke Heiko, für deinen super Support.

LG
Bernd
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

RalfRog

Zitat von: DS_Starter am 17 Mai 2022, 09:39:56
Danke Ralf für die Info. Sieht ja schon gut aus  :)

Bisher immer noch alles (insert) sauber :)

Gruß Ralf
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Nighthawk

Hallo Heiko,

gibt es eigentlich eine Möglichkeit Werte aus der DB in ein Reading zu schreiben?
Hintergrund ist mein Problem mit dem Statistics Device, dieses hat irgendwie Probeme mit "temperature", da ich aber die Höchsttemperatur und Durchschnittstemperatur für meine Bewässerung benötige, wäre die Frage ob ich diese Werte (die in der DB eh jeden Tag erzeugt werden) für die Bewässerung heranziehen kann.

Gruß
Alex

frober

Ja, z.B. mit maxValue, minValue oder averageValue.

Ein
set dbrep minValue display reicht.

Dann mit Attribut autoForward das Ziel definieren und den Zeitraum für die Datenermittlung eingrenzen.
z.B. {
  ".*MAX.*" => "KS300 => MAXTemp", 
  ".*MIN.*" => "KS300 => MINTemp",
}


Ansonsten einfach Mal die Comref lesen...
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Nighthawk


RalfRog

Funktion Attribut userExitFn

Hallo Heiko
Irgendwann nach einem Update so Anfang März hat meine userExitFn-Funtion"db_File_Cleanup" nicht mehr funktioniert  :-[ (scheint nicht mehr aufgerufen zu werden)
Hat sich seit Ende letzten Jahres/Anfang diesen Jahres hier etwas beim Aufruf geändert?

Lt. Commandref muss jetzt der RegEx matchen.

  • Heisst das, dass "userExitFn db_File_Cleanup state:done" nur exakt dannn aufgerufen wird wenn im DBRep der "state = state:done" ist?
=> Somit könnte ich den Aufruf per "userExitFn db_File_Cleanup state:.*" erzwingen und das Reading in der Funktion (Variablen $reading, $value) auswerten. Wie in der Hilfe auch beschrieben:

sub UserFunction {
  my $name    = shift;             # der Name des DbRep-Devices
  my $reading = shift;             # der Namen des erstellen Readings
  my $value   = shift;             # der Wert des Readings
  my $hash    = $defs{$name};


Was das "my $hash = $defs{$name}" macht muss ich in der Hash-Variablen bei Perl nochmal nachlesen  ::) - ist aber vermutlich im Detail nur dann wichtig wenn man die Werte verwenden will.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

DS_Starter

#1671
Hallo Ralf,

Zitat
Hat sich seit Ende letzten Jahres/Anfang diesen Jahres hier etwas beim Aufruf geändert?
Seit Dezember letzten Jahres man direkt Code zur Ausführung bringen indem er in {..} eingeschlossen wird wie im Fall 2 der ComRef beschrieben.

Zitat
Lt. Commandref muss jetzt der RegEx matchen.

    Heisst das, dass "userExitFn db_File_Cleanup state:done" nur exakt dannn aufgerufen wird wenn im DBRep der "state = state:done" ist?
Das war schon immer so, sofern man etwas angibt. D.h. mit

userExitFn db_File_Cleanup    (wäre identisch mit "db_File_Cleanup .*:.*")

wird db_File_Cleanup für jeden Einzelwert aufgerufen/durchlaufen, wogegen mit

userExitFn db_File_Cleanup state:done

db_File_Cleanup nur aufgerufen für das Reading "state" sofern dessen Wert "done" ist.

Zitat
Was das "my $hash = $defs{$name}" macht muss ich in der Hash-Variablen bei Perl nochmal nachlesen  ::) - ist aber vermutlich im Detail nur dann wichtig wenn man die Werte verwenden will.
Das ist richtig. Brauchst du nur wenn wenn man auf den $hash des DbRep-Devices ($name) zugreifen will/muss.

Um zu prüfen ob deine sub aufgerufen wird kannst du dir einfach ein Log einbauen:

Log3 $name, 1, "UserExitFn $name called - transfer parameter are Reading: $reading, Value: $value " ;

Zitat
Somit könnte ich den Aufruf per "userExitFn db_File_Cleanup state:.*" erzwingen ...
"erzwingen" ist hier das falsche Wort ! Erzwingen kannst du nichts, nur filtern sozusagen.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

RalfRog

Danke für die Erläuterung.  :)

Zitat
Zitat
    Lt. Commandref muss jetzt der RegEx matchen.
    Heisst das, dass "userExitFn db_File_Cleanup state:done" nur exakt dannn aufgerufen wird wenn im DBRep der "state = state:done" ist?

Das war schon immer so, sofern man etwas angibt. D.h. mit


Möglicherweise habe ich den Aufruf selbst (vermeintliche Codeoptimierung) geändert und der Nichtaufruf ist mir zu spät aufgefallen - und die Änderung zwischenzeitlich vergessen.

P.S.
bisher läuft das Thema "set <name> insert" ohne Auffälligkeiten. Auch dafür vielen Dank.

FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

RalfRog

Oh muss doch noch mal nachhaken. Wird die in "userExitFn" definierte Routine während des Abarbeitung der DBRep mehrfach aufgeufen. In meinem Fall nun bei den beiden Statusänderungen running und done?

Attribut in der DBRep:  userExitFn   db_File_Cleanup state:.*

Log mit zweimaligem Aufruf (für den Test lasse ich nur ins Log schreiben und tue nix, also direkt ein return im Code nach dem Logeintrag):

2022.06.03 13:44:23.233 1: UserExitFn DBRep_BackupWoche called - mit transfer-Parameter Reading: state, Value: running
2022.06.03 13:44:23.234 3: Aufruf checken, wenns klappt weiter an der Funktion sub db_File_Cleanup arbeiten
2022.06.03 13:44:24.047 3: DbRep DBRep_BackupWoche - Number of exported datasets from fhem to file /opt/fhem/backup/db_back/week/fhem_history_since-prev-week_2022-22_5.csv: 4325
2022.06.03 13:44:24.061 1: UserExitFn DBRep_BackupWoche called - mit transfer-Parameter Reading: state, Value: done
2022.06.03 13:44:24.061 3: Aufruf checken, wenns klappt weiter an der Funktion sub db_File_Cleanup arbeiten


Das Verhalten sieht natürlich unzweifelhaft so aus  ;D. Den Mehrfachaufruf also ggfs. auch 5mal fangs ich dann ab.
Ich hatte es so verstanden das UserExitFn einmal am Ende aufgerufen wird.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

DS_Starter

Zitat
Wird die in "userExitFn" definierte Routine während des Abarbeitung der DBRep mehrfach aufgeufen. In meinem Fall nun bei den beiden Statusänderungen running und done?
Es wird für jedes erstellte/aktualisierte Reading das Argument im Attribut userExitFn aufgerufen bzw. vorher geprüft ob eine angegebene Regex-Bedingung erfüllt ist.
Wenn ja, wird die Routine aufgerufen.

Wird ein Aktion gestartet, aktualisiert sich i.A. nur das "state" und wird an die sub weitergreicht. Ist der DbRep-Lauf fertig wird der Vorgang für jedes erstellte Reading/Value-Paar durchgeführt und man kann als User entsprechend auswerten.

Hast also richtig beobachtet.  8)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

RalfRog

Danke für die Unterstützung.
Scheint zu klappen - zumindest per execNow im at.
Heute Nacht läuft das reguläre Backup somit vermutlich auch  ;) - für das Monatsbackup muss ich dann noch bis Ultimo warten...

Da sieht man wie leicht man sich selber auf den Holzweg befördert  ::)

FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

juniormajor

Hi in die Runde,

in meiner Testumgebung versuche ich gerade der Funktion "reduceLog" einen Filter mitzugeben.
Lt. Doku sollte auch TYPE= ein valider Filter sein, jedoch schaffe ich es nicht, dass dieser auch berücksichtigt wird.

Config der DbRep:
Internals:
   DATABASE   sensors
   DEF        logdb
   FUUID      619363ed-f33f-22db-c36e-9f029177fb49c324
   FVERSION   93_DbRep.pm:v8.49.0-s26054/2022-05-17
   LASTCMD    initial database connect stopped due to attribute 'fastStart'
   MODEL      Client
   NAME       logdbRep
   NOTIFYDEV  global,logdbRep
   NR         15
   NTFY_ORDER 50-logdbRep
   ROLE       Client
   STATE      initialized
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.49.0
   OLDREADINGS:
   READINGS:
     2022-06-08 11:59:31   background_processing_time 0.00
     2022-06-08 11:59:31   reduceLogState  reduceLog finished. Rows processed: 0, deleted: 0, updated: 0
     2022-06-08 12:05:27   state           initialized
Attributes:
   device     TYPE=SSCam
   timeOlderThan d:120
   verbose    5


Hier das Log wo nirgends in der WHERE Klausel der TYPE auftaucht:
2022.06.08 12:01:13 4: DbRep logdbRep - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history where  ( DEVICE = '^^' ) AND TIMESTAMP >= '2021-11-15 00:00:00' AND TIMESTAMP <= '2022-02-09 00:59:59' ORDER BY TIMESTAMP ASC;


Hat jemand eine Idee wo mein Fehler liegen kann?

Danke
Grüße Bernhard

DS_Starter

Hallo Bernhard,

Zitat
Hier das Log wo nirgends in der WHERE Klausel der TYPE auftaucht:
Wird auch nicht auftauchen weil TYPE ein FHEM Schlüssel ist mit dem die DB nichts anfangen kann.
TYPE ist ein FHEM devspec (http://fhem.de/commandref_DE.html#devspec) und wird durch FHEM aufgelöst bzw. übergibt die identifizierten Devices an die Datenbank.

Wenn TYPE aufgelöst werden kann, würde im Statement auftauchen ".... where  ( DEVICE in  <devs> ) .." wobei <devs> die durch FHEM aufgelösten devices sind.

Was ist denn die Ausgabe von


list TYPE=SSCam


in der Browser Kommandozeile ?

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

juniormajor

Hallo Heiko,

danke für Info - da bin ich dann auf dem Holzweg unterwegs gewesen. Damit erübrigt sich aber auch meine weitere Frage,
da es mir auch darum ging, dass DbRep im Zuge eines reduceLogs auch "fremde" (also nicht in FHEM bekannte) Geräte bzw. deren Datensätze berücksichtigt.

lG,
Bernhard

DS_Starter

Zitat
Damit erübrigt sich aber auch meine weitere Frage,
da es mir auch darum ging, dass DbRep im Zuge eines reduceLogs auch "fremde" (also nicht in FHEM bekannte) Geräte bzw. deren Datensätze berücksichtigt.
Das geht schon, nur mußt du dann diese Geräte im Attr devices explizit benennen weil FHEM sie nicht ausflösen kann.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter