In Gladys ist es derzeit nur möglich, Folgendes auszuwählen:
Die „aggregierten“ Zustände werden vorerst dauerhaft gespeichert.
Die Idee dieser Entwicklung wäre, eine feinere Verwaltung dieses Teils vorzuschlagen:
Und es zu ermöglichen, eine andere Dauer für die Aufbewahrungsdauer der aggregierten Zustände zu wählen:
Was haltet ihr davon? Erscheinen euch die Dauerangaben passend oder sollte ich noch weitere hinzufügen?
Ich finde das sehr gut, es gibt nicht wenig Optionen, ich gebe zu, dass ich mir nicht wirklich einen speziellen Fall vorstellen kann, der noch mehr Optionen für Zeiträume erfordern würde.
@guim31 wie lange nutzt du es denn?
3 Monate, ohne wirklich jemals weiter zurückgehen zu müssen.
Denn das Einzige, was ich von Jahr zu Jahr vergleichen möchte, ist mein Stromverbrauch, aber das erledige ich über die spezielle App meiner Solarpaneele, die sehr umfassend ist.
Okay, aber aktuell behältst du alle aggregierten Daten für immer, obwohl du sie nicht länger als 3 Monate brauchst ^^ Also ist das nicht optimal 
Daher dieses Projekt
Ich stimme direkt zu, denn die Datenbank wird immer größer und ich mache deshalb selbst ab und zu eine Reinigung, um die aggregierten Daten zu löschen.
Ja genau!
Der PR:
Es ist wahr, dass eine feinere Verwaltung auch die Größe der Backups begrenzen wird, denn zwischen 3 Monaten und unbegrenzt war es etwas knapp, es ist gut, dass diese Zeiträume hinzugefügt wurden! 
Gilt das rückwirkend?
Wenn ich zuerst unbegrenzt definiere und dann ein Jahr später auf 1 Monat, werden dann alle alten Zustände gleich mit gelöscht?
Ja, noch in derselben Nacht um 4 Uhr wird es gelöscht
« le soir » und « 4h morgens », das ist doch nicht logisch 
Danke für die Bestätigung, dass die aggregierten Daten vorerst lebenslang gespeichert werden, das hatte ich vergessen.
Eine etwas dumme Frage, ich glaube, du hast diese Frage schon beantwortet, aber Themen entwickeln sich manchmal weiter:
→ Unter Berücksichtigung, dass die Datenbanken derjenigen, die die Daten mehrere Monate (oder unbegrenzt) behalten möchten, in der Größe erheblich werden, ist es vorstellbar, auf eine Datenbank wie InfluxDB für die nicht aggregierten Sensorwerte zu migrieren?
Die Größe würde stark reduziert, aber andererseits ermöglicht man die Flexibilität, flache Dateien wie mit SQLite für diese Daten zu haben.
Manchmal gibt es Tage, die sich wie Wochen anfühlen… 
Dazu habe ich schon eine Weile ein Auge auf eine neue Datei-Datenbank (wie SQLite) geworfen, aber für Zeitreihendaten heißt das DuckDB und wird langsam zu einer Referenz. Ich habe es getestet und es ist ziemlich phänomenal, wie viel Platz es im Vergleich zu Gladys derzeit einnimmt (für Zeitreihendaten natürlich).
Ich warte darauf, dass DuckDB stabil wird, um ein Projekt damit zu starten.
Danach, InfluxDB für diejenigen, die es kennen, warum nicht eine Integration haben, aber für mich wird das keine „empfohlene“ Methode sein, sondern eher eine Integration für Experten 
Ja, du hattest das Projekt bereits erwähnt. Ich kann es kaum erwarten, bis es stabil wird, denn dann können wir alle davon profitieren:
Ich denke genauso, eher mehr, mach dir da mal nicht so viele Gedanken drüber aha
Aber das ja, das ist genau der Sinn der Sache.
@lmilcent Schau, wenn du Hoffnung willst, ich habe einen Test mit einer 4,5 GB großen Datenbank mit Sensorzuständen (verschiedene Daten) in DuckDB durchgeführt.
Das ist ein Faktor von 90, das ist schon verrückt 
(Na gut, das ist normal, es ist eine Time-Series-Datenbank, dafür ist sie gemacht)
Auch wenn man weiß, dass es dafür gemacht ist, ist es beeindruckend!
14 GB an Datenbank würden mit einem Faktor 90 160 MB ergeben. 
14 GB ist auf der Festplatte, oder? Bei Gladys Plus in komprimierter und verschlüsselter Form, wie viel hast du? Funktionieren deine Backups noch?
