Génial ! Yes c’est normal que la migration prenne du temps, il faut construire tout l’index.
Ta base de donnée sera aussi plus grosse, facile +20% normalement mais c’est le prix à payer pour que ça soit instantanée à afficher ! 
Ouai mais tu va pouvoir virer des features de l’historique ça fera un peu de place 
2 « J'aime »
Clairement.
J’avoue que j’ose pas encore y toucher, quelqu’un l’a déjà fait ?
Moi je le faisais en db 
2 « J'aime »
@euguuu a testé et ça marche !
Le bonus c’est qu’à chaque fois que tu retire des features de l’historique, Gladys fait tourner un petit VACUUM donc ça fait du nettoyage aussi 
1 « J'aime »
Woaw merci pour le lien, j’étais passé à côté. Je suis impatient de tester ça !!
1 « J'aime »
@pierre-gilles, j’ai essayé hier soir d’installer Gladys sur mon PC fixe, d’utiliser ma DB actuelle pour ensuite supprimer des features.
Mon PC fixe utilise un SSD NVME donc ça doit être super rapide, bien plus que mon RPi qui prend 10h pour traiter les 8Go de ma DB et supprimer les features…
MAIS, comme le service Zigbee2MQTT doit être utilisé et qu’il n’est pas lancé dans l’instance de dev que j’ai installé sur mon PC, impossible d’accéder aux périphériques pour supprimer les features.
→ As tu une astuce pour me permettre de réaliser la suppression des features sur mon PC fixe et ensuite réutiliser cette version de DB modifiée sur mon RPi ?
Salut @lmilcent !
A part taper directement dans la DB, j’ai pas d’astuce particulière 
Ca prend vraiment trop de temps sur ton Pi ?
Tu peux utiliser un programme comme TablePlus sur ton PC pour avoir une interface d’accès propre à ta DB.
Pense bien à stopper Gladys avant de récupérer/remettre ta nouvelle DB
En effet, je m’étais rendu compte que ça corromp la base sinon.
Oui je te confirme, ça tourne depuis plus de 12h, pour la suppression d’une seule feature. Mais je sais que c’est lié à deux choses : une DB de 8Go et un RPi avec une carte SD et pas un SSD.
Si tu as ça sous la main, tu peux me rappeler comment :
- Lister les features par devices
- Supprimer les données d’une feature (et je désactiverais ensuite leur stockage dans l’interface)
Sinon j’irais chercher dans le code source 
Merci
C’est ici:
Ensuite pour supprimer les états d’une feature:
DELETE FROM t_device_feature_state WHERE device_feature_id = 'cca32009-8d8f-4965-b658-bdb28eb31300';
DELETE FROM t_device_feature_state_aggregate WHERE device_feature_id = 'cca32009-8d8f-4965-b658-bdb28eb31300';
Ne pas oublier à la fin:
VACUUM;
2 « J'aime »
Merci, je savais bien que tu avais déjà fait le taf pour moi au moins une fois😂
Désolé pour la demande en doublon, et merci encore !!
1 « J'aime »
Résultats en image : une taille réduite de 50% 
Désormais ma DB fait 3.8Go contre plus de 8Go !
Niveau sauvegardes (perso) ça se ressent :
4 « J'aime »
C’est super, j’ai aussi réduit de 1.6Go ma base et que ça fait du bien les dashbord qui charge immédiatement ! 
3 « J'aime »
ça fait plaisir à lire tout ça
2 « J'aime »
On pourrait aussi cleaner la table location, on a tout l’historique de localisation mais ça sert à rien on est d’accord ?
Dans Gladys 3 on avait une fonctionnalité, on pouvait voir l’historique de ces déplacements, je trouvais ça pratique
Cette table est vraiment grosse chez toi ?
Je l’avais clean il y’a quelques semaines, je l’ai fait ce matin ( env 60000 lignes )
Je ne vois pas de use case sur l’historique de localisation.
Ok, 60k lignes c’est rien on pourra mettre à terme une tâche pour vider l’historique (un peu comme on fait avec les states: derniers 6 mois, dernière année, etc…)
Super la base de donnée a été réduite aussi chez moi et cela se ressent sur l’affichage des graphiques.
Par contre maintenant j’ai un problème à chaque modification d’un device, par exemple son nom, cela me bloque Gladys pendant plusieurs minutes. (facile 10 à 15 min)
Est-ce normal?
Je pourrais donner plus de détails et faire des tests mais en soirée si besoin.