les commandes que j’ai mis en mode lissage historique au lieu de aucun n’ont pas bougée ni en lancant la tache a la main ni cette nuit … j’ai donc, dans les commandes les plus gourmandes la température de chaque onduleur soleil mesuré toutes les 5 min … je fouine pour regler ca
Ça n’a aucune importance, c’est le fonctionnement normal de toute base de données.
L’espace occupé sur disque, c’est juste de l’espace réservé. Aucun impact sur les perfs ni sur les backups puisque c’est un dump qui est fait ( extraction des données).
Suite aux échanges, j’ai travaillé sur un script d’audit des commandes historisees que je posterai dans la journée.
Norbert
ok, bonne nouvelle
tu as vu pour les historiques qui ne sont pas lissés ?
Oui, je ne sais pas trop du coup, faudrait creuser.
Je pense que la solution, c’est de les rebasculer dans la table History pour qu’elles soient archivées de nouveau, mais c’est pas obvious !
As tu essayé un nettoyage de la base de données ?
Norbert
oui, j’en étais a me demander pour les passer sur une autre commande et rebelote … bof aussi
je fouine, merci de l’aide
Bonjour à tous,
Pour info et cordialité, je suis vos échanges ayant eu récemment les mêmes soucis 
Des mécanismes d’audit et d’alerte sur la mauvaise utilisation que l’on fait lorsqu’on débute de l’historisation manquent cruellement.
Ma jeedom date de 2016 et de migration en migration assurément des choses se sont entassées ainsi que ma mauvaise compréhension et utilisation du paramétrage des commandes.
Bien cordialement
Même pas le temps de le penser que c’est fait, quel talent 
Je viens de la passer et c’est vraiment excellent.
Cela mériterait d’être intégré dans le core en section Outils du Menu Réglages Système.
1 « J'aime »
J’ai eu le cas sur une de mes commandes de remettre à plat le lissage
Procédure (pour la commande 637, donc à personnaliser dans les 2 requetes sql)
1 - Recopie des valeurs de la commande de historyArch vers History
INSERT INTO history (cmd_id, datetime, value) SELECT cmd_id, datetime, value FROM historyArch where cmd_id = 637;
2 - suppression des valeurs dans historyArch
DELETE FROM `historyArch` WHERE `cmd_id` = 637
3 - relance de l’archivage via le gestionnaire des taches (ou attendre 5h du mat’
Il va ainsi via la table history recalculer les archives avec le nouveau lissage pour les reinserer dans historyArch
Norbert
oui, je fais un truc de ce genre, un boulot de fou, bref …
je remarque que les tables mal archivées sont celles qui ont une valeur a la con dedans, genre un texte ou vide ou autre
une idée avec adminer ou autre pour détecter tout ce qui est autre qu’un nombre ?
@superbricolo tu peux me ré expliquer l’archivage stp
si je coche « sauvegarder les valeurs de plus de 12 mois », je ne pourrais plus voir le détail d’une journée d’il y a 2 ans (x W à 7h00 et y W à 7h05)
par contre, dans les stats, je pourrais encore ventiller par jour si je le souhaite ou il y a une manip a faire avec la bdd archivée ?
autrement dit, puis je me revoir toutes les données par jour, semaine ou mois depuis 2019 dans les stats ?
je sais que je suis un maniaque de la conservation des données !
edit : et il faut cocher « Epuration et sauvegarde automatique de conso_teleinfo » ??
oui c’est bien cela
Oui tu pourras toujours ventiler par jour sans rien faire
Oui
Oui pour avoir un épuration tout les 1er du mois
quelle clarté !!! merci !!