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

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

Vorheriges Thema - Nächstes Thema

oldscout

Hallo,
also nachträglich wurde nichts importiert.
Hier das Reading:
timestamp_oldest_dataset   2018-10-06 19:55:52
das ist m.E. falsch, das älteste Datum für dieses Device ist der 23.3.18 laut MySQL Workbench.

set dbrep sqlCmd select TIMESTAMP from history limit 1; ergibt: auch den 6.10.18, im Workbench jedoch 23.3.18

Ich mache wöchentlich ein configdb reorg, das war auch am 6.10.18 das letzte Mail.

Mich irritiert die Zeile:
SQL execute: SELECT COUNT(*) FROM history where DEVICE = 'var_Z1' AND TIMESTAMP >= '2018-10-06 18:51:10' AND TIMESTAMP <= '2018-10-09 07:05:29' ;

Ich  habe doch nur das Attribut timeOlder Than gesetzt und trotzdem gibt es die Zeitspanne von bis ??

Heute früh:
ich habe nochmal ein neues DBrep Device angelegt, gleiches device im Attribut, folgender Fehler kommt:

Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbRep.pm line 1464.

Die bereits angelegten Devices mit DbRep funktionieren aber noch!!!

Ist das ev. die Ursache??

Dieser Fehler kommt auch in der Modulversion 17377 vom 20.9.18

Habe eben auch nochmal ein bereits definiertes Device gecheckt:
Sobald timeOlderThan gesetzt ist, wird falsch gezählt, ist das Attribut gelöscht stimmt der Zähler mit Workbench überein.

Gruß




FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

JoeALLb

Servus,

Zitat von: oldscout am 11 Oktober 2018, 06:55:42
set dbrep sqlCmd select TIMESTAMP from history limit 1; ergibt: auch den 6.10.18, im Workbench jedoch 23.3.18

Es fehlt das Ergebnis von
set dbrep sqlCmd select TIMESTAMP from history order by timestamp limit 1;
Kannst Du das bitte noch schicken?

configDb ist eine andere Datenbank, also unabhängig.


sG Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#812
ZitatHeute früh:
ich habe nochmal ein neues DBrep Device angelegt, gleiches device im Attribut, folgender Fehler kommt:

Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbRep.pm line 1464.

Die bereits angelegten Devices mit DbRep funktionieren aber noch!!!

Ist das ev. die Ursache??

Nein, das sind zwei paar Schuhe.
Dieser Fehler kommt wenn das DbLog Device noch nicht geladen ist, aber schon dbrep. die startreihenfolge wird normalerweise durch die fhem.cfg vorgegeben. Ich weiss nicht wie configdb dies sicherstellt.
Insbesondere wenn ein configdb reorg durchgeführt wird.
Allerdings gibt es mir zu denken dass der letzte reorg genau auf dieses datum fällt. Benutzt configdb dieselbe Datenbank (andere Tabellen natürlich) ?
Ich werde versuchen dbrep unempfindlich gegenüber diesem problem zu machen, wobei es nur ein hilfreicher workaround sein kann ... die startreihenfolge sollte eingehalten werden.

EDIT: das gleiche Problem tritt auf wenn man sich bei der Angabe des DbLog Device im DEF verschreibt. Bitte nochmal checken !

ZitatHabe eben auch nochmal ein bereits definiertes Device gecheckt:
Sobald timeOlderThan gesetzt ist, wird falsch gezählt, ist das Attribut gelöscht stimmt der Zähler mit Workbench überein.
Das hängt mit der falschen Ermittlung des min timestamps zusammen.

deswegen bitte das Statement ausführen wie von Joe geschrieben und das Ergebnis posten !

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

oldscout

Hallo,
hier das Ergebnis von
set dbrep sqlCmd select TIMESTAMP from history order by timestamp limit 1;

SQLResultRow_1: 2018-03-23 00:00:13

Entspricht also dem Datum von der Workbench.

Danke für Eure Unterstützung bisher.
FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

DS_Starter

Das entspricht jetzt meinen Erwartungen.
Ich hatte die Erweiterung bereits ins Modul eingebaut und eingecheckt. Wenn du jetzt ein update machen würdest, wäre dieses problem und deine fehlerhaften Zählungen beseitigt.

Sag mal Bescheid ...
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

oldscout

Hallo,
es funktionert wieder, auch andere bereits definierte zählen bzw. löschen wieder korrekt. Die Initialisierung nach dem Neustart dauert aber nun wesentlich länger.... aber damit kann man sicher leben.
Was aber nach wie vor noch nicht geht, ist die Neuanlage eines DbRep-Devices wie schon beschrieben.
Frage nebenbei: wird die fhem.cfg noch benutzt obwohl fhem auf DBLog umgestellt ist?
Bezug hierauf:
ZitatNein, das sind zwei paar Schuhe.
Dieser Fehler kommt wenn das DbLog Device noch nicht geladen ist, aber schon dbrep. die startreihenfolge wird normalerweise durch die fhem.cfg vorgegeben. Ich weiss nicht wie configdb dies sicherstellt.
Danke.
FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

JoeALLb

Heiko, reicht es nicht, beim Start der Aktion den ältesten Datensatz zu ermitteln, und nicht schon  beim Start von FHEM?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Ja, die Initialisierung beim Neustart war eigentlich der Grund weshalb ich das Statement mal abgeändert hatte, aber hier geht Zuverlässigkeit vor Schnelligkeit. Ist ja ohnehin non-blocking.

Sehr schön ...

ZitatFrage nebenbei: wird die fhem.cfg noch benutzt obwohl fhem auf DBLog umgestellt ist?
Dblog hat damit nichts zu tun. du meinst sicherlich configdb. dann wird die fhem.cfg nicht mehr genutzt.

Wegen der Neuanlage ... funktioniert denn das Kopieren eines dbrep auf ein neues ?
Trotz des Fehlers wird das device angelegt ?
ist die im DEF benannte DbLog Device online ?


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

ZitatHeiko, reicht es nicht, beim Start der Aktion den ältesten Datensatz zu ermitteln, und nicht schon  beim Start von FHEM

Leider ist das modultechnisch nicht umsetzbar ohne komplexe umbauten vornehmen zu müssen. Andere Variante wäre wieder auf meine ursprüngliche Verwendung der festen Größe 1970 als Start zurück zu gehen. Und das ist/war aus anderen Gründen wieder ungünstig.
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

#819
@Joe, was ich mir allerdings vorstellen könnte ist ein, sagen wir Qickstart Attribut anzubieten, weches der Advanced User verwenden kann.

Habe noch etwas recherchiert ... allgemein wird empfohlen auf min() statt auf "order by" zu gehen bzgl. der Performance.
Das werdecich dann nochmal anpassen.
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

JoeALLb

Oder eine Art Funktion, die "reload cache" heist, und dabei den minimalen Timestamp erneut ermittelt. das könnte dann ja in ein internal oder vielleicht auch in ein Attribut geschrieben werden. Bei einem define könnte dieser Wert ja auch einmalig erzeugt werden, oder?
Würde es Sinn machen, wenn diese Funktion auch andere Daten vorab cached? zB die Datenbanksettings?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

So eine Funktion gibt es intern ja schon und der min timestamp wird in einen helper geschrieben und immer wieder verwendet. diese funktion wird auch beim get minTimestamp aufgerufen, was deinem reload cache entsprechen würde.
Und du hast recht, die Speicherung anderer db-werte wie Spaltenbreite etc. habe ich schon auf meiner todo.  ;)

Hmm ... müssen wir nochmal drüber nachdenken.
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

Als ich jetzt nach Hause gefahren bin, kam mir doch noch eine Idee wie ich vielleicht die Ermittlung des MinTS von der Startsequenz entkoppeln könnte und dabei noch die Vorraussetzungen für die weiteren Ziele schaffen könnte.  ;)

Ich programmiere mal etwas und dann schauen wir uns das an ...

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

oldscout

Hallo,
kopieren eines dbRep Dev funktioniert.
Bei der Neuanlage kommt erst initialized, sobald das device attribut gesetzt wird kommt der Fehler.
Gruss
FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

DS_Starter

Zitatsobald das device attribut gesetzt ....

Das Attribut "device" ... wirklich ? 
Habe ich bei mir gemacht und funktioniert einwandfrei.

Mach mir mal bitte ein list von einem neuen initial angelegten DbRep-Device.
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