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

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

Vorheriges Thema - Nächstes Thema

JoeALLb

Wow, vielen Dank, das klingt großartig!!!
Werds heute Abend testen, wenn ich zuhause bin!


Zitat von: DS_Starter am 10 Dezember 2016, 13:26:05
Diese Verfahren stellt m.M. nach sicher dass mathematisch nichts "verloren" geht. Vom logischen Standpunkt ist es natürlich nicht unbedingt schlüssig da der Verbrauch ja eher zwischen dem 02.11. und 30.11 anfiel. Vielleicht kriege ich das noch besser geregelt, mal schauen.

Ist denke ich schon ok, ersteres ist im Moment wichtiger als letzteres.... denn wenn mir das nicht gefällt, kann ich ja (zumindest einstweilen) mir selbst noch einen
Zwischen-Wert ausrechnen, der das Ergebnis dann besser "verteilt". Danke in diesem Zusammenhang auch für deine "insert" funktion!


Danke Heiko,
schöne Grüße 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

JoeALLb

Hm, konnte es doch schon jetzt testen (erstaunlich, was manchmal am handy alles so klappt).

Ivh bekomme nun öfter Minuseinträge, so wie in diesem Beispiel.
2012-07-01__stromverbrauch__2012-07 11400.9000
2016-12-10 13:49:33 2012-08-01__stromverbrauch__2012-01 -11400.9000


Ich wollte das jetzt nur melden, die genauen Daten dazu muss ich mir tatsächlich später ansehen, aber eigentlich sollte die DIFF-Funktion ja nie negativ werden, oder?
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

Hi Joe,

Zitataber eigentlich sollte die DIFF-Funktion ja nie negativ werden, oder?

nee, sollte nicht.

Wie gesagt ... erstmal testen und zusammentragen. Dann korrigieren wir wieder bis es richtig klappt.

Bis später ...
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

DS_Starter

Hi Joe,

ich glaube das Problem mit den negativen Diffs in der V4.8.2 (Eingang) beseitigt zu haben.
Habe es mit deinen Wasserdaten vom letzten Mal durchlaufen lassen.
Klappt sogar wenn nur ein Wert im Monat vorhanden ist. Warnung kommt aber noch.

Aber jetzt muß ich echt ... bis später

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

JoeALLb

Hallo Heiko,

meine Tests verliefen bisher sehr erfolgreich, vielen Dank für die Änderungen!
Mein Heizungszähler, der eigentlich recht häufig Werte liefert,  hat damit im letzten Jahr gleich 120KWh mehr angezeigt... das unterscheidet sich nur um 5 kwh von der
Ablesung, aber diese ist ja nicht am 31.12...
Ich werd das nochmals demnächst genau nachrechnen, aber ich gehe davon aus, dass dies jetzt stimmt.
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

Morgen Joe,

das hört sich gut an ... danke für die Rückmeldung.
Ich werde auch noch Tests in verschiedenen Konstellationen durchführen und das Ganze auch mal noch mit SQLite durchziehen.

Dauert aber noch bisschen ...

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

DerFrickler

aus dem Wiki:

ALTER TABLE 'fhem'.'history' ADD INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE;
oder:
CREATE INDEX Reading_Time_Idx ON `fhem`.`history` (READING, TIMESTAMP);

jetzt helft doch bitte mal einen Laien in Sachen DB weiter... worin liegt der Unterschied?

Gruß!

DS_Starter

Hallo,

macht faktisch keinen Unterschied außer in der obligatorischen Angabe eines Indexnamens ....

Zitat aus  http://stackoverflow.com/questions/17113149/what-is-the-difference-between-mysqls-create-index-and-alter-add-index  ->
What is the difference between MySQL's create index and alter add index?

Zitat
The implementation is the same on the server-side.

The only practical difference is that with ALTER TABLE, you have the option to create an index without specifying a name for the index. The server generates a default name, as the name of the first column in the index, with a number suffix if necessary.

Whereas with CREATE INDEX syntax, you must specify a name for the index.

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

DerFrickler

#263
wenn ich mit folgenden Anweisungen eine DB erstelle:

sudo sqlite3 /opt/fhem/DbLog.db

CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));

wie müsste dann die Anweisung für den INDEX aussehen?

edit:
CREATE INDEX Reading_Time_Idx ON 'history' (READING, TIMESTAMP);

DS_Starter

#264
Es kommt darauf an welche Felder der Index einschließen soll. Das hängt davon ab wie letztendlich die Abfrage der DB erfolgen soll.

Mein Beispiel:
CREATE INDEX Reading_Time_Idx ON `history` (READING, TIMESTAMP);

fügt nur die Felder READING und TIMESTAMP zu diesem Index hinzu. Dieser Index würde Abfragen der Form " Select  .... where Reading = .... AND TIMESTAMP = ..." beschleunigen.  Man könnte nun noch weitere und im Extremfall alle Felder der DB mit hinzufügen.

Um zum Beispiel Device noch mit hinzuzunehmen würde es etwa so aussehen:

CREATE INDEX Reading_Dev_Time_Idx ON `history` (READING, DEVICE, TIMESTAMP);

Entspechendes für die Tabelle "current" :

CREATE INDEX Reading_Dev_Time_Idx ON `current` (READING, DEVICE, TIMESTAMP);

Problem dabei ist dass diese Indizes Platz auf der DB benötigen der u.U. an die Größe der Daten selbst herankommen.
Ich weiß jetzt nicht was der Hintergrund deiner Frage ist, aber ich würde den Erfolg (Verringerung Laufzeit) des Indexaufbaus einfach austesten und wegen des benötigten Platzes nur Indizes erstellen die einen Performancegewinn verursachen.



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

DerFrickler

Danke erst mal für Deine Antworten.

Im Grunde überlege ich mir gerade wie ich meine DB für Logdaten am besten aufsetzte und später auch Pflege. Im Wiki zu DbRep bin ich auf den Hinweis gestossen dass aus Performancegründen ein Index erstellt werden soll. Wenn ich die DB erneut aufsetze, dann aber auch von Anfang an richtig.

Gruß!

DS_Starter

Auf MySQL kannst/willst du nicht wechseln ?
Wenn ich wählen könnte (hab ich ja) würde ich auf MySQL setzen.

Während ich mit DbRep im Entwicklungsprozess mit beiden DB-Typen teste, komme ich immer wieder zu dem Ergebnis dass MySQL performanter arbeitet.
Möglicherweise ist das auch von meiner konkreten Testumgebung abhängig, doch ist dies mein Erfahrungswert. 
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

DerFrickler

Gab es bei MySQL nicht die Einschränkung in der Länge der Device Namen?

Gruß!

DS_Starter

Ja, die gibt es. Aber es etwas entspannt weil die Länge auf 64 Zeichen im DbLog abgeändert wurde.
Da!mit kommt man gut klar denke ich.
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

Zitat von: DS_Starter am 12 Dezember 2016, 11:37:38
Ja, die gibt es. Aber es etwas entspannt weil die Länge auf 64 Zeichen im DbLog abgeändert wurde.

Und zur Not kann man die Spaltenbreite selbst bei den Tabellen noch weiter erhöhen, funktioniert bei mir bisher recht gut.
Ich habe sogar auf einem kleinen Raspi v1 eine Mysql-DB am laufen, und es klappt wunderbar.
Natürlich ist die CPU-Auslastung etwas höher als bei SQLIte, dafür ist sonst vieles um vieles angenehmer.
zB gleichzeitiger Zugriff auf die DB von fhem und vom Anwender, auswertungen, stored Procedures, ..

Ich würde hier immer wieder mysql (oder aktueller MariaDB als 1:1 Ersatz für MySQL) verwenden.

@Heiko: Bei mir läuft die VErsion gut, und da sie für mich entscheidendes verbessert, würde ich für ein Eincheckem plädieren ;-)

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