Oui je sais faire je regarderai ça ce soir, je ne suis pas chez moi la.
Par contre plutôt que de modifier les data en direct perso je créerai un virtuel, recopierai l’historique et ferai mes tests dedans
Ben techniquement non 2025-07-08 00:00:00 et 2025-07-08 23:59:59 c’est le même jour
Effectivement dans ce sens cest good 
ChatGPT me propose la commande SQL suivante :
UPDATE historyArch
SET datetime = DATE_FORMAT(datetime, ‹ %Y-%m-%d ›) + INTERVAL ‹ 00:01:00 › HOUR_SECOND
WHERE cmd_id = 8112;
Je testerai plus tard car j’ai du monde chez moi ce soir.
Merci encore en tout cas !
Par contre je ne sais pas comment on copie l’historique d’une commande vers une autre…
— Trouvé ----
Bon c’est rapide en fait :
- Virtuel avec commande numérique créé
- copie de l’historique de mon conso d’eau vers cette nouvelle commande
- Dans la vue historique j’obtient le même bug sur le regroupement en somme par mois
— A few moment later ---------
Faux espoir : j’ai bien réussi à tout updater à 00:01:00 mais ce n’est pas mieux, j’ai toujours la même erreur.
J’abandonne pour ce soir !
Il faudrait que sur cette nouvelle commande tu supprime les données qui sont avant 2025 pour vérifier si c’est ok.
Est-ce que ça pourrait être lié au changement d’heure et/hiver du 30 mars ?
Le soucis ne serait pas aléatoire mais permanent.
Je chercherai plus coté design en dupliquant, puis en supprimant éléments par éléments.
Peut-être quelque chose qui reste en mémoire, le soucis intervient peut-être lorsque tu vas d’une page x vers le design …
je n’ai pas tout lu et je ne suis pas certain que cela corresponde mais j’ai parfois eu des soucis lorsque je faisais des regroupement dans la vue historique de la commande qui servait aussi à afficher des graphiques dans un template
Par exemple: Graphique ne fonctionne pas, et valeur incorrecte - #12 par Noyax37
En fait on dirait que le type de regroupement n’est pas juste une option d’affichage mais que ça suit la commande.
On dirait que jeedom se souvient que sur telle ou telle commande il y a eu une demande de regroupement (par ex somme par mois) et du coup quand on lui demande un nouveau graphique il l’applique par défaut. Ce qui fait qu’il est parfois compliqué d’afficher la même commande selon deux types de regroupements
Ca n’explique cependant pas les erreurs de calcul…
Bonjour,
Il manque les valeurs de la table history. Elles sont utilisées par les graphiques.
C’est pour cela qu’en groupement en Somme par mois, le dernier mois est faux. Il y a une valeur qui vient d’history et une de d’historyArch qui sont additionnées. Dans ce cas, il faut utiliser Max par mois s’il n’y a qu’une seule valeur par mois.
Hello,
Le soucis est sur les mois précédents, au pire vu que c’est une valeur par jour, il manquerai simplement la dernière valeurs qui est dans history.
Donc mystère…
Hello et merci de ton aide !
Peux-tu m’en dire plus sur le fonctionnement de l’historisation stp ?
Je comprends qu’il y a deux tables : history et historyArch ?
En tout cas la commande SELECT * FROM history WHERE cmd_id = 8112 ORDER BY datetime DESC ne retourne rien…
Et SELECT * FROM history WHERE cmd_id=8112 non plus. C’est normal d’après vous ?
Normale a mon avis le cron du plugin intervient avant le cron history archive, verifiable via le moteur des tâches. Donc ta valeur quand elle est récupéré par le plugin reste quelques heures en base history avant que le core la bascule dans historyArch.
1 « J'aime »
Sur les mois précédents à part des valeurs en double, dans une des 2 tables, je ne vois pas ce qui pourrait causer le pb.
Mon explication ne concernait que la dernière valeur.
1 « J'aime »
Valeur en double on y a pensé mais le soucis est aléatoire, donc si valeur double le graph serait en permanence faux.
Alors oui le dernier mois pour le dernier jour peut être faux.
J’ai donné cette requete sans history par souci de simplification, je vais donc en donner une ci dessous qui donne le résultat des deux tables. Mais comme l’a dit @Phpvarious ça n’explique pas les soucis rencontrés sur les mois précédents …
Donc pour les puristes :
SELECT * FROM history WHERE cmd_id = 2226 UNION SELECT * FROM historyArch WHERE cmd_id = 2226 ORDER BY datetime DESC
En remplaçant bien entendu aux deux endroits 2226 par l’id de la commande
1 « J'aime »
Les nouvelles valeurs sont traitées (lissage, min, max … ) puis stockées dans la table history.
Dès qu’elles ont un certain age,
elles sont reprises chaque jour par la tache archive qui les place dans la table historyArch.
Très intéressant merci !
En simplifiant beaucoup, history est la table de l’historique de la journée en cours historyArch des jours précédents.
Toutes les nuits un traitement vient passer les données de l’history vers la table d’archive.
1 « J'aime »