Oui exactement !
La PR:
2 « J'aime »
C’est vrai qu’une gestion plus fine limitera la taille des sauvegardes également car entre 3 mois et illimité cela faisait court, c’est bien d’avoir ajouté ces durées ! 
Donc c’est rétroactif ?
Si je définis d’abord illimité, et que 1 an plus tard je définis à 1 mois, alors tous les anciens états seront supprimés dans la foulée ?
Oui le soir même à 4h du matin ça sera purgé
1 « J'aime »
« le soir » et « 4h du matin », c’est pas sensé être logique 
Merci pour la confirmation que pour l’instant les données aggrégées sont gardées à vie, j’avais oublié.
Question plus ou moins bête, je crois que tu as déjà répondu à cette question, mais les sujets évoluent parfois :
→ En prenant en compte que les bases de données de ceux qui souhaitent garder les données plusieurs mois (ou illimité) deviennent conséquentes en taille, est-ce imaginable de migrer vers une base de données type InfluxDB pour les valeurs des capteurs non aggrégées ?
La taille serait grandement diminuée, mais en revanche on permet la flexibilité d’avoir des fichiers plats comme avec SQLite pour ces données là.
2 « J'aime »
Des fois Il y a des jours on dirait des semaines… 
1 « J'aime »
Là dessus, je zieute depuis un bout de temps sur une nouvelle DB fichier (comme SQlite) mais pour des données time-serie, ça s’appelle DuckDB et ça devient un peu une référence. J’ai testé et c’est assez phénoménale l’espace que ça prend vs Gladys actuellement (pour des données time-serie bien-sûr)
J’attendais que DuckDB passe en stable pour lancer un chantier dessus
Après, InfluxDB pour ceux qui connaissent, pourquoi pas avoir une intégration, mais pour moi ça ne sera pas une façon « recommandée » de faire mais plutôt une intégration pour les experts 
1 « J'aime »
En effet tu l’avais déjà mentionné ce projet. Vivement qu’il passe en mode stable, car on pourra tous en profiter :
- Moins d’accès SSD / MicroSD sur RaspberryPi je pense
- Possibilité de garder toutes les données de nos capteurs sur plus d’un an, sans soucis d’espace disque
- Des sauvegardes côté Gladys Plus optimisées (ma DB fait plus de 10Gb !!)
Je pense tout autant voir plus, te fais pas trop de plan là dessus aha 
Par contre ça oui carrément, c’est tout le but.
1 « J'aime »
@lmilcent Tiens si tu veux de l’espoir, j’avais fais un test avec une DB de 4.5GB d’états de capteurs (des données variés) importé dans DuckDB.
- Dans Gladys: 4.5GB
- Dans DuckDB: 50Mb
On est sur un facteur 90, c’est assez dingue 
(Bon après, c’est normal, c’est une BDD time-serie, c’est fait pour ça)
3 « J'aime »
Même en sachant que c’est fait pour, c’est impressionnant !
14Go actuellement de base de données donnerait 160Mo avec un facteur 90. 
1 « J'aime »
14Go c’est sur disque on est d’accord? Côté Gladys Plus en compressé + chiffré t’es à combien ? Tes backups passent encore ?
Oui on est d’accord 
3.25 Go de backup !
C’est vrai que si on garde coché toute l’historisation cela fait conséquent, j’ai pour l’instant une dizaine de capteur et il prennent déjà 350Mo, après comment sont sauvegardées les données (à chaque changement de valeurs, selon un timer) ? Est-il
nécessaire de tout sauvegarder ou seulement selon des seuils (la pile par exemple c’est seulement si elle passe en dessous d’un seuil que cela peut être intéressant de connaitre la durée ou alors par palier 90% 85% etc) il y a des variations d’usages (température, humidité etc) et des variations de maintenance (batterie tension intensité etc) les deux couvrent pas les mêmes besoins donc la sauvegarde des données pourraient être différentes!
C’est ouf ces différences de poids, comment est-ce possible ?!
Ca serait long à expliquer mais ce qu’il faut retenir c’est que côté Gladys pour arriver à un requêtage assez rapide de données time-serie, on duplique la donnée plusieurs fois (les fameuses données agrégées), et on utilise des index qui sont eux aussi de la donnée dupliquée. Mis bout à bout, ça fait beaucoup de duplicata
Dans une base de donnée timeserie, le format de donnée est différent et est optimisé pour des données temporelles, donc pas besoin de faire les pirouettes qu’on fait avec une DB relationelle. En plus de ça, une DB time-serie utilise des algos de compression pour stocker la donnée compressée et peut de-compresser à la volée à la lecture.
Après, tout ça a des tradeoffs, ces base de données timeseries ne sont bonnes qu’aux données temporelles, donc si un jour on implémente ça dans Gladys, ça sera uniquement la table « t_device_feature_state » qui partira dans cette DB, le reste restera dans SQLite (qui est ultra-robuste pour tout ce qui est relationnel)
3 « J'aime »
Cette fonctionnalité est disponible dans Gladys Assistant 4.31 ! 
Je ferme ce sujet pour libérer les votes, n’hésitez pas à créer un autre sujet en cas de bugs sur cette fonctionnalité