Je fais suite à un sujet que j’ai ouvert hier (Lixee + JeeZigbee) concernant ma migration des différents éléments de ma config de Zigbee vers JeeZigbee.
J’ai entamé la migration de prises à remontée de consommation de marque NOUS, mais je pense que j’aurais dû m’y prendre autrement. Je m’explique : Au lieu de remplacer dans l’outil « remplacer », j’ai repris la configuration de chaque élément dans le plugin conso et ai modifié les id inconnus (suite à la suppression des prises NOUS dans Zigbee) pour y mettre les infos issues de JeeZigbee. Ma config pour l’un de mes prises ressemble à ceci :
En revanche, j’ai un gros souci sur les stats qui, je pense, ont repris la valeur de consommation stockée dans la prise et l’ont appliqué à) la journée d’hier :
J’ai cherché dans les outils de correction de données du plugin Conso, mais je ne vois pas comment faire pour supprimer cet enregistrement en particulier …
J’ai également exécuté la requête update conso_teleinfo set hchp = hchp - 903600 where id_equipement = 311 and rec_date = '2024-03-26' afin de corriger les données du jour en cours …
Synchro. Tout semble OK. Je fais de même pour les autres prises NOUS.
Alors oui, l’update fonctionne bien. Les données sont bien corrigées, mais les données que je récupère des prises sont fausses donc je repars sur des données de télémétrie erronées :
Tant que les prises transmettront des données fausses, mon problème reviendra en fait …
As tu une idée ?
C’est pas grave, ce qui compte c’est l’écart. De toutes façon tu n’es pas en mode FGD212? Et ton pb ne vas pas revenir puisque maintenant c’est parti comme ça. C’est si tu touches avec la requêtes une journée en cours que tu risques de reprovoquer le pb
Bonjour @superbricolo , désolé, je ne suis pas sûr de bien tout comprendre …
Qu’est ce que le mode FGD212 ?
Le fait est que les stats sont totalement faussées :
Ce que je ne comprends pas, et là, cela ne concerne pas le plugin Conso, c’est cette différence entre les données exposées via le plugin Zigbee et celles exposées par le plugin JeeZigbee qui expliquent cette différence lors de la migration des prises …
L’avantage est que tu peux renseigner une variation max entre 2 mesures ce qui permet de d’ignorer des cas comme tu as eu. Dans ce mode SuiviConso gère un index virtuel qu’il incrémente en fonction de l’écart entre la dernière mesure et la mesure précédente.
En tout cas ton index étant ce qu’il est maintenant, il ne faut pas bricoler les journées autres que celle ou il y a l’anomalie surtout sur la journée en cours, car tu vas venir modifier les données jusqu’à l’heure de l’instant t, mais les données suivantes vont continuer à s’enregistrer avec le nouvel index, et donc cela va générer un écart .
C’est ce qui as du se passer. Tu as corriger le 25. et tu as fait aussi le 26 alors que la journée n’était pas terminée. Tu as donc recréer le même cas que le 25.
Pour la différence des infos entre plugin, je ne peux pas te dire.
Merci pour toutes ces infos.
Mes prises NOUS sont configurées en FDG-212, mais je n’avais pas défini de variation MAX …
Donc, pour conclure, je n’ai aucune solution pour palier le problème de stat complètement fausse sur une journée …c’est dommage, car je perds tout l’intérêt de pouvoir comparer les données d’un mois à un autre ou d’une année à une autre …
Etrange en effet cette différence. Les données sont très proches du simple au double. J’ai le même souci pour mon Lixee que j’ai également migré.
On est bien d’accord que si je corrige de nouveau les données du 26, je vais déporter le problème sur la journée suivante puisque les données remontées par la prise NOUS sont supérieures à leur valeur réelle. Un peu comme le cas que j’avais remonté où j’avais updaté toutes les données le 26/03/24 à 23:07, toutes les données suivantes reprenant par conséquent les données transmises par la prise …
En fait, je pense même que le mieux serait de définir la consommation de l’équipement Conso à #[Cuisine][Prise réfrigérateur][Consommation]# - 537 950 pour être sûr que la valeur récupérée par le plugin Conso soit la bonne. C’est pas très propre à mon sens, mais je ne vois pas comment faire autrement … sauf si je passe à côté de quelque chose d’évident.
une qui contient l’ensemble des données de tous les jours et chaque minutes (environ)
une qui maintient les données pour chaque jour et calculée à partir de la table précédente
Quand le plugin veut calculer les données du jour (donc le 27 après minuit pour la journée du 26) regarde quel a été la valeur minimum de la journée et la valeur maximum. Il fait la différence et enregistre ça dans la table « jour » pour la journée du 26.
En modifiant les données du 26 APRES le 26 les données du 26 ne seront plus modifiés donc il n’y aura plus de risque que la différence min/max fausse le calcul.
Comme superbricolo expliquait, le problème c’est que tu as modifié les valeurs pendant la journée du 26. Donc comme l’ensemble des données de cette journée n’avait pas encore été enregistré, le même problème s’est représenté.
En résumé, si tu as une journée J qui pose problème, attend le lendemain (J+1 minimum), corrige les données de J et fait un « tout synchroniser »
Merci pour toutes ces explications. Je comprends en effet maintenant la raison pour laquelle il ne fallait effectuer la requête d’update uniquement sur la journée qui posait problème …
En tout cas, je pense avoir corrigé les différences de données sur mes prises NOUS.
J’ai encore un ou deux soucis avec mon Lixee (Le plugin Zigbee remontait par défaut les données avec 3 décimales tandis que JeeZigbee remontait sans décimale, ce qui a créé de gros écarts dans les bases).
Merci encore à tous pour votre aide.
En résumé, si tu as une journée J qui pose problème, attend le lendemain (J+1 minimum), corrige les données de J et fait un « tout synchroniser »