Hallo,
weiß jemand, woran es liegt, wenn in die Log-Datei /var/log/p4d.log kein Eintrag mehr geschrieben wird?
Der letzte Eintrag ist schon ein paar Monate alt.
p4d: Platte voll weil Datenaggregierung nicht funktioniert hat
There are 41 replies in this Thread which was already clicked 1,014 times. The last Post () by Etaminator.
-
Ist noch Platz auf dem Laufwerk?
Codedf -H -
Ist noch Platz auf dem Laufwerk?
p4d läuft auf Proxmox.
Ergebnis:
Code$ df -H Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-vm--101--disk--0 28G 25G 1,6G 95% / none 504k 4,1k 500k 1% /dev efivarfs 394k 100k 289k 26% /sys/firmware/efi/efivars tmpfs 11G 0 11G 0% /dev/shm tmpfs 4,2G 156k 4,2G 1% /run tmpfs 5,3M 0 5,3M 0% /run/lock tmpfs 2,1G 8,2k 2,1G 1% /run/user/1000EDIT:
p4d läuft seit 5-6 Jahren.
Die p4d Datenbank hat 18 GB.
Ist das normal?
Oder kann/soll/muss man die mal komprimieren?
Code
Display More$ sudo du -h / | sort -hr | head -n 50 24G / 22G /var 19G /var/lib/mysql 19G /var/lib 18G /var/lib/mysql/p4 2,6G /var/log/journal/46317947ab404df8a41931f4eb4d85c5 2,6G /var/log/journal 2,6G /var/log 1,4G /usr 459M /usr/lib 308M /usr/lib/x86_64-linux-gnu 292M /usr/bin 258M /var/cache 257M /var/lib/apt/lists 257M /var/lib/apt 235M /var/cache/apt 206M /usr/share 203M /usr/src 145M /usr/src/libwebsockets 111M /var/cache/apt/archives -
Eigentlich sollte eine automatische Zusammenfassung der Daten erfolgen. Unter "Konfiguration" gibt es dafür die Punkte:
"Intervall der Aufzeichnung" - alle wieviel Sekunden sollen Meßwerte aufgezeichnet werden (Standard 60)
"Historie [Tage]" - das ist die Anzahl Tage, für die Meßwerte im obigen Intervall vorliegen. Alles was älter ist, wird zusammengefaßt (Standard 365).
"Aggregate Intervall der historisierten Daten [m]" - die Daten werden auf dieses Intervall zusammengefaßt (Standard 15).
Kannst ja mal Deine Werte anschauen und prüfen, ob ältere Werte tatsächlich nur noch im "Aggregate Intervall" vorliegen. Ich finde die Größe Deiner Datenbank ziemlich hoch.
Meine "samples" Tabelle ist ca. 1,5GB groß und hat Daten seit Mitte August 2025. Bei mir liegen alle Daten noch im Intervall von einer Minute vor , weil noch keine 365 Tage rum sind. Bei 365 Tagen wird der benötigte Speicher für diese Daten auf ca. 2,25GB angewachsen sein. Die aggregierten Daten benötigen dann nur noch ein Fünfzehntel des Platzes, also ca. 150MB pro Jahr. Bei 6 Jahren sollte das dann eine Gesamtmenge von ca. 3GB ergeben.
-
Eigentlich sollte eine automatische Zusammenfassung der Daten erfolgen. Unter "Konfiguration" gibt es dafür die Punkte:
"Intervall der Aufzeichnung" - alle wieviel Sekunden sollen Meßwerte aufgezeichnet werden (Standard 60)
"Historie [Tage]" - das ist die Anzahl Tage, für die Meßwerte im obigen Intervall vorliegen. Alles was älter ist, wird zusammengefaßt (Standard 365).
"Aggregate Intervall der historisierten Daten [m]" - die Daten werden auf dieses Intervall zusammengefaßt (Standard 15).
Meine Einstellung ist Standard.
"Intervall der Aufzeichnung" - 60 (Standard 60)
"Historie [Tage]" - 365 (Standard 365)
"Aggregate Intervall der historisierten Daten [m]" - 15 (Standard 15)
-
Kannst ja mal Deine Werte anschauen und prüfen, ob ältere Werte tatsächlich nur noch im "Aggregate Intervall" vorliegen. Ich finde die Größe Deiner Datenbank ziemlich hoch.
Danke für den Tipp.
Und ja, Du hast Recht. Der "Aggregate Intervall" funktioniert bei mir nicht.
Wie kann ich das lösen bzw. das Zusammenfassen der alten Daten neu starten?
Hier mal zwei Beispiele der Außentemperatur aus Januar 2025 und Januar 2024.
Code
Display MoreMariaDB [p4]> select * from samples -> where address = 4 and type = "VA" -> and time > "2025-01-16 13:00:00" -> and time < "2025-01-16 13:30:00" -> order by time asc; +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ | address | type | aggregate | time | inssp | updsp | value | text | samples | +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ | 4 | VA | S | 2025-01-16 13:00:29 | 1737028829 | 1737028829 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:01:29 | 1737028889 | 1737028889 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:02:29 | 1737028949 | 1737028949 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:03:29 | 1737029009 | 1737029009 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:04:29 | 1737029069 | 1737029069 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:05:29 | 1737029129 | 1737029129 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:06:29 | 1737029189 | 1737029189 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:07:29 | 1737029249 | 1737029249 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:08:29 | 1737029309 | 1737029309 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:09:29 | 1737029369 | 1737029369 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:10:29 | 1737029429 | 1737029429 | 3.50 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:11:29 | 1737029489 | 1737029489 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:12:29 | 1737029549 | 1737029549 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:13:30 | 1737029610 | 1737029610 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:14:29 | 1737029669 | 1737029669 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:15:29 | 1737029729 | 1737029729 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:16:29 | 1737029789 | 1737029789 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:17:29 | 1737029849 | 1737029849 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:18:29 | 1737029909 | 1737029909 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:19:29 | 1737029969 | 1737029969 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:20:29 | 1737030029 | 1737030029 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:21:29 | 1737030089 | 1737030089 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:22:29 | 1737030149 | 1737030149 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:23:29 | 1737030209 | 1737030209 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:24:29 | 1737030269 | 1737030269 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:25:29 | 1737030329 | 1737030329 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:26:29 | 1737030389 | 1737030389 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:27:29 | 1737030449 | 1737030449 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:28:29 | 1737030509 | 1737030509 | 4.00 | NULL | 1 | | 4 | VA | S | 2025-01-16 13:29:29 | 1737030569 | 1737030569 | 4.00 | NULL | 1 | +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ 30 rows in set (0,001 sec)Code
Display MoreMariaDB [p4]> select * from samples -> where address = 4 and type = "VA" -> and time > "2024-01-16 13:00:00" -> and time < "2024-01-16 13:30:00" -> order by time asc; +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ | address | type | aggregate | time | inssp | updsp | value | text | samples | +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ | 4 | VA | S | 2024-01-16 13:00:58 | 1705406458 | 1705406458 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:01:58 | 1705406518 | 1705406518 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:02:58 | 1705406578 | 1705406578 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:03:58 | 1705406638 | 1705406638 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:04:58 | 1705406698 | 1705406698 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:05:58 | 1705406758 | 1705406758 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:06:58 | 1705406818 | 1705406818 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:07:58 | 1705406878 | 1705406878 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:08:58 | 1705406938 | 1705406938 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:09:58 | 1705406998 | 1705406998 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:10:58 | 1705407058 | 1705407058 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:11:58 | 1705407118 | 1705407118 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:12:59 | 1705407179 | 1705407179 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:13:58 | 1705407238 | 1705407238 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:14:58 | 1705407298 | 1705407298 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:15:58 | 1705407358 | 1705407358 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:16:58 | 1705407418 | 1705407418 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:17:58 | 1705407478 | 1705407478 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:18:58 | 1705407538 | 1705407538 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:19:58 | 1705407598 | 1705407598 | -0.50 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:20:58 | 1705407658 | 1705407658 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:21:58 | 1705407718 | 1705407718 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:22:58 | 1705407778 | 1705407778 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:23:58 | 1705407838 | 1705407838 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:24:58 | 1705407898 | 1705407898 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:25:58 | 1705407958 | 1705407958 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:26:58 | 1705408018 | 1705408018 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:27:58 | 1705408078 | 1705408078 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:28:58 | 1705408138 | 1705408138 | 0.00 | NULL | 1 | | 4 | VA | S | 2024-01-16 13:29:58 | 1705408198 | 1705408198 | 0.00 | NULL | 1 | +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ 30 rows in set (0,006 sec) -
Der "Aggregate Intervall" funktioniert bei mir nicht.
Ich weiß natürlich nicht, wie Aggregate umgesetzt wurde.
Es gibt in MariaDB "Aggregate Functions".
Aber das ist mir im Moment zu hoch.
Man kann sich vorhandene "Functions" anzeigen lassen.
Da scheint aber keine "Aggregate Function" dabei zu sein.
MariaDB [mysql]> SHOW FUNCTION STATUS\G
Mal sehen, ob mir hier jemand weiterhelfen kann.
-
Der P4D Code hat eine Funktion, welche die Zusammenfassung anstößt, wenn das Zeitkriterium erfüllt ist.
Es gibt aber unter "/usr/local/bin" auch ein Skript "aggregate-samples-manual.sh", welches die gleiche Funktionalität beinhaltet. Das könntest Du nutzen.
-
Es gibt aber unter "/usr/local/bin" auch ein Skript "aggregate-samples-manual.sh", welches die gleiche Funktionalität beinhaltet. Das könntest Du nutzen.
Ich habe mir das Skript /usr/local/bin/aggregate-samples-manual.sh angeschaut.
Die SQL-Statements darin habe ich erst mal direkt in der Datenbank ausgeführt.
Und auch nur für Daten älter als 01.01.2021. p4d läuft bei mir seit ca. Juli 2020.
Also hätte es ca. 6 Monate betroffen.
Aber es kam ein Fehler, weil die Partition zu klein war und die MariaDB keinen Platz hatte, um tmp-Daten zu erstellen.
Also wurde die Partition vergrößert, jetzt sind 6 GB frei.
Nun habe ich den Zeitbereich erst mal verkleinert auf 6 Stunden von 09.09.2020 12:00 Uhr bis 09.09.2020 18:00 Uhr
time > "2020-09-09 12:00:00"
time < "2020-09-09 18:00:00"
Hier vorab mein Fazit:
Die Aggregate-Funktion in der Datei /usr/local/bin/aggregate-samples-manual.sh scheint nicht zu funktionieren.
Ausführliche Beschreibung ab hier.
Das Ergebnis aller SQL-Statements ist zusätzlich in der separaten Datei "p4d_Aggregate_samples_Ergebnis.sql" zu sehen.
Es wurden folgende SQL-Statement ausgeführt.
1. SQL-Statement
Vor Aggregate ermitteln, wie viele Datensätze der Außentemperatur für den Zeitraum vorhanden sind.
Ergebnis sind 240 Datensätze Außentemperatur.
Codeselect * 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; 240 rows in set (0,005 sec)2. SQL-Statement
Datensätze für Aggregate ermitteln und mit aggregate='A' markieren.
Code
Display Morereplace into samples select address, type, 'A' as aggregate, CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15) * 15)) + 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 > "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) * 15)) + INTERVAL 15 MINUTE, address, type; Query OK, 11040 rows affected (0,705 sec) Records: 11040 Duplicates: 0 Warnings: 03. SQL-Statement
Nach dem Markieren der Datensätze für Aggregate ermitteln, wie viele Datensätze der Außentemperatur für den Zeitraum vorhanden sind.
Ergebnis sind plötzlich 470 Datensätze Außentemperatur.
Codeselect * 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; 470 rows in set (0,005 sec)4. SQL-Statement
Datensätze löschen, die nicht für Aggregate benötigt werden.
Bedingung: aggregate != 'A'
Codedelete from samples where aggregate != 'A' and time > "2020-09-09 12:00:00" and time < "2020-09-09 18:00:00"; Query OK, 11040 rows affected (0,568 sec)5. SQL-Statement
Nach Aggregate ermitteln, wie viele Datensätze der Außentemperatur für den Zeitraum vorhanden sind.
Ergebnis sind 230 Datensätze Außentemperatur.
Es wurden also nur 10 Datensätze innerhalb von 6 Stunden gelöscht.
Das ist sicher viel zu wenig.
Codeselect * 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; 230 rows in set (0,002 sec) -
Kann ich nicht, weil meine Daten noch nicht älter als 365 Tage sind.
-
Kann ich nicht, weil meine Daten noch nicht älter als 365 Tage sind.
OK, schade.
Vll. meldet sich ja noch jemand anderes.
Ich würde es gerne verifizieren, bevor ich das von mir auf 15 Minuten Aggregate angepasste Skript /usr/local/bin/aggregate-samples-manual.sh loslaufen lasse.
Mein p4d läuft jetzt 6 Jahre und ich habe festgestellt, dass noch kein einziger Datensatz mit Aggregate bearbeitet wurde.
-
Hallo meute,
du könntest dein neues SQL-Statement nochmal auf einen anderen 6-Stundenbereich anwenden und das Ergebnis wieder posten. Schlimmeres wird nicht passieren.
Du bist auf der richtigen Spur, ich in mir aber nicht sicher, ob die Gruppierung und Aufsummierung so funktioniert. Mangels p4d-Umgebung kann ich es nur theoretisch vermuten. Die neuen Ergebnisse könnten dabei helfen, dies zu bestätigen oder zu widerlegen...
Nachtrag:
Wenn du, wie oben gepostet, den Befehl "select count(*), ... from samples where address = 4 and type = "VA" and ... group by ..." leicht ergänzt und ohne das vorangestellte "replace into samples" laufen lässt, erhälst du die Vorschau auf das zu erwartende Ergebnis, ohne die Daten gleich in die Tabelle zu schreiben.
Der Ausdruck "count(*)" hilft zu beurteilen, wie viele Zeilen pro Gruppe (Zeitintervall) tatsächlich aggregiert wurden.
Die weiter eingrenzende where-Bedingung verkleinert die Datenmenge und zeigt nur die (Außentemperatur-) Daten, auf die es bei diesem Test ankommt.
Viele Grüße von Karlheinz
-
Hier sind meine Daten aus dem letzten Jahr. Sie sind, wie erwartet, in 15-Minuten-Intervalle aggregiert. Ein Blick auf das Diagramm für denselben Zeitraum zeigt ebenfalls ein Abtastintervall von 15 Minuten. Ich verwende Version 0.11.7-GIT4d1176c. Meine Außentemperatur liegt auf Adresse 8 statt auf 4 (S3 Turbo).
Code
Display MoreMariaDB [p4]> select * from samples where address = 8 and type = "VA" and time > "2025-04-25 13:00:00" and time < "2025-04-25 19:00:00" order by time asc; +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ | address | type | aggregate | time | inssp | updsp | value | text | samples | +---------+------+-----------+---------------------+------------+------------+-------+------+---------+ | 8 | VA | A | 2025-04-25 13:15:00 | 1777190429 | 1777190429 | 5.50 | NULL | 15 | | 8 | VA | A | 2025-04-25 13:30:00 | 1777190429 | 1777190429 | 5.47 | NULL | 15 | | 8 | VA | A | 2025-04-25 13:45:00 | 1777190429 | 1777190429 | 5.10 | NULL | 15 | | 8 | VA | A | 2025-04-25 14:00:00 | 1777190429 | 1777190429 | 5.00 | NULL | 15 | | 8 | VA | A | 2025-04-25 14:15:00 | 1777190429 | 1777190429 | 5.00 | NULL | 15 | | 8 | VA | A | 2025-04-25 14:30:00 | 1777190429 | 1777190429 | 5.17 | NULL | 15 | | 8 | VA | A | 2025-04-25 14:45:00 | 1777190429 | 1777190429 | 5.23 | NULL | 15 | | 8 | VA | A | 2025-04-25 15:00:00 | 1777190429 | 1777190429 | 5.50 | NULL | 15 | | 8 | VA | A | 2025-04-25 15:15:00 | 1777190429 | 1777190429 | 5.50 | NULL | 15 | | 8 | VA | A | 2025-04-25 15:30:00 | 1777190429 | 1777190429 | 5.50 | NULL | 15 | | 8 | VA | A | 2025-04-25 15:45:00 | 1777190429 | 1777190429 | 5.87 | NULL | 15 | | 8 | VA | A | 2025-04-25 16:00:00 | 1777190429 | 1777190429 | 6.07 | NULL | 15 | | 8 | VA | A | 2025-04-25 16:15:00 | 1777190429 | 1777190429 | 6.50 | NULL | 15 | | 8 | VA | A | 2025-04-25 16:30:00 | 1777190429 | 1777190429 | 6.80 | NULL | 15 | | 8 | VA | A | 2025-04-25 16:45:00 | 1777190429 | 1777190429 | 7.17 | NULL | 15 | | 8 | VA | A | 2025-04-25 17:00:00 | 1777190429 | 1777190429 | 7.63 | NULL | 15 | | 8 | VA | A | 2025-04-25 17:15:00 | 1777190429 | 1777190429 | 8.13 | NULL | 15 | | 8 | VA | A | 2025-04-25 17:30:00 | 1777190429 | 1777190429 | 8.60 | NULL | 15 | | 8 | VA | A | 2025-04-25 17:45:00 | 1777190429 | 1777190429 | 9.00 | NULL | 15 | | 8 | VA | A | 2025-04-25 18:00:00 | 1777190429 | 1777190429 | 9.53 | NULL | 15 | | 8 | VA | A | 2025-04-25 18:15:00 | 1777190429 | 1777190429 | 9.93 | NULL | 15 | | 8 | VA | A | 2025-04-25 18:30:00 | 1777190429 | 1777190429 | 10.37 | NULL | 15 | | 8 | VA | A | 2025-04-25 18:45:00 | 1777190429 | 1777190429 | 10.80 | NULL | 15 | +---------+------+-----------+---------------------+------------+------------+-------+------+---------+In meinem Aggregationsskript (/usr/local/bin/aggregate-samples-manual.sh) ist der Wert 15 nicht fest einprogrammiert (hard-coded); es handelt sich um eine Variable, die an das Skript übergeben wird. Ich weiß nicht, ob Sie in Ihrem Code-Beispiel die Variable durch „15“ ersetzt haben oder ob dieser Wert dort fest einprogrammiert ist.
Codeecho "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 -
In meinem Aggregationsskript (/usr/local/bin/aggregate-samples-manual.sh) ist der Wert 15 nicht fest einprogrammiert (hard-coded); es handelt sich um eine Variable, die an das Skript übergeben wird.
Bei mir steht im Skript /usr/local/bin/aggregate-samples-manual.sh natürlich auch die Variable ${INT} drin.
Aber wie oben geschrieben, erfolgt damit Aggregate auf 15 Sekunden und nicht 15 Minuten.
Es fehlt der Faktor 60
Code
Display More-- Original SELECT-Syntax aus dem Skript (Mit Fehler, weil Aggregate auf 15 Sekunden) 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;Code
Display More-- Angepasste SELECT-Syntax auf Aggregate auf 15 Minuten replace into samples select address, type, 'A' as aggregate, CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV (${INT} * 60)) * (${INT} * 60))) + 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} * 60)) * (${INT} * 60))) + INTERVAL 15 MINUTE, address, type; -
Hallo meute,
wenn das Aggregation-Bereinigung-script manuell aufrufst z.B. mit den zwei Parametern Datum(2021-01-01) und Zeitintervall(900)
z.B ./aggregate-samples-manual.sh 2021-01-01 900
das funktioniert auch und aggregiert in 15 Minuten-Zeitintervallen. (900 sind die 15Minuten in 900Sekunden umgerechnet).
Dann brauchst im Original-script (aggregate-samples-manual.sh) nix ändern.
Vielleicht kannst in der Konfiguration in der nächste Zeile nach dem Parameter "Historie [Tage]"
--> "danach aggregieren über " die bisherigen 15 mit 900 überschreiben.
Gruß
Jürgen
-
Hallo,
ich habe diese Problemstellung aus dem großen p4d-Thema in dieses separate Thema verschoben - ich hoffe, das ist für meute und die anderen Beteiligten in Ordnung.
Zu dem Script:
Da das Script bei OffGridICF ohne Änderungen funktioniert, muss es bei meute an der Programmversion liegen (sofern das Script direkt aus dem p4d-Programm aufgerufen wird und nicht über andere Mechanismen).
Ich finde es auch nicht weiter schlimm, wenn das Script lokal angepasst wird, wenn es dann wie gewünscht funktioniert. Man muss beim Update ggf. daran denken.
Meine Einstellung ist Standard.
...
"Aggregate Intervall der historisierten Daten [m]" - 15 (Standard 15)
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 ist m.E. gar nicht erforderlich, sondern sogar kontraproduktiv, weil dadurch die Daten in den ältesten 15 Minuten der Tabelle samples nie aggregiert werden? Das merkt man aber vermutlich gar nicht, weil das darauf folgende "Delete" alle "S"-Sätze bis zum Ende wegputzt (egal ob aggregiert oder nicht):
Codedelete from samples where aggregate != 'A' and time <= '${DATE}'Das alles ist auch gar nicht weiter schlimm, stört aber meinen inneren Monk.
Viele Grüße von Karlheinz
-
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.
Heute sind alten Werte bis Anfang Januar 2023 als Aggregate-Werte vorhanden.
Aggregate automatisch über Nacht funktioniert also immer noch.
-
Display More
wenn das Aggregation-Bereinigung-script manuell aufrufst z.B. mit den zwei Parametern Datum(2021-01-01) und Zeitintervall(900)
z.B ./aggregate-samples-manual.sh 2021-01-01 900
das funktioniert auch und aggregiert in 15 Minuten-Zeitintervallen. (900 sind die 15Minuten in 900Sekunden umgerechnet).
Dann brauchst im Original-script (aggregate-samples-manual.sh) nix ändern.
Ja, OK, so funktioniert es natürlich auch.
Aber der Intervall wird ja in Minuten und nicht Sekunden angegeben. Zumindest in der GUI ist das so.
Ich habe im Skript /usr/local/bin/aggregate-samples-manual.sh nichts angepasst.
Ich habe das SQL-Statement manuell ausgeführt.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!
