p4d: Platte voll weil Datenaggregierung nicht funktioniert hat

meute · May 6th 2026

Quote from Etaminator

Für mich ist es eh' unlogisch, das "Aggregate Intervall" per Parameter einstellen zu können, der dazu passenden Offset jedoch fest hinterlegt ist (+ INTERVAL 15 MINUTE). Bei anderen Einstellungen als 15 Minuten bzw. 900 Sekunden, führt das zu unschönen Nebeneffekten.

Warum dieser Offset von 15 Minuten überhaupt eingeführt wurde ist mir auch unklar.

Das habe ich auch noch nicht verstanden, warum der Offset 15 Minuten ist und für was er gebraucht wird.

Etaminator · May 6th 2026

Quote from meute

Jetzt ist der Parameter "Historie [Tage]" = 1200 gesetzt.
Mal sehen, was heute Nacht passiert.
Es müssten morgen Aggregate-Werte bis Ende 2022/Anfang 2023 vorhanden sein.

Quote from meute

Ich habe im Skript /usr/local/bin/aggregate-samples-manual.sh nichts angepasst.
Ich habe das SQL-Statement manuell ausgeführt.

Hallo meute,

auch wenn das nicht so wichtig ist, sehe ich in diesen Aussagen einen Widerspruch. Ich bin bisher davon ausgegangen, dass du das Script /usr/local/bin/aggregate-samples-manual.sh sehr wohl manuell angepasst hast, sonst kann doch die "nächtliche Automatik" nicht funktionieren?

Und noch ein (etwas kleinlicher) Hinweis:

Dein erster manueller Versuch der Aggregierung für "2020-09-09 12:00:00 bis 18:00:00" hat zwar (teilweise) "A"-Sätze erzeugt, diese waren aber nicht aggregiert, sondern nur dupliziert. Das betrifft zwar nur 6 Stunden, aber ich hätte diese Daten ebenfalls (korrekt) zusammengefasst haben wollen (vielleicht hast du ja auch schon darüber nachgedacht)?

Jedenfalls sind die damals nicht aggregierten Daten inzwischen entweder nachträglich aggregiert oder durch das Delete-Script gelöscht worden. Wenn man wollte, dann könnte man für diesen Zeitraum jetzt noch die "falsch" aggregierten Daten nachträglich nochmals aggregieren, z.B. indem die falsch aggregierten Daten auf "S" zurückgesetzt werden. Der nächste Aggregate-Lauf würde die Daten dann nochmals korrekt zusammenfassen - man könnte das aber auch manuell anstoßen (mit Prüfung vorher und nachher):

Code

#Kontrolle-1
select * from samples 
where time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"

#Update
Update samples set aggregate="S" 
where aggregate = "A" 
and time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"

#Kontrolle-2
select * from samples 
where time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"

#Aggregate
replace into samples
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15*60) * 15*60)) time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from samples
where 
time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15*60) * 15*60)), address, type;

#Kontrolle-3
select * from samples 
where time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"

#Delete
Delete from samples where aggregate = "S" 
and time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"

#Kontrolle-4
select * from samples
where time >= "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"

Display More

Noch ein Hinweis:

Das obige Aggregate-SQL funktioniert (wegen der Einschränkung des Datumsbereichs) nur dann korrekt, wenn der Offset mit den 15 Minuten weggelassen wird. Das sieht man "schön" an dem von dir bereitgestellten Protokoll "p4d_Aggregate_samples_Ergebnis.sql": Dort ist der erste aggregierte Datensatz "A" mit "time = 2020-09-09 12:15:30" hinterlegt - dieser Satz ist ein Duplikat des "S" mit "time = 2020-09-09 12:15:42". Die "S"-Sätze in den 15 Minuten davor wurden (wegen dem 15-Minuten-Offset) nicht aggregiert.

Sorry für die viele Theorie - aber ich möchte das auch für mich verstehen (alte Berufskrankheit). Du kannst das gerne ignorieren - weil wirklich wichtig ist es nicht.

Viele Grüße von Karlheinz

Nachtrag:

Die SQLs habe ich nicht getestet, es kann also auch zu Syntax-Fehlern kommen, falls ich mich verschrieben habe...

SolarEngel · May 6th 2026

Hallo meute,

um die Aggregation genauer zu verstehen und zu visualisieren, habe ich von deinen sample.sql Daten

34 Zeilen "2020-09-09 12:00:42" - "2020-09-09 12:50:12" in eine leere samples Tabelle mit insert eingfügt.

Wie schon von Karlheinz beschrieben geht das ganz gut mit zerlegten SQL-commands.

Also die eigentliche Aggregation findet in der time2 spalte statt durch Runden der Uhrzeit auf 900 Sekunden

mit den beiden Funktionen SEC_TO_TIME und TIME_TO_SEC statt.

Damit man das besser sieht hab ich zusätzlich die original time-spalte vor die time2-spalte eingefügt.

Man sieht dass die Uhrzeit jeder time-spalte in der time2-spalte auf 15Min oder 900 Sekunden gerundet wurde.

MariaDB [p4]> select address, type, 'A' as aggregate, time,

-> CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) time2,

-> unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,

-> value, text, samples

-> from samples;

Code

+---------+------+-----------+---------------------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time                | time2               | inssp      | updsp      | value | text | samples |
+---------+------+-----------+---------------------+---------------------+------------+------------+-------+------+---------+
|       4 | VA   | A         | 2020-09-09 12:50:12 | 2020-09-09 12:45:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:48:42 | 2020-09-09 12:45:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:47:12 | 2020-09-09 12:45:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:45:42 | 2020-09-09 12:45:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:44:12 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:42:42 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:41:12 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:39:42 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:38:12 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:36:42 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:35:12 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:33:42 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:32:12 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:30:42 | 2020-09-09 12:30:00 | 1778023279 | 1778023279 | 18.50 | NULL |       1 |
...
+---------+------+-----------+---------------------+---------------------+------------+------------+-------+------+---------+
34 rows in set (0,001 sec)

Display More

Nun müssen noch die Blöcke mit der gleichen Uhrzeit in der time2 spalte mit

group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) in jeweils eine Aggregat-Zeile zusammgefasst werden.

MariaDB [p4]> select address, type, 'A' as aggregate, time,

-> CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) time,

-> unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,

-> round(sum(value)/count(*), 2) as value, text, count(*) samples

-> from samples

-> where aggregate != 'A'

-> and time < "2020-09-10"

-> group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900));

Code

+---------+------+-----------+---------------------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time                | time                | inssp      | updsp      | value | text | samples |
+---------+------+-----------+---------------------+---------------------+------------+------------+-------+------+---------+
|       4 | VA   | A         | 2020-09-09 12:14:12 | 2020-09-09 12:00:00 | 1778023380 | 1778023380 | 18.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 12:29:12 | 2020-09-09 12:15:00 | 1778023380 | 1778023380 | 18.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 12:44:12 | 2020-09-09 12:30:00 | 1778023380 | 1778023380 | 18.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 12:50:12 | 2020-09-09 12:45:00 | 1778023380 | 1778023380 | 18.50 | NULL |       4 |
+---------+------+-----------+---------------------+---------------------+------------+------------+-------+------+---------+
4 rows in set (0,002 sec)

Und jetzt noch das ganze mit replace in die Tabelle reinschreiben:

MariaDB [p4]> replace into samples

-> select address, type, 'A' as aggregate,

-> CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) time,

-> unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,

-> round(sum(value)/count(*), 2) as value, text, count(*) samples

-> from samples

-> where aggregate != 'A'

-> and time < "2020-09-10"

-> group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900));

Query OK, 4 rows affected (0,009 sec)

Records: 4 Duplicates: 0 Warnings: 0

MariaDB [p4]> select * from samples;

Code

+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time                | inssp      | updsp      | value | text | samples |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
|       4 | VA   | S         | 2020-09-09 12:50:12 | 1599648612 | 1599648612 | 18.50 | NULL |       1 |
|       4 | VA   | S         | 2020-09-09 12:48:42 | 1599648522 | 1599648522 | 18.50 | NULL |       1 |
...
|       4 | VA   | S         | 2020-09-09 12:02:12 | 1599645732 | 1599645732 | 18.00 | NULL |       1 |
|       4 | VA   | S         | 2020-09-09 12:00:42 | 1599645642 | 1599645642 | 18.00 | NULL |       1 |
|       4 | VA   | A         | 2020-09-09 12:45:00 | 1778023730 | 1778023730 | 18.50 | NULL |       4 |
|       4 | VA   | A         | 2020-09-09 12:30:00 | 1778023730 | 1778023730 | 18.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 12:15:00 | 1778023730 | 1778023730 | 18.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 12:00:00 | 1778023730 | 1778023730 | 18.00 | NULL |      10 |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
38 rows in set (0,001 sec)

Display More

Was mir hierbei auffiel ist, dass die Originalzeilen erhalten blieben und die neuen Aggregat-Zeilen hinten angehängt wurden.

Das mit "replace" auch daten insertet werden können, wusste ich bisher auch nicht. Man lernt immer wieder dazu.

In den Unterlagen zur MariaDB ist bei "Einführung von REPLACE INTO" zu lesen.

Die REPLACE INTOAnweisung in MariaDB ermöglicht es, sowohl Einfügungen als auch Aktualisierungen mit einem einzigen SQL-Befehl durchzuführen.

Die grundlegende Syntax ähnelt der von `setup` INSERT INTO, jedoch mit einer Besonderheit:

Existiert bereits eine Zeile mit dem angegebenen Primärschlüssel oder eindeutigen Index, wird diese gelöscht und durch die neue Zeile ersetzt,

was von außen wie eine Aktualisierungsoperation aussieht.

Also die samples-Tabelle wird durch das Aggregieren zuerst mal grösser um die Anzahl der neuen Aggregat-Zeilen.

In diesem Beispiel steigt die Anzahl der Einträge von 34 auf 38 Zeilen in der samples-Tabelle.

Die anschliessende Bereinigung mit dem delete-statement von aggregate != 'A' räumt dann wieder auf.

MariaDB [p4]> delete from samples

-> where aggregate != 'A'

-> and time < "2020-09-10";

Query OK, 34 rows affected (0,009 sec)

In diesem Beispiel hat eine Aggregation die samples-Tabelle von 34 Zeilen auf 4 Zeilen, auf ca. ein zehntel reduziert.

Das bringt schon was und würde deine über 100 Millionen-record samples-Tabelle schon deutlich verkleinern und würde deine Space-Probleme beseitigen.

Das Aggregation-Bereinigung-script manuell aufgerufen mit den zwei Parametern Datum und Zeitintervall

funkioniert auch mit anderen Zeitintervallen als den 15 Minuten.

z.B ./aggregate-samples-manual.sh 2020-09-10 1800

MariaDB [p4]> select * from samples;

+---------+------+-----------+---------------------+------------+------------+-------+------+---------+

+---------+------+-----------+---------------------+------------+------------+-------+------+---------+

| 4 | VA | A | 2020-09-09 12:45:00 | 1778023065 | 1778023065 | 18.50 | NULL | 14 |

| 4 | VA | A | 2020-09-09 12:15:00 | 1778023065 | 1778023065 | 18.00 | NULL | 20 |

+---------+------+-----------+---------------------+------------+------------+-------+------+---------+

2 rows in set (0,001 sec)

Gruß

Jürgen

meute · May 6th 2026

Quote from Etaminator

Und noch ein (etwas kleinlicher) Hinweis:
Dein erster manueller Versuch der Aggregierung für "2020-09-09 12:00:00 bis 18:00:00" hat zwar (teilweise) "A"-Sätze erzeugt, diese waren aber nicht aggregiert, sondern nur dupliziert. Das betrifft zwar nur 6 Stunden, aber ich hätte diese Daten ebenfalls (korrekt) zusammengefasst haben wollen (vielleicht hast du ja auch schon darüber nachgedacht)?

Doch, auch diese Zeiten passen jetzt.

Das war ja der erste Versuch.

Und zu dem Zeitpunkt wurde noch auf Sekunden und nicht auf Minuten aggregiert.

Da kannte ich den Faktor 60 (Sekunden zu Minuten umrechnen) noch nicht.

Die Daten habe ich wieder gelöscht.

Aber gut aufgepasst.

Code

MariaDB [p4]> select * from samples
    -> where address = 4 and type = "VA"
    -> and time > "2020-09-09 12:00:00"
    -> and time < "2020-09-09 18:00:00"
    -> order by time asc;
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time                | inssp      | updsp      | value | text | samples |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
|       4 | VA   | A         | 2020-09-09 12:30:00 | 1777915230 | 1777915230 | 18.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 12:45:00 | 1777915230 | 1777915230 | 18.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 13:00:00 | 1777915230 | 1777915230 | 18.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 13:15:00 | 1777915230 | 1777915230 | 18.60 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 13:30:00 | 1777915230 | 1777915230 | 19.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 13:45:00 | 1777915230 | 1777915230 | 19.30 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 14:00:00 | 1777915230 | 1777915230 | 19.75 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 14:15:00 | 1777915230 | 1777915230 | 20.25 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 14:30:00 | 1777915230 | 1777915230 | 20.70 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 14:45:00 | 1777915230 | 1777915230 | 21.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 15:00:00 | 1777915230 | 1777915230 | 21.45 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 15:15:00 | 1777915230 | 1777915230 | 21.70 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 15:30:00 | 1777915230 | 1777915230 | 22.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 15:45:00 | 1777915230 | 1777915230 | 22.20 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 16:00:00 | 1777915230 | 1777915230 | 22.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 16:15:00 | 1777915230 | 1777915230 | 22.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 16:30:00 | 1777915230 | 1777915230 | 22.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 16:45:00 | 1777915230 | 1777915230 | 22.30 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 17:00:00 | 1777915230 | 1777915230 | 22.00 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 17:15:00 | 1777915230 | 1777915230 | 21.60 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 17:30:00 | 1777915230 | 1777915230 | 21.50 | NULL |      10 |
|       4 | VA   | A         | 2020-09-09 17:45:00 | 1777915230 | 1777915230 | 21.50 | NULL |      10 |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
22 rows in set (0,007 sec)

Display More

Etaminator · May 6th 2026

Quote from meute

Doch, auch diese Zeiten passen jetzt.
Das war ja der erste Versuch.
Und zu dem Zeitpunkt wurden noch auf Sekunden und nicht auf Minuten aggregiert.
Da kannte ich den Faktor 60 (Sekunden zu Minuten umrechnen) noch nicht.
Die Daten habe ich wieder gelöscht.

Hallo meute,

ich finde es echt super, wie du dich in eine (vermutlich) vorher unbekannte Thematik reinwühlst!

Einen kleinen Wermutstropfen muss ich aber noch nachreichen:

In den nachaggregierten Daten (time=2020-09-09 12:xx:00) sieht man, dass für das Intervall 12:15:00 keine Daten (mehr) vorliegen. Das liegt daran, weil dort der (unnötige) 15-Minuten-Offset zugeschlagen hat und die Daten der ersten 15 Minuten nicht aggregiert und mit "A" markiert wurden. Durch das nächste spätere "Delete" auf die stehengeblieben "S"-Sätze wurden diese Daten gelöscht. Nun könnte man diese fehlenden Daten anhand des alten Protokolls per Insert nachträglich wieder einfügen und manuell (oder auch automatisch) aggregieren (lassen) - aber diese kleine Lücke wird wohl nie auffallen. Ich wollte lediglich der Vollständigkeit halber darauf hinweisen.

Übrigens hat Jürgen SolarEngel in seiner sehr gut gemachten Erläuterung ebenfalls auf den 15-Minuten-Offset verzichtet. Andernfalls wären in seiner selektierten Teilmenge ebenfalls die ersten 15 Minuten nicht aggregiert worden.

Wäre es mein Projekt, dann würde ich das SQL-Script entsprechend abändern (und dadurch vereinfachen), auch wenn das "Problem" normalerweise nur bei den allerersten Daten in der Tabelle samples auftritt (oder eben in selektierten Teilmengen). Wie weiter oben schon erwähnt, ist es sowieso "unsauber", zwar das Aggregations-Intervall per Variable an das Script zu übergeben, den damit zusammenhängenden Minuten-Offset jedoch nicht. Vielleicht wollt ihr diesen Aspekt ja in eines der nächsten Updates einfließen lassen...

Viele Grüße von Karlheinz

meute · May 6th 2026

Quote from Etaminator

meute,

ich finde es echt super, wie du dich in eine (vermutlich) vorher unbekannte Thematik reinwühlst!

Danke, aber so ganz unbekannt ist mir SQL nicht.

Quote from Etaminator

Übrigens hat Jürgen SolarEngel in seiner sehr gut gemachten Erläuterung ebenfalls auf den 15-Minuten-Offset verzichtet. Andernfalls wären in seiner selektierten Teilmenge ebenfalls die ersten 15 Minuten nicht aggregiert worden.

Wäre es mein Projekt, dann würde ich das SQL-Script entsprechend abändern (und dadurch vereinfachen), auch wenn das "Problem" normalerweise nur bei den allerersten Daten in der Tabelle samples auftritt (oder eben in selektierten Teilmengen).

Solange sich horchi nicht dazu äußert, warum er die 15 Minuten eingebaut hat, können wir nur mutmaßen.

Ansonsten könnte man auch einen Pull request stellen:

linux-p4d/scripts/aggregate-samples-manual.sh at master · horchi/linux-p4d

Deamon which fetch sensor data of the 'Lambdatronic s3200' and store to a MySQL database - horchi/linux-p4d

github.com

horchi · May 7th 2026

Sorry ich habe das Problem noch nicht verstanden ..

- was die Aggregation macht und wofür sie ist das ist klar und nicht die Frage?

- die 15 Minuten sind der default aber einstellbar und auch nirgends hard-coded sofern ich bei check gerade nicht übersehen habe

Könnt Ihr mir bitte erläutern was nicht geht bzw. was die Farge ist?

Etaminator · May 7th 2026

Quote from horchi

- was die Aggregation macht und wofür sie ist das ist klar und nicht die Frage?
- die 15 Minuten sind der default aber einstellbar und auch nirgends hard-coded sofern ich bei check gerade nicht übersehen habe

Hallo horchi,

ich melde mich nochmal, weil ich mich weiter oben eingemischt habe und weil ich meute helfen wollte.

Wie die Aggregation funktioniert, ist (glaube ich) inzwischen allen klar.

Der Ausgangspunkt der von mir angestoßenen Diskussion war folgendes:

Die "fixen" 15 Minuten beziehen sich auf das oben verlinkte script aggregate-samples-manual.sh.

Dort steht zweimal der Ausdruck "+ INTERVAL 15 MINUTE".

Das wäre Hard-Coded und würde nicht zum Übergabeparameter "interval [minutes]" passen, sofern dieser nicht auch "15" wäre.

Diesen Ausdruck "INTERVAL 15 MINUTE) könnte/müsste man natürlich ebenfalls variabel machen.

M.E. ist dieses "INTERVAL 15 MINUTE" ein unnötiger Offset und ich würde es ganz weglassen.

Aber vielleicht übersehe ich ja auch etwas?

Viele Grüße von Karlheinz

horchi · May 7th 2026

Ich habe jetzt nochmal im code geschaut, wo ist es denn hard coded

asprintf(&stmt,

"replace into samples "

" select address, type, 'A' as aggregate, "

" CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV %d) * %d)) + INTERVAL %d MINUTE time, "

" unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp, "

" round(sum(value)/count(*), 2) as value, text, count(*) samples "

" from "

" samples "

" where "

" aggregate != 'A' and "

" time <= from_unixtime(%ld) "

" group by "

" CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV %d) * %d)) + INTERVAL %d MINUTE, address, type;",

aggregateInterval * tmeSecondsPerMinute, aggregateInterval * tmeSecondsPerMinute, aggregateInterval,

history,

aggregateInterval * tmeSecondsPerMinute, aggregateInterval * tmeSecondsPerMinute, aggregateInterval);

tell(eloAlways, "Starting aggregation ...");

pellet-heizer · May 7th 2026

Hallo Jörg,

im Skript "aggregate-samples-manual.sh" steht:

Quote

echo "replace into samples
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV ${INT}) * ${INT})) + INTERVAL 15 MINUTE time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from
samples

where

aggregate != 'A' and time <= '${DATE}'

group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV ${INT}) * ${INT})) + INTERVAL 15 MINUTE, address, type;" | mysql -u p4 -pp4 -Dp4

Display More

horchi · May 7th 2026

ahh okay, ich kann das Erweitern sodass man es als Parameter mitgeben kann. Grundsätzlich ist es so gedacht das der p4d das alles macht. Das Script war mal zum Testen.

Etaminator · May 7th 2026

Quote from Etaminator

M.E. ist dieses "INTERVAL 15 MINUTE" aber unnötig und ich würde es ganz weglassen.

Wäre das nicht einfacher?

horchi · May 7th 2026

du meinst einfach nicht konfigurierbar und immer 15 Minuten?

Etaminator · May 7th 2026

Quote

echo "replace into samples
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV ${INT}) * ${INT})) ~~+ INTERVAL 15 MINUTE~~ time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from
samples
where
aggregate != 'A' and time <= '${DATE}'
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV ${INT}) * ${INT})) ~~+ INTERVAL 15 MINUTE~~, address, type;" | mysql -u p4 -pp4 -Dp4

Display More

Ich meine, dass der durchgestrichene Ausdruck redundant, bzw. sogar schädlich ist. Lässt man den Ausdruck weg, braucht man ihn auch nicht parametrieren.

Etaminator · Friday, 11:05 am

Hallo horchi.

Nachtrag:

Mangels eigener Kenntnis des Projekts p4d bin ich bisher davon ausgegangen, dass p4d das besagte Script "aggregate-samples-manual.sh" verwendet. Jetzt weiß ich, dass die SQL-Aggregierung vom Programm generiert wird. Dort wäre natürlich derselbe "Issue" zu korrigieren.

In diesem Zusammenhang wäre es eine Überlegung wert, generell das externe Script aufzurufen. Das Script zum Testen ist ja durchaus sinnvoll und (spätere) Änderungen wären nur an einer Stelle erforderlich. Aber das ist eine Designfrage und es ist dein Projekt.

Viele Grüße von Karlheinz

horchi · Friday, 11:41 am

Quote from Etaminator

Hallo horchi.

Nachtrag:
Mangels eigener Kenntnis des Projekts p4d bin ich bisher davon ausgegangen, dass p4d das besagte Script "aggregate-samples-manual.sh" verwendet. Jetzt weiß ich, dass die SQL-Aggregierung vom Programm generiert wird. Dort wäre natürlich derselbe "Issue" zu korrigieren.

In diesem Zusammenhang wäre es eine Überlegung wert, generell das externe Script aufzurufen. Das Script zum Testen ist ja durchaus sinnvoll und (spätere) Änderungen wären nur an einer Stelle erforderlich. Aber das ist eine Designfrage und es ist dein Projekt.

Viele Grüße von Karlheinz

Display More

1)
ich möchte es (zumindest aus jetziger Sicht) lieber im Code belassen statt ein externes Skript aufzurufen - kann ich aber bei Gelegenheit nochmal drüber nachdenken.

2)
zu den 15 Minuten, das absichtlich konfigurierbar, manche wollen ggf.über andere Intervalle aggregieren -

3)

weglassen der 15 Minuten ...
wie stellst du dir die Aggregation vor?

Die 15 Minuten Alias 900 Sekunden geben den Intervall an über welchen aggregiert wird.
Hier ein Beispiel mit den ersten paar Ergebnissen der Aggregation - zur besseren Übersichtlichkeit mit nur einem Sensor:

Code

MariaDB [p4]> select address, type, 'A' as aggregate, time as 'time-S', CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) + INTERVAL 15 MINUTE 'time-A', unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp, round(sum(value)/count(*), 2) as value, text, count(*) samples from samples where aggregate != 'A' and type = 'VA' and address = 2 and

time <= from_unixtime(1778232222) and time > from_unixtime(1777368392)  group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) + INTERVAL 15 MINUTE, address, type limit 10;

+---------+------+-----------+---------------------+----------------------------+------------+------------+-------+------+---------+

| address | type | aggregate | time-S              | time-A                     | inssp      | updsp      | value | text | samples |

+---------+------+-----------+---------------------+----------------------------+------------+------------+-------+------+---------+

|       2 | VA   | A         | 2026-04-28 11:27:15 | 2026-04-28 11:30:00.000000 | 1778232911 | 1778232911 | 25.33 | NULL |       3 |

|       2 | VA   | A         | 2026-04-28 11:30:15 | 2026-04-28 11:45:00.000000 | 1778232911 | 1778232911 | 25.40 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 11:45:15 | 2026-04-28 12:00:00.000000 | 1778232911 | 1778232911 | 25.47 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 12:00:15 | 2026-04-28 12:15:00.000000 | 1778232911 | 1778232911 | 25.47 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 12:15:15 | 2026-04-28 12:30:00.000000 | 1778232911 | 1778232911 | 25.43 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 12:30:15 | 2026-04-28 12:45:00.000000 | 1778232911 | 1778232911 | 25.10 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 12:45:15 | 2026-04-28 13:00:00.000000 | 1778232911 | 1778232911 | 25.00 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 13:00:15 | 2026-04-28 13:15:00.000000 | 1778232911 | 1778232911 | 25.00 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 13:15:15 | 2026-04-28 13:30:00.000000 | 1778232911 | 1778232911 | 24.90 | NULL |      15 |

|       2 | VA   | A         | 2026-04-28 13:30:15 | 2026-04-28 13:45:00.000000 | 1778232911 | 1778232911 | 24.97 | NULL |      15 |

+---------+------+-----------+---------------------+----------------------------+------------+------------+-------+------+---------+

Display More

Du kannst mir das Statement welches dir vorschwebt ja mal mit paar Ergebnissen posten dann verstehe ich sicher besser worauf du hinaus möchtest.

horchi · Friday, 11:53 am

ahh jetzt ... ich sehe/verstehe nun was du meinst!

ich habe damit das speichern auf das Ende des Zeitabschnitts geschoben also z.B. die Werte von 14:00-14:15 unter 14:15 statt unter 14:00 gespeichert, kam mir damals besser vor. Unterm Strich spielt es aber nicht wirklich eine Rolle und ist so vermutlich verwirrender.

Die 15 Minuten müssen dennoch konfigurierbar bleiben wenn die Intervalle nicht fix sein sollen, also auch ohne INTERVALL wie hier:

Code

select address, type, 'A' as aggregate, time as 'time-S', CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900))  'time-A', unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp, round(sum(value)/count(*), 2) as value, text, count(*) samples from samples where aggregate != 'A' and type = 'VA' and address = 2 and time <= from_unixtim
e(1778232222) and time > from_unixtime(1777368392)  group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)), address, type limit 10;

Etaminator · Friday, 12:15 pm

Dass die Daten über ein einstellbares Zeitintervall aggregiert werden müssen, stellt niemand in Frage. Es geht lediglich darum, den unnötigen Ausdruck "INTERVAL 15 MINUTE" wegzulassen.

Code

MariaDB [p4]> replace into samples
select address, type, 'A' as aggregate, CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900)) time, unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp, round(sum(value)/count(*), 2) as value, text, count(*) samples
from samples
where aggregate != 'A'
and time < "2020-09-10" 
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 900) * 900));

Ich nehme mal das obige Beispiel von SolarEngel. Dort hat er den Ausdruck "INTERVAL 15 MINUTE" weggelassen und es funktioniert (m.E. sogar besser).

Dieses INTERVAL wirkt als Offset auf die Startdaten, was dazu führt, dass die Daten auf das obere Intervall-Ende aggregiert werden. Das ist ungewöhnlich und macht das SQL unnötig komplex. Daher finde ich diesen Ausdruck redundant.

Ich kann es leider nicht besser erklären. Bin grad nur am Handy, aber später könnte ich das noch mit einem Beispiel belegen, falls gewünscht...

Viele Grüße von Karlheinz

Nachtrag:

Unsere Beiträge haben sich zeitlich überschnitten.

meute · Monday, 9:56 am

Hallo,

Aggregate läuft nun wie es soll.

Es werden täglich alle Daten älter als 365 Tage aggregiert.

Dadurch sind nun die Daten in der Tabelle samples massiv geschrumpft.

Die Tabelle samples enthält nur noch 13 GB Daten.

Die Datenbankdatei samples.ibd ist aber 21 GB groß.

Deshalb wollte ich die Datenbankdatei samples.ibd verkleinern.

Hat das schon mal jemand gemacht und kann dazu was sagen?

Ich vermute, das geht vermutlich am Besten so:

- Tabelle samples löschen

- Tabelle samples neu erstellen

- Backup samples importieren

Hier habe ich mal notiert, wie ich es machen würde.

Kann da bitte mal jemand drüberschauen, ob das so passen kann oder ob ich was vergessen habe.

Code

#
# Linux
#

# Dienst p4d – stoppen
sudo systemctl stop p4d.service

# Anmelden an Datenbank p4
mysql -u p4 -pp4 p4

SQL

--
-- MariaDB
--

-- Tabellen anzeigen
SHOW TABLES;

-- Tabelle samples löschen
DROP TABLE IF EXISTS samples;

-- Tabellen anzeigen
SHOW TABLES;

-- Tabelle samples erstellen
CREATE TABLE `samples` (
`address` int(4) unsigned NOT NULL,
`type` varchar(8) NOT NULL,
`aggregate` varchar(1) NOT NULL,
`time` datetime NOT NULL,
`inssp` int(10) DEFAULT NULL,
`updsp` int(10) DEFAULT NULL,
`value` float(14,2) DEFAULT NULL,
`text` varchar(50) DEFAULT NULL,
`samples` int(3) DEFAULT NULL,
PRIMARY KEY (`address`,`type`,`aggregate`,`time`),
KEY `idxtime` (`time`),
KEY `idxtype` (`type`),
KEY `idxaggregate` (`aggregate`),
KEY `idxaddr_type_time` (`address`,`type`,`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

-- Tabellen anzeigen
SHOW TABLES;

Display More

Code

#
# Linux
#

# Backup der Tabelle samples unzippen
sudo gunzip samples-dump.sql.gz

# Backup der Tabelle samples importieren
sudo mysql -u p4 -pp4 -Dp4 < samples-dump.sql

# Dienst p4d – starten
sudo systemctl start p4d.service

Display More

Etaminator · Monday, 10:26 am

Hallo meute,

ich würde die Methode OPTIMIZE TABLE samples; bevorzugen. Vorher natürlich den p4d-Dienst beenden und die Daten sichern.

MariaDB verkleinern optimieren defragmentieren

Viele Grüße von Karlheinz

p4d: Platte voll weil Datenaggregierung nicht funktioniert hat

Participate now!

Share