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

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

Vorheriges Thema - Nächstes Thema

DS_Starter

#270
Hallo Joe, @all,

ich habe noch etwas gefunden und mit Version 4.8.3 gefixt.
Mit dieser Version werden die Differenzüberträge auch über eine oder mehrere Leerperioden hinweg transportiert und der nächsten Aggregationsperiode die einen Wert enthält, zugeordnet.

Was ich damit meine ist an dem Beispiel erläutert.
Mit fetchrows sehen die Daten so aus:


2008-01-11_00-00-00__Manuell__Wasser   335.61   2016-12-13 17:11:18
2008-02-04_00-00-00__Manuell__Wasser   342.8   2016-12-13 17:11:18
2008-02-29_00-00-00__Manuell__Wasser   349.635   2016-12-13 17:11:18
2008-03-27_00-00-00__Manuell__Wasser   356.581   2016-12-13 17:11:18
2008-05-07_00-00-00__Manuell__Wasser   366.283   2016-12-13 17:11:18
2008-05-25_00-00-00__Manuell__Wasser   370.028   2016-12-13 17:11:18
2008-06-03_00-00-00__Manuell__Wasser   371.447   2016-12-13 17:11:18
2008-06-19_00-00-00__Manuell__Wasser   371.68   2016-12-13 17:11:18
2008-06-20_00-00-00__Manuell__Wasser   372.251   2016-12-13 17:11:18
2008-06-21_00-00-00__Manuell__Wasser   372.748   2016-12-13 17:11:18
2008-07-13_00-00-00__Manuell__Wasser   377.134   2016-12-13 17:11:18
2008-07-22_00-00-00__Manuell__Wasser   378.956   2016-12-13 17:11:18
2008-07-23_00-00-00__Manuell__Wasser   379     2016-12-13 17:11:18
2008-10-14_00-00-00__Manuell__Wasser   403.731   2016-12-13 17:11:18
2008-10-30_00-00-00__Manuell__Wasser   408.307   2016-12-13 17:11:18
2008-11-17_00-00-00__Manuell__Wasser   413.849   2016-12-13 17:11:18
2008-12-03_00-00-00__Manuell__Wasser   417.307   2016-12-13 17:11:18
2008-12-19_00-00-00__Manuell__Wasser   421.655   2016-12-13 17:11:18


Es gibt hier eine Datenlücke im April und August/September. Mit der Version 4.8.3 sieht diffValue für dieses Beispiel nun so aus:

2008-01-11_00-00-00__Manuell__Wasser__DIFF__2008-01   -           2016-12-13 17:09:52
2008-02-29_00-00-00__Manuell__Wasser__DIFF__2008-02   14.0250   2016-12-13 17:09:52
2008-03-27_00-00-00__Manuell__Wasser__DIFF__2008-03   6.9460   2016-12-13 17:09:52
2008-04-01__Manuell__Wasser__DIFF__2008-04                   -               2016-12-13 17:09:52
2008-05-25_00-00-00__Manuell__Wasser__DIFF__2008-05   13.4470   2016-12-13 17:09:52
2008-06-21_00-00-00__Manuell__Wasser__DIFF__2008-06   2.7200   2016-12-13 17:09:52
2008-07-23_00-00-00__Manuell__Wasser__DIFF__2008-07   6.2520   2016-12-13 17:09:52
2008-08-01__Manuell__Wasser__DIFF__2008-08                   -           2016-12-13 17:09:52
2008-09-01__Manuell__Wasser__DIFF__2008-09                   -           2016-12-13 17:09:52
2008-10-30_00-00-00__Manuell__Wasser__DIFF__2008-10   29.3070   2016-12-13 17:09:52
2008-11-17_00-00-00__Manuell__Wasser__DIFF__2008-11   5.5420   2016-12-13 17:09:52
2008-12-31_00-00-00__Manuell__Wasser__DIFF__2008-12   12.0220   2016-12-13 17:09:52

D.h. die Differenz zw. dem 27.03. und 25.05. wird aus 370,028 - 356,581 = 13,447 errechnet und der Aggregationsperiode 2008-05 zugeordnet (der ersten Periode mit einem Wert die auf die Leerperiode folgt).
Das gleiche funktioniert über mehrere benachbarte Leerperioden. Es gibt keinen Wert für August/September.
Hier wird die Differenz aus dem letzten Wert Oktober und dem letzten Wert Juli gebildet, also 408,307 - 379 = 29,307. Diese Diff wird wiederum der auf eine Leerperiode folgenden Aggregationsperiode (hier 2008-10) zugeordnet.

Das hat in dieser Form in V4.8.2 noch nicht funktioniert wei meine Tests gezeigt haben.

Schau(t) mal ob es auch bei euch so gut funktioniert wie bei mir.
Dann wäre ich auch für ein Check-In  :)

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

JoeALLb

Danke, ja, die KWs wurden nun nochmal etwas nach oben korrigiert!!
Sehr schön! Funktioniert 1a.
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

Wow, jetzt warst du aber schnell  :)
Ich sehe zu es heute Abend noch einzuchecken. Muß noch dokumentieren....
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

Mit der DB bin ich jetzt nach MySQL umgezogen, klappt gut und die Performance ist wirklich deutlich besser. Konsequenter weise sollte ich dann ach meine configDB mit umziehen lassen.

1. Gibt es da eine einfache Methode des Datentransfers vom sqlit3 nach MySQL?

2. Bei sqlit3 habe ich regelmässig ein VACUUM gemacht, besteht die Notwendigkeit einer Optimierung bei MySQL auch und wie erfolgt das dann bei MySQL?

3. für sqlit3 gab es die Möglichkeit mittels
attr myDbLog userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }

sich die große des DB-Files anzeigen zu lassen. Gibt es hier für MySQL auch eine Möglichkeit den Speicherbedarf der DB zu ermitteln?

Dann hatte ich folgendes Thema bereits in Beitrag zu DbLog angebracht...

Hintergrund: Ich schreibe in meine DB Daten die ich lediglich 7 Tage aufbewahre und Daten die ich über 2 Jahre aufbewahren möchte. Bei den Daten die ich 2 Jahre aufbewahren möchte handelt es sich um Zählerstände bei denen ich gerne das Vorjahr als Vergleichszeitraum haben möchte. Von der Datenmenge her würde es völlig ausreichen wenn ich 2 Datensätze pro Monat in der DB stehen hätte, da ich lediglich die Differenz bilde. Für den aktuellen Tag können es dann ruhig ein paar mehr sein, die sollten dann aber am folgenden Tag auf 2 Werte, den ersten und den letzten reduziert werden. Wie man sich jetzt vorstellen kann handelt es sich bei dem ersten Wert am Tag / Monat um den letzten Wert des Vortages / Vormonats (ich mache um 00:00:01 einen Übertrag auf den Folgetag), wodurch es prinzipiell auch ausreichen würde den letzten Wert des Tages / Monats in der DB stehen zu haben, da man sich ja den Wert zur Differenzbildung aus dem Vortag / Vormonat holen kann. Jetzt benötigt DbRep aber mindestens zwei Werte pro Periode. Währe es ein großer Aufwand z.B. eine Option einzubauen, die es erlaubt bei diffValue auf den letzten Wert der Vorperiode zurückzugreifen?

Alternativ hatte ich schon bei der DbLog Entwicklung angefragt ob man die Option im ReduceLog lediglich den letzten Wert zu behalten ausweiten kann auf den ersten und den letzten.

Gruß!

JoeALLb

Zitat von: DerFrickler am 13 Dezember 2016, 18:13:14
Mit der DB bin ich jetzt nach MySQL umgezogen, klappt gut und die Performance ist wirklich deutlich besser. Konsequenter weise sollte ich dann ach meine configDB mit umziehen lassen.
1. Gibt es da eine einfache Methode des Datentransfers vom sqlit3 nach MySQL?
ich würde zurück auf fhem.cfg gehen und wenn dir dbconfig gut gefällt, einfach wieder neu mit DBconfig für mySQL beginnen.

Zitat von: DerFrickler am 13 Dezember 2016, 18:13:14
2. Bei sqlit3 habe ich regelmässig ein VACUUM gemacht, besteht die Notwendigkeit einer Optimierung bei MySQL auch und wie erfolgt das dann bei MySQL?

optimize table history;

Zitat von: DerFrickler am 13 Dezember 2016, 18:13:14
Wie man sich jetzt vorstellen kann handelt es sich bei dem ersten Wert am Tag / Monat um den letzten Wert des Vortages / Vormonats (ich mache um 00:00:01 einen Übertrag auf den Folgetag), wodurch
Ich würde  00:00:00 empfehlen. Dann wird es korrekt in den Plots angezeigt und auch andere Module verwenden den Wert wie gedacht.
Da dieser Wert bei Plots automatisch als Anfag und Ende verwendet wird, würde Dir damit auch ein einziger Eintrag pro Tag ausreichen!

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

Hallo Frickler,

darf ich deine Fragen zum Teil zurückstellen weil ich grad wenig Zeit habe, aber:

ZitatBei sqlit3 habe ich regelmässig ein VACUUM gemacht, besteht die Notwendigkeit einer Optimierung bei MySQL auch und wie erfolgt das dann bei MySQL?

Die Entsprechnung wäre "optimize table". Es dient auch dazu Freiplatz innerhalb der DB freizugeben bzw. der Performanceoptimierung. Ab einem bestimmten Release geht es m. Wissens sogar online nicht blockierend (Joe ? ). Dafür würde ich dann sogar noch eine Funktion in DbRep einbauen.

Zitatdie große des DB-Files anzeigen zu lassen. Gibt es hier für MySQL auch eine Möglichkeit den Speicherbedarf der DB zu ermitteln?

Ja , du kannst die Funktion "get ... tableinfo" im DbRep. Habe Screenshots im Anhang.

ZitatWähre es ein großer Aufwand z.B. eine Option einzubauen, die es erlaubt bei diffValue auf den letzten Wert der Vorperiode zurückzugreifen?

Habe ich jetzt in der V4.8.3 (Eingang) umgesetzt. Teste mal wie es bei dir funktioniert.

Vllt. kann Joe noch etwas dazu sagen.

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

ich habe irgendwie das Gefühl dass mein Setup in MySQL doch nicht so gelungen ist. Tableinfo gibt mir folgenden error text:

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.

Das Erweitern auf 64 char scheint auch nicht gefruchtet zu haben.

2016.12.13 18:36:19 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'DEVICE' at row 1 at ./FHEM/93_DbLog.pm line 613.




Die DB habe ich gemäß wiki und folgender Datei erstellt:

apt-get install mysql-server mysql-client libdbd-mysql libdbd-mysql-perl

mysql -u root -p < db_create_mysql.sql

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemUser'@'%' IDENTIFIED BY 'fhemUser01';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemUser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);


Danach noch:

ALTER TABLE current MODIFY VALUE VARCHAR(64);
ALTER TABLE history MODIFY VALUE VARCHAR(64);

Mit meinen beschränkten SQL Kenntnissen kann ich dann folgendes Ergebnis erkennen:

mysql> use fhem
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current        |
| history        |
+----------------+
2 rows in set (0,00 sec)

mysql>


JoeALLb

Sorry, habe gerade wenig Zeit.
Mach mal folgendes, um auch die Device-Spalte zu vergrößern.

ALTER TABLE current MODIFY DEVICE VARCHAR(64);
ALTER TABLE history MODIFY DEVICE VARCHAR(64);


B ezüglich optimize:
Ich verwende MariaDB statt MySQL, dort liest sich folgendes:
https://mariadb.com/kb/en/mariadb/optimize-table/
If a MyISAM table is fragmented, concurrent inserts will not be performed until an OPTIMIZE TABLE statement is executed on that table, unless the concurrent_insert server system variable is set to ALWAYS.
Für eine Logtabelle ist das so natürlich völlig ausreichend.... (normalerweise)
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

Und installiere bitte noch

sudo apt-get install libdbi-perl

Bin mir nicht sicher ob libdbd identisch ist.
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

Zitat von: JoeALLb am 13 Dezember 2016, 18:49:30
ALTER TABLE current MODIFY DEVICE VARCHAR(64);
ALTER TABLE history MODIFY DEVICE VARCHAR(64);
Da hätte ich jetzt prinzipiell auch 'drauf kommen sollen; Danke!

Zitat von: JoeALLb am 13 Dezember 2016, 18:49:30
B ezüglich optimize:
Ich verwende MariaDB statt MySQL, dort liest sich folgendes:
https://mariadb.com/kb/en/mariadb/optimize-table/
If a MyISAM table is fragmented, concurrent inserts will not be performed until an OPTIMIZE TABLE statement is executed on that table, unless the concurrent_insert server system variable is set to ALWAYS.
Für eine Logtabelle ist das so natürlich völlig ausreichend.... (normalerweise)
Das mit den Optimize läuft leider auch ins leere:
mysql> optimize table history;
+--------------+----------+----------+-------------------------------------------------------------------+
| Table        | Op       | Msg_type | Msg_text                                                          |
+--------------+----------+----------+-------------------------------------------------------------------+
| fhem.history | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| fhem.history | optimize | status   | OK                                                                |
+--------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0,15 sec)

Laut google-Recherche kann diese Mitteilung aber ignoriert werden, da rein informell?!

DerFrickler

Zitat von: DS_Starter am 13 Dezember 2016, 18:56:05
Und installiere bitte noch

sudo apt-get install libdbi-perl

Bin mir nicht sicher ob libdbd identisch ist.

Hatte ich schon bei SQLite mit installiert:

sudo aptitude install sqlite3 libdbi-perl libdbd-sqlite3-perl

und SQLite habe ich wegen der configDB erst mal beibehalten.

DS_Starter

Deinen Fehler:

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.

schauen wir uns später an, muß los.
Mach erstmal ein Update auf DbRep V4.8.3 aus dem Eingangsthread und dann schauen wir weiter.

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

#282
Hallo Frickler, @all,

die Version 4.8.4 sollte die Fehlermeldung

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.

eliminieren.

Bitte mal testen.

EDIT: In der Version habe ich auch die Doku angepasst sowie das Reading "not_enough_data_in_period" in "less_data_in_period" geändert um zu kennzeichnen dass nur 1 Datensatz in der Periode gefunden wurde, aber dennoch eine Diff berechnet wurde mit der Einschränkung der logischen Ungenauigkeit bei der Zuordnung der Diff zu den Aggregationperioden.

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

Hallo,

danke, werde ich gerne am Wochenende ausprobieren. Jetzt hätte ich noch mal eine prinzipielle Frage...

Mit dem Umstieg auf MySQL habe ich erneut den Versuch gewagt meine Langzeit- und Kurzzeitdaten in einer DB zu erfassen.
Langzeitdaten: Werden ca. 2 Jahre in der DB verweilen
Kurzzeitdaten: Werden nach ca. 1 Woche aus der DB entfernt.

Bei 2 DBs habe ich das pro DB über DbLog mit einem deleteOldDays je DB gelöst. Bei einer einzelnen DB müsste ich dann pro Device Typ über DbRep ein delEntries antriggern. Es hält sich in Grenzen, wir liegen da aber bei ca. 15 delEntries, die ich jede Nacht anstossen würde.

Warum wollte ich auf eine DB zurück? Weil mir bei einer 2 DB Strategie jedes FHEM Update die zweite DB Konfiguration zerschossen hat.

Angenommen das Problem des "Konfigurationszerschiessen" beim FHEM Update lässt sich lösen.... was wäre performancetechnisch optimaler? 2 DBs mit jeweils einem deleteOldDays oder 1 DB mit 1 einem deleteOldDay und 15 delEntries?

Gruß!

JoeALLb

Mal noch ein paar Anmerkungen:

1. @DerFrickler: Wenn Du InnoDB als Datenbanktyp verwendest, wird diese nicht kleiner.
    Ich verwende MyISAM oder eben Aria (Für MariaDB). Diese werden tatsächlich kleiner.
Wenn Du das möchtest, kannst du es mit
ALTER TABLE `history`ENGINE=MyISAM;
umstellen. Zurück geht natürlich über den selben Weg auch wieder!

2. Wenn Dich die Datenbankgröße interessiert, nimm nicht Unicode (UTF8), sondern eine herkömmliche Datenbankcodierung. Die Readings die ich so beobachte haben fast nie Unicode-Zeichen
(mit Ausnahme von Radio-Texten beim Abspielen von Musik, aber die interessieren mich eh nicht in der Datenbank).

Der Befehl dazu wäre
ALTER TABLE `history`COLLATE='latin2_swedish_ci';
, jedoch auf eigenes Risiko. Ich nutze es und bin glücklich damit ;-)

3. @Heiko: Ist das "lenth" hier eventuell ein Vertipper und sollte length heißen?
INFO_history.data_index_lenth_MB
generell erzeugt das extrem viele Readings, mich würde aber nur eines davon interessieren. könnte man das (irgendwann mal) noch erweitern um Parameter wie "delete-readings, all " oder eben eine separierte Liste an Readings, die mich interessieren? Wie gesagt, sicher eher nice to have.

4. Blockieren von Optimize:
Leider funktioniert das nut in der Theorie.
Um das zu lösen, nutze ich wie gesagt MariaDB. Zusätzlich nutze ich Partitionierung,
Ich speichere also alle Logeinträge eines Tages in einer Tabelle, die des nächsten Tages in einer anderen Tabelle.
Somit könnte ich heute problemlos die Partition optimieren, die mit den Daten von gestern gefüllt ist.
Der Befehl dazu ist: (mon=monday)
alter table history optimize partition mon;
Einziges Manko: Leider blockiert es aktuell dennoch!

4. @DerFrickler "Warum wollte ich auf eine DB zurück? "
Ich würde immer eine DB bevorzugen. Dafür sind DBs eigentlich gemacht. Normalerweise sollte das auch kein problem darstellen, und wenn doch mal, gibt es dafür Lösungen.
Auch wenn die Plots zwischenzeitlich ebenfalls mit 2 Tabellen zurecht kommen, ist es imemr praktischer, alle Werte in einer Tabelle zu haben.
Aber Achtung: Da das danns chnell mal etwas komplexer wird würde ich mich damit nur beschäftigen, wenn es wirklich notwendig wird!

Welche Lösungen gäbe es:
a) Ich habe beispielsweise hinten eine Spalte angehängt mit dem Titel "Longterm". dort schreibe ich 1 hinein, wenn ich den Datensatz länger behalten möchte und 0, wenn er nicht wichtig ist. Mein Befehl zum löschen berücksichtigt nun einfach dieses Longterm
b) GGf. zusätzlich eine Partition der MySQL-Tabelle mit diesem Longterm als Partitionsanweisung machen. Ein Löschen sämtlicher alten Datensätze dauert damit keine Zeit, da lediglich die entsprechende Tabelle komplett gelöscht wird.
Der Befehl ist bei mir dann schlicht:
ALTER TABLE history TRUNCATE PARTITION longterm
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