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

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

Vorheriges Thema - Nächstes Thema

flummy1978

Holla,

Zitat von: DS_Starter am 21 März 2020, 12:53:58
Es gibt nur innerhalb des Programmablaufs eine Logik die mit den time.*-Attributen arbeitet. Die 120:150 übertseuern die Attribute wie gewollt, soweit so gut. Nur wenn keine Zeitattribute gesetzt sind, gibt auch nichts zu übersteuern ... Rest kannst du dir denken ...  ;)
Ich korrigiere das gerade ...

Ok mit der Erklärung macht es Sinn, warum das Ding dann abstürzt, wenn die Kontrolle der Attribute nicht abgefangen wird  :D
Jetzt ist die Verwirrung auch schon wieder weg und macht direkt einen Vorschlag draus (der vielleicht mehr Arbeit macht) :

Wäre es von der Ablaufstruktur des Modules nicht vielleicht sinnvoller erst zu kontrollieren ob time.* Attribute ODER xx:yy eingegeben wurde und dann entsprechend zu überspringen ?
Alternativ wäre ein Befehl alá "ReducelLogManuell" ja auch vielleicht eine Idee. Dann musst Du nie an Deine vorhandene Struktur ran, wenn sich am ReduceLog was ändert wie zuletzt mit den time* device und reading angaben
Nur so meine 2Cent Ideen  ;)

Vielen Dank für die schnelle Umsetzung und btw:
Hab die o.g. Attribute eingesetzt und mit verschiedenen Tagen gebastelt ... funktioniert einwandfrei.

Grüße
Andreas


DS_Starter

#1036
Hallo Andreas, @all,

im contrib gibt es eine neue Version.

Was ist neu:

* bugfix der von Andreas gemeldeten Problematik wenn die Timeoptionen verwendet werden aber kein time.*-Attribut gesetzt
   ist

* bei diversen sqlCmd bzw. sqlSpecial Commands werden durch die SQL-Ergebnisse Headerdaten erzeugt. Die werden jetzt
   auch mit ausgegeben

* den letzten SQL von Christian habe ich als sqlSpecial diffBetweenValuesOfReading readingsDifferenceByTimeDelta etwas abweichend für MySQL
   implementiert. Die Zeitgrenzen der Auswertung werden der gesetzten time.*-Attribute entnommen. Die Attribute
   device/reading wie gehabt. Die Precision habe ich auch hochgesetzt, damit man auch kleine 0.xxx Werte vergleichen kann.

Ich habe readingsDifferenceByTimeDelta erstmal nur für MySQL implementiert. Für SQLite und Postgre muss die Syntax erst noch übersetzt werden.
Wenn ein SQLite / Postgre -Spezi mir einen Vorschlag zuliefern könnte würde ich mich freuen.  :)

@Andeas ... danke fürs mitdenken.  :)  Aber meine Problembeschreibung oben war schon etwas stark vereinfacht. Es gibt bereits entsprechend etablierte (und verzahnte!) Strukturen im Modul. Diese Abhängigkeiten entsprechend aufzulösen war nicht sehr schwer, ich musste mich dessen nur erstmal bewusst werden. War bei meinen Test nicht drauf gestoßen weil die time.*-Attr immer gesetzt waren.

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

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

DS_Starter

@Christian ... habe deinen Vorschlag jetzt erst gesehen. Gefällt mir aber besser als mein verwendeter Name und habe ihn schon übernommen.
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

baumix

Moin zusammen,

irgendwas ist bei einem der letzten offiziellen Updates kaputt gegangen, das Löschen alter Einträge wirft einen Fehler:

Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !

Hier mal ein List des dbrep-Devices, was bis vor 14 Tage noch funktioniert hat:

Internals:
   DATABASE   fhemdb
   DEF        logdb
   FUUID      5c729a24-f33f-dfd6-1187-471cb684065376b3
   FVERSION   93_DbRep.pm:v8.38.0-s21473/2020-03-21
   LASTCMD    delEntries 1000
   MODEL      Client
   NAME       dbrep.deleteoldentries
   NOTIFYDEV  global,dbrep.deleteoldentries
   NR         210
   NTFY_ORDER 50-dbrep.deleteoldentries
   ROLE       Client
   STATE      Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     GRANTS     SELECT,INDEX,INSERT,CREATE,TRIGGER,EXECUTE,FILE,ALTER,UPDATE,SHOW VIEW,CREATE VIEW,CREATE TEMPORARY TABLES,DROP,DELETE,EVENT,CREATE ROUTINE,ALTER ROUTINE
     IDRETRIES  3
     MINTS      2018-07-26 21:55:41
     PACKAGE    main
     SQLHIST   
     VERSION    8.38.0
     CV:
       aggregation no
       aggsec     1
       destr      2017-06-25
       dsstr      2018-07-26
       epoch_seconds_end 1498379517
       mestr      06
       msstr      07
       testr      10:31:57
       tsstr      21:55:41
       wdadd      345600
       yestr      2017
       ysstr      2018
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     DELENTRIES:
       dbrep.deleteoldentries
       delEntries
       1000
   OLDREADINGS:
   READINGS:
     2020-03-22 10:31:58   state           Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !
Attributes:
   alias      DBRep Device zum Löschen alter Einträge
   allowDeletion 1
   event-on-update-reading state
   icon       security
   room       92_Database
   showproctime 1
   timeOlderThan y:2
   timeout    86400


Im Normalfall wird das einfach per Zeitsteuerung so aufgerufen:

set dbrep.deleteoldentries delEntries

Das Attribut timeOlderThan ist ja auf  y:2 gesetzt. Nachdem das aber so nicht mehr ging, habe ich nun auch mal mit

set dbrep.deleteoldentries delEntries 1000

versucht, kommt aber der gleiche Fehler ... habe ich eine notwendige Änderung übersehen?

Grüße und bleibt gesund
Baumix


DS_Starter

#1039
Hallo Baumix,

ich vermute das Modul hat recht.  :)

Dein ältester Datensatz in der DB ist

MINTS      2018-07-26 21:55:41

d.h. jünger als zwei Jahre. Dieser Timestamp wird implizit verwendet als timediffToNow (d.h. newer than) falls das Attribut timediffToNow  nicht gesetzt ist (war schon immer so).
Das gleiche gilt für

set dbrep.deleteoldentries delEntries 1000

Hier sollen Daten älter als 1000 Tage gelöscht werden.

Neu ist, dass ich durch die Einführung der möglichen Optionsangabe bei delEntries und reduceLog eine schärfere Prüfung implementiert habe, die deine etwas unglückliche Konfig ans Licht bringt.
Momentan löscht du ja in deiner DB nichts ...

Wenn du verbose 4 einschaltest, sieht man die Zusammenhänge recht gut im Log. Kannst du ja mal machen und posten. Aber ich denke es ist so wie beschrieben.

Du kannst es auch so prüfen:

set dbrep.deleteoldentries delEntries 1000:1010

Dadurch wird timediffToNow (= newer than) explizit auf 1010 Tage gesetzt und überschreibt MINTS. Damit wird es dann funktionieren.

Ebenfalls wird es funktionieren, wenn du zuätzlich

timediffToNow  y:3

setzt. Auch in diesem Fall ist die Forderung erfüllt.

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

baumix

Hallo Heiko,

Zitat von: DS_Starter am 22 März 2020, 12:04:15
ich vermute das Modul hat recht.  :)

Naja, hat es  ;)

ZitatDein ältester Datensatz in der DB ist

MINTS      2018-07-26 21:55:41

d.h. jünger als zwei Jahre. Dieser Timestamp wird implizit verwendet als timediffToNow (d.h. newer than) falls das Attribut timediffToNow  nicht gesetzt ist (war schon immer so).

Tja, auf MINTS hatte ich tatsächlich nicht geachtet und ich war der festen Überzeugung, dass Einträge durch das Löschen aus der Datenbank fliegen ... war aber wohl nur delSeqDoublets und Konsorten ... ist ja auch ein Löschen ...

ZitatEbenfalls wird es funktionieren, wenn du zuätzlich

timediffToNow  y:3

setzt. Auch in diesem Fall ist die Forderung erfüllt.

Jepp, das hat funktioniert und ich habe sogar verstanden, warum ... war wohl meine Konfig von Anfang an kaputt, ist nur jetzt erst aufgefallen  ;D
Danke für die schnelle Hilfe!

Grüße
Baumix

flummy1978

Hallo Heiko,

ich muss nochmal meine Idee aufgreifen, die ich die Tage schon mal erwähnt habe:

Zitat von: flummy1978 am 20 März 2020, 00:23:12
Meine Idee wäre dann 1-7 Tage mit ungefilterten Werten arbeiten (anzeigen)
Der 5 und 30 Minuten Schnitt wird "live" von der DB erzeugt
Livedaten werden alle 7-x Tage mit Reduce Log dann auf Stunden Schnitt verringert und die 5-30 Minuten Schnittwerte sind ja immernoch vorhanden

ich hab jetzt ein wenig mit AverageValue rumgespielt, allerdings bin ich nicht so wirklich "zufrieden" mit dem Ergebnis. Ich versuche mal zu erklären, was ich gerne machen möchte. Vielleicht ist meine Herangehensweise aber auch vollkommener Blödsinn:

Ich habe ein Wettermodul, das mir sowohl Windgeschwindigkeit als auch Böen als Wert liefert. Da ich das Ganze als Schutz für eine Markise benötige, sind für mich die Böen wichtiger, als die normale Windgeschwindigkeit. Wenn ich jetzt allerdings normale Böen-Werte mitlogge habe ich ständig Sprünge von +4 -> 0 -> +4 ->  -> 0 usw .... teilweise nach einer Std (was ok ist) teilweise aber auch innerhalb von wenigen Sekunden.

Nun war meine Idee hier, ein at zu aktivieren, das immerwieder die Funktion averageValue aufruft und einen Schnitt der Böen über meinetwegen 30 Minuten erstellt. Diesen dann in die DB speichert und die alten Werte löscht. Den Durchschnitt berechnen und alles eintragen lassen, bekomme ich hin. Genauso wie ich nach einer gewissen Zeit dann auch die Einträge einfach löschen kann. Allerdings erfüllt die Funktion "WriteToDB[Single]" leider nicht das, was ich an der Stelle erwartet habe:
Der Wert wird nicht an die Stelle geschrieben, an der die Messung begonnen hat (in meinem Fall also JETZT bis JETZT -30 Min) sondern am ende des heutigen Tages. Das wäre für diese Funktion doch sehr unglücklich......
Im Endeffekt wäre diese Funktion doch dann im Prinzip das Gleiche wie "ReduceLog" nur zusätzlich mit Optionen anderen zeitraum als Schnitt zu nehmen, als nur Day oder Stunde - Aber Eintragen geht nur "Day" Grenze ???

Hab ich jetzt hier einen kompletten Denkfehler, oder ..... ?

Alternativ wäre (für mein Vorhaben) und für viele andere Möglichkeiten die mir grad so einfallen, auch der ReduceLog Befehl perfekt dafür, wenn man hier noch die Optionen hätte zwischen
ReduceLog average blubla ReduceLog average=day blubla zusätzlich auch die Mögichkeit hätte von ReduceLog average=30min blubla oder ReduceLog average=1800sek blubla oder oder oder ....

Bin mal gespannt was die Anregung dazu sagt ....  8)

Viele Grüße
Andreas

DS_Starter

Morgen Andreas,

die Anregung weitere Aggregationen bei reduceLog anzubieten gab es schon mal. Ich würde das auch gerne machen, war bisher aber an der dann doch hohen Komplexität gescheitert (oder war nicht zielstrebig genug  ;) ).

Was aber vermutlich relativ gut machbar wäre, das WriteToDB[Single] so zu erweitern, dass die Auswertungszeitraumgrenzen mit berücksichtigt werden.
Ich probiere mal was und melde mich wieder ...

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

flummy1978

Guten Morgen die Damen (und Herren),

Zitat von: DS_Starter am 27 März 2020, 09:04:09
die Anregung weitere Aggregationen bei reduceLog anzubieten gab es schon mal. Ich würde das auch gerne machen, war bisher aber an der dann doch hohen Komplexität gescheitert (oder war nicht zielstrebig genug  ;) ).

Ich probiere mal was und melde mich wieder ...

Ich habe mir den betroffenen teil im Modul mit meinen bescheidenen Kentnissen angeschaut.... Kein Wunder, dass Dir bei sowas irgendwann mal der Kopf raucht  ;D
Wenn es kompletter Blödsinn ist, ignoriere es bitte schnell wieder. Ich hatte schon länger nicht mehr komplexer mit DBs zu tun - Perl in Verbindung mit DB in der Komplexität wie in Deinem Modul noch nie (selbst gebaut) ... aber vielleicht sehe ich ja einen Baum, den Du vor lauter Bäumen nicht siehst.....

8802 Log3 ($name, 4, "DbRep $name - UPDATE history SET TIMESTAMP=$updDate $updHour:30:00, EVENT='rl_av_h', VALUE=$average WHERE DEVICE=$hourHash->{$hourKey}->[1] AND READING=$hourHash->{$hourKey}->[3] AND TIMESTAMP=$hourHash->{$hourKey}->[0] AND VALUE=$hourHash->{$hourKey}->[4]->[0]");


In dem Bereich (die 5 Zeilen davor) wird der Durchschnitt errechnet richtig ?
Wäre es nicht sinnvoll an der Stelle mit den vorhanden Variablen Werten und den eingegebenen Werten (average, average=hour, average=1800(sek) usw .... ), einen Befehl wie

"SELECT Avg( VALUE ) AS 'rl_av_h[m][s]' FROM `history` WHERE `TIMESTAMP` BETWEEN '2020-03-27 08:00:00.000000' AND '2020-03-27 08:15:00.000000' AND DEVICE ....... AND READING LIKE '%humidity%' " zu generieren ?

------------Schnitt in der DB----------------------------------------------------------------------------Startzeit---------------------------------Endzeit-----------------------------------..... usw.
Die Endzeit wäre dann auch der Zeitpunkt zu dem man dann den Schnitt eintragen würde UND man könnte direkt in einem Abwasch die alten Werte löschen. (weil man ja die Veriablen Bedingungen in der gleichen Zeile genutzt hat)

Wie gesagt bitte ignorieren, wenn es kompletter Blödsinn ist  ??? Aber wenn nicht, hilft es ja vielleicht ein wenig ;)


Bitte nur keinen Stress, nur weil ICH es möchte ;)
Wenn es für andere auch hilfreich ist, wäre es natürlich toll. Für mich wäre es in diesem Fall eine sehr gute Hilfe....

Viele Grüße
Andreas

DS_Starter

Hallo Andreas, @all,

ich habe eine neue DbRep Version zum Test in mein contrib geladen.
Die Funktionen sumValue und averageValue sind nun ergänzt um die Option writeToDBInTime.
Diese Option dürfte dir schon weiterhelfen Andreas.

Die Optionen stellen nun folgende Möglichkeiten zur Verfügung:

writeToDB                : schreibt jeweils einen Wert mit den Zeitstempeln 00:00:01 und 23:59:59 innerhalb der jeweiligen Auswertungsperiode (wie bisher)
writeToDBSingle       : schreibt nur einen Wert mit dem Zeitstempel 23:59:59 am Ende einer Auswertungsperiode (wie bisher)
writeToDBInTime      : schreibt jeweils einen Wert am Anfang und am Ende der Zeitgrenzen einer Auswertungsperiode

Die Möglichkeiten bzgl. reduceLog schaue ich mir auch noch an. Vllt. kann ich dem User dort noch eine flexible Aggregationsmöglichkeit bieten, mal schauen. Vorher will ich mir allerdings die etwas weiter vorn schon erwähnte Möglichkeit des direkten Übertragens von Ergebnissen in ein Reading anschauen und ggf. umsetzen.

Download:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Wie immer freue ich mich um Testergebnisse, Meinungen anderer Anwender.  :)

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

flummy1978

Hallöchen,

Zitat von: DS_Starter am 28 März 2020, 21:07:38
ich habe eine neue DbRep Version zum Test in mein contrib geladen.
Die Funktionen sumValue und averageValue sind nun ergänzt um die Option writeToDBInTime.
(Für mich) absolut perfekt. Macht genau das was es tun soll inkl. richtigem Zeitpunkt. Aktuell läuft es automatisch mit einem at alle 10 Min aber auch die 60-90 Min Tests mit "display" Ausgabe waren erfolgreich  :) *thumbsup*

Für mich dennoch immernoch sehr interessant: Gibt es eine Möglichkeit die Funktionen die Du dort nutzt (egal ob reduceLog, delEntries oder auch delSeqDoublets), irgendwie "hintenrum" (direkter Perl Befehl oder sonst etwas) mit entsprechenden Variablen zu übergeben,ohne dafür jedes mal ein neues DBRep Device zu nutzen ?
Ich frag einfach aus dem Grund, weil ich das für viele andere Sachen gern nutzuen würde (auch ältere Daten), wo ich dann aus dem Device heraus sowas aufrufen kann und nicht für jede Abfrage ein extra DBRep device brauche.

Dann nochmal eine ganz andere Frage:
Zitat von: DS_Starter am 16 März 2020, 11:38:10
..... Allerdings kannst du das alles mit nur  einem at Device antriggern. Stichwort heisst Chain mit den Attribut executeAfterProc.
Das habe ich probiert und in dem DBRep Device, das den neuen Befehl alle 10 Min ausführen soll, ein
attr DBrep_Wetter_windgust executeAfterProc set DBrep_Wetter_windgust delEntries
hinzugefügt.
Dummerweise führt er dann diesen Befehl nicht einmal aus, sondern ständig. Ich denke mal es liegt daran, dass ich das gleiche Device aufrufen wie das, das den Befehl "executeAfterProc" beinhaltet und mir damit ungewollt eine Endlosschleife bastele. Ich weiss nicht ob das übersehen habe, oder das nirgendwo erwähnt wird. Vielleicht wäre es eine Idee, das mit in die Doku aufzunehmen.
(Mit executebeforeProc isses noch schlimmer, weil man nichts anderes mehr ausgeführt wird, da gibts dann nur noch den bösen kill ;) )
Hast Du (oder jemand anders) n Tipp für mich, wie ich das umgehen / lösen kann ?

Da du auf meine Vorschlag nicht eingegangen bist, geh ich mal davon aus, dass es vollkommener Blödsinn war was ich gefunden / mir gedacht habe?  ::) :P

Auf jeden Fall vielen herzlichen Dank für die schnelle / geniale Umsetzung

Viele Grüße
Andreas

DS_Starter

Hallo Andreas,

ich fange mal hinten an ...

ZitatDa du auf meine Vorschlag nicht eingegangen bist, geh ich mal davon aus, dass es vollkommener Blödsinn war was ich gefunden / mir gedacht habe?  ::)
Ganz und garnicht. Ich arbeite nur meinen Plan schrittweise ab. Das kommt noch dran. Momentan bin ich dabei die automatische Übertragung von Readings in andere Devices zu implementieren.

ZitatDummerweise führt er dann diesen Befehl nicht einmal aus, sondern ständig. Ich denke mal es liegt daran, dass ich das gleiche Device aufrufen wie das, das den Befehl "executeAfterProc" beinhaltet und mir damit ungewollt eine Endlosschleife bastele.
Das ist richtig. Naja, ich dachte es ist relativ klar dass man sich nicht immer selbst aufrufen sollte.  ;)  Im Wiki-Beispiel habe ich auch geschriebendass man 4 verschiedene DbReps anlegt/kopiert ... Aber ich hebe es nochmal hervor  :)

ZitatFür mich dennoch immernoch sehr interessant: Gibt es eine Möglichkeit die Funktionen die Du dort nutzt (egal ob reduceLog, delEntries oder auch delSeqDoublets), irgendwie "hintenrum" (direkter Perl Befehl oder sonst etwas) mit entsprechenden Variablen zu übergeben,ohne dafür jedes mal ein neues DBRep Device zu nutzen ?
Das kann so pauschal nicht beantwortet werden. Wenn es reines SQL ist, kannst du es einem Rep mit sqlCmd übergeben. Kann natürlich immer ein anderes Statement sein.
Ansonsten kann man sich das anschauen wenn du mal ein ganz konkretes Beispiel / Aufgabe hast du du lösen möchtest. Es greift vieles ineinander, zum Beispiel auch die non-Blocking Implementierung. Die müstest du nachbauen. Meist kommt dann eins zu anderem. Ich glaube ich habe über 100 Devices ...

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

flummy1978

#1047
Hey,

vielen Dank für die schnelle Antwort :)
ob Du auf meinen Vorschlag eingehst oder nicht, war jetzt nicht so wichtig. Ich war in der Hinsicht nur neugierig, ob ich da mal was richtig erkannt habe oder ob es wirklich vollkommener Blödsinn war ;)  Vielleicht erfahr ich das ja dann später, wenn das an der Reihe ist.

Zitat von: DS_Starter am 29 März 2020, 17:48:37
Ich glaube ich habe über 100 Devices ...
:o Das erklärt einiges  :-\  (Nein es ist sicherlich nicht schlecht - siehe Erklärung, aber für mich "Neuland")

Als ich mich angefangen habe mit FHEM zu beschäftigen, haben mich immer Config Übersichten, die 500 Geräte (davon 400 Dummys) total abgeschreckt, weil es einfach nicht nachvollziehbar war. Wenn sich ein virt_Geräte sich im Hintergrund um 20 reale Geräte kümmert, ist es auch nicht immer übersichtlich aber leichter nachzuvollziehen. In diesem Fall wäre das so, dass sich ein Gerät um die Datenbank in Verbindung mit Wetterdaten kümmern soll, eines um Stromverbrauchsdaten und eines um das "normale" Aufräumen. Hier wäre es eben von Nöten verschiedene Befehle mit verschiedenen Attributen / Optionen in dem jeweiligen Device aufzurufen.  Ich müsste alternativ eben für jede Abfrage / korrektur oder sonst etwas jeweils ein neues Gerät erstellen.

Ich versuche einfach mit so wenig verschiedenen Geräten auszukommen wie möglich, damit innerhalb von Fhem eine Übersicht bleibt.
Automatische Timer / Verzögerung für Bewegungsmelder oder Benachrichtigung / Auto-on-for-Timer für Geräte die bestimmte Attribute haben sind 2 Beispiele, die ich hier schon im Forum vorgestellt habe.

Vielleicht ist es aber auch so, dass ich da (noch) keine gescheite Idee für eine GUTE Struktur habe um eben NICHT die Übersicht zu verlieren, auch wenn es alleine von einem Type 100 Devices gibt Wenn Du mal Lust und Laune haben solltest, würde mich ein Auszug aus Deiner Config bzw die Übersicht der einzelnen Devices interessieren :)

Edith trägt noch etwas nach: Wenn man das Device alle 10 Min ausführt, gibts n volles Log Gibt es eine Möglichkeit das im Log zu unterbinden (und dennoch nicht unbedingt gravierende Fehler zu übersehen?)
2020.03.30 03:34:15.305 3: DbRep DBrep_Wetter_windgust - number of lines updated in "DBLogging": 1
2020.03.30 03:34:15.306 3: DbRep DBrep_Wetter_windgust - number of lines inserted into "DBLogging": 1


Viele Grüße
Andreas

kadettilac89

Hallo Heiko,

ich habe im Log folgende Meldung ... PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 67142) line 1.

Modul: # $Id: 93_DbRep.pm 21473 2020-03-21 21:09:33Z DS_Starter $

Kann man da was dagegen tun? Kennst du die Meldung schon? :)

Befehl:
set myDbRep exportToFile;

Danke

List des Devices:

Internals:
   DATABASE   fhem
   DEF        myDbLog
   FUUID      5c575e19-f33f-4fe4-eeb6-712d9409654163f4
   FVERSION   93_DbRep.pm:v8.38.0-s21473/2020-03-21
   LASTCMD    exportToFile
   MODEL      Client
   NAME       myDbRep
   NOTIFYDEV  global,myDbRep
   NR         506
   NTFY_ORDER 50-myDbRep
   ROLE       Client
   STATE      done » ProcTime:  sec
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE myDbLog
     GRANTS     CREATE ROUTINE,CREATE TEMPORARY TABLES,REFERENCES,CREATE VIEW,SHOW VIEW,USAGE,INDEX,EXECUTE,UPDATE,EVENT,TRIGGER,LOCK TABLES,ALTER,DROP,CREATE,SELECT,INSERT,DELETE,ALTER ROUTINE
     IDRETRIES  3
     MINTS      2014-06-09 09:32:12
     PACKAGE    main
     VERSION    8.38.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-03-30
       dsstr      2020-03-30
       epoch_seconds_end 1585557228
       mestr      03
       msstr      03
       testr      10:33:48
       tsstr      08:33:47
       wdadd      604800
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2020-03-30 10:33:48   state           done
Attributes:
   device     .*
   dumpCompress 1
   dumpDirLocal /opt/fhem/backup/db/
   event-on-change-reading .*
   expimpfile /opt/fhem/backup/db/%Y%m%d_%T.csv
   group      DB-Log
   optimizeTablesBeforeDump 1
   room       Server
   stateFormat { ReadingsVal($name,"state", undef) eq "running" ? "renaming" : ReadingsVal($name,"state", undef). " » ProcTime: ".ReadingsVal($name,"sql_processing_time", undef)." sec"}
   timeDiffToNow h:2


Stacktrace:


2020.03.30 10:29:53.775 1:     main::CallFn                        called by fhem.pl (757)
2020.03.30 10:29:53.775 1:     main::telnet_Read                   called by fhem.pl (3772)
2020.03.30 10:29:53.775 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2020.03.30 10:29:53.775 1:     main::AnalyzeCommand                called by fhem.pl (1100)
2020.03.30 10:29:53.775 1:     main::AnalyzePerlCommand            called by fhem.pl (1171)
2020.03.30 10:29:53.775 1:     (eval)                              called by fhem.pl (1146)
2020.03.30 10:29:53.774 1:     main::expfile_ParseDone             called by (eval 66785) (1)
2020.03.30 10:29:53.774 1:     main::readingsEndUpdate             called by ./FHEM/93_DbRep.pm (5895)
2020.03.30 10:29:53.774 1:     main::evalStateFormat               called by fhem.pl (4748)
2020.03.30 10:29:53.774 1:     (eval)                              called by fhem.pl (4645)
2020.03.30 10:29:53.774 1:     main::__ANON__                      called by (eval 66786) (1)
2020.03.30 10:29:53.774 1: stacktrace:
2020.03.30 10:29:53.774 1: eval: {expfile_ParseDone('myDbRep|568|0.01366,0.016039|0|.*|%|/opt/fhem/backup/db/20200330_10:29:53.csv')}
2020.03.30 10:29:53.774 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 66786) line 1.

DS_Starter

#1049
Moin zusammen,

im contrib gibt es nun eine erweiterte Version 8.40.0.
Mit dieser Version ist es nun möglich DbRep-Ergebnisse automatisch in andere Devices (z.B. dummy) zu übertragen.
Dafür gibt es das Attribut autoForward.

Auszug:

* autoForward - wenn aktiviert, werden die Ergebnisreadings einer Funktion in ein oder mehrere Devices übertragen.
Die Definition erfolgt in der Form:

{
  "<source-reading> => "<dest.device> [=> <dest.-reading>]",
  "<source-reading> => "<dest.device> [=> <dest.-reading>]",
  ...
}                               
                             

In der Angabe <source-reading> sind Wildcards (.*) erlaubt.

    Beispiel:

    {
      ".*"               => "Dum.Rep.All",             
      ".*AVGAM.*"  => "Dum.Rep     => average", 
      ".*SUM.*"      => "Dum.Rep.Sum => summary",
    } 
    # alle Readings werden zum Device "Dum.Rep.All" übertragen, Readingname bleibt im Ziel erhalten
    # Readings mit "AVGAM" im Namen werden zum Device "Dum.Rep" in das Reading "average" übertragen
    # Readings mit "SUM" im Namen werden zum Device "Dum.Rep.Sum" in das Reading "summary" übertragen

Wiki ergänze ich noch.

@Andreas ... verbose 2 einstellen. Kritische Meldungen erstelle ich im Modul immer mit verbose 2 oder 1.

@kadettilac89 ... Hmm, kannte ich noch nicht und kommt bei mir auch nicht. Habe eine Weile auf den Code geschaut und kam momentan noch nicht dahinter. Vermutung: du verwendest in deinem stateFormat eine Auswertung des Readings sql_processing_time, erzeugst es aber nicht. D.h. die angegebene Verknüpfung sollte auf jeden Fall eine Warnung werfen.

Edit: @Andreas ... ich habe 126 DbRep-Devs. Habe mit jsonlist2 eine Übersicht erzeugt. Das ist ganz schön viel. Was interessiert dich daran bzw. wozu brauchst du das?

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