Nettoyer rapidement des équipements

Hello,

Suite à un gros souci sur Jeedouino qui s’est incrémenté de valeurs totalement aberrantes au niveau compteur, je me demande s’il n’y a pas lieu de prévoir quelques modifications côté suivi conso :

  • la première, pouvoir supprimer ou modifier facilement une zone « temps » d’un équipement. La recherche d’erreurs ou le correcteur ne sont pas efficaces (ou le sont pour une valeur par ci par là). Très vite il faut passer par Adminer et ça devient d’un compliqué même pour moi qui le maitrise.

Entre la table history et la table history_arch, on s’y perd vite.

Exemple dans mon cas. Le compteur est complétement faux et aucun rattrappage possible mise à part le mettre à 0. Le problème, c’est que le mettre à 0 maintenant (conso jour, prix jour, conso veille, prix veille, semaine, mois etc) maintenant est impossible car la valeur du compteur est complément dans les choux.
On est passé d’un compteur de 1 à 6kw à des millions… pour imager.

Qu’une envie. Supprimer toute la zone de l’équipement vu qu’elle est perdue.
Exemple de la semaine en MWh !

Alors qu’avant le bug Jeedouino tout était ok (13/05) :

D’ailleurs à choisir, c’est même une copie des semaines précédentes qu’on a envie de faire non ?
Avoir la possibilité de copier le même motif en cas de gros souci : veille, jour, semaine, mois…

Là je suis bloqué complètement et je dois attendre le début du mois prochain pour corriger de manière estimative…

  • la seconde serait justement de prévoir une couche pour éviter ces erreurs. Je ne suis pas dans qui doit le faire, mais je commence à me dire que les erreurs de comptage sont « fréquentes » façon de parler. @revlys fait son possible, mais si le compteur part en vrille, il faudrait éviter ce phénomène pour éviter de polluer à ce point les données de comptage.

Par exemple : sur la configuration de l’équipement, mettre sa puissance nominale ou maximale à la minute pour obliger un max ou sa consommation maximale d’une journée par exemple.
A défaut, je vais me résoudre à le faire par scénario.
Je le fais déjà pour le PV par exemple pour les pulses parasites la nuit alors qu’il n’y a pas de production.
Idem pour l’eau chaude si je suis en dérogation.

Votre avis, idées ?

J’ai ajouté un contrôle pour les modules type FGD212 qui vérifie la valeur max entre 2 mesures paramétré à l’équipement. On pourrait l’ajouter pour les équipements type téleinfo.

Si tu veux, je peux t’aider à corriger tes valeurs. Cela me permettra de voir ce que le correcteur pourrait avoir comme fonctionnalités supplémentaires

Hello, euh… Tu veux un accès à mon jeedom ?

Ou plutôt un fichier avec les données des jours faux de conso_teleinfo. un export que je pourrais recharger dans ma base pour faire le nettoyage en test. → Si c’es jt possible pour toi. Sinon effectivement ce sera un accès à ton Jeedom

Hurmf, je vois et je sors ça. Ça doit être possible par adminer

Bon, comme j’ai foiré ma tentative de nettoyage, j’ai cloné ma VM et j’ai restauré une sauvegarde au matin du jour où j’ai tenté de faire quelque chose. Du coup, tu n’auras les données que jusqu’au 22 matin. Mais mes données à moi vont bien plus loin. Je ne sais pas trop comment faire du coup.

En passant par adminer, je t’ai isolé la taille conso_teleinfo :

  1. partie PV. Le compteur est passé en carafe depuis le 18/5 à 16h05/10 :

jusqu’à ce que je réinitialise le démon pour qu’il recompte correctement le 20/5 vers 9h :

conso_teleinfo_PV1545.txt (262,8 Ko)

  1. pour l’eau chaude, malheureusement je m’en suis rendu compte tard. Du coup, je n’ai aucune idée du début du souci sur le compteur d’eau chaude car je ne garde que 7 jours glissants sur la valeur du compteur (sinon bonjour l’historisation !).

A priori, tout était OK depuis le 22/05 où j’ai réenregistré le démon.

Forcément si je regarde le prix jour total (7j histo), je n’en ai aucune idée… idem pour la veille.
A la semaine, pareil !
Au mois… le problème semble être apparu le 13/05 au matin.

Conclusion, il faudrait « copier » une semaine type de chauffe (j’ai des consignes différentes), avant le 13/05.
Pareil pour le PV je présume ?

J’ai fait une recherche sur la table conso_teleinfo sur l’équipement 554 (qui correspond à celui de l’eau chaude) c’est ce que tu voulais ?

conso_teleinfo_ECS554.txt (664,3 Ko)
Au passage, j’ai une autre doléance qui est très casse pied avec l’utilisation des fonctions php. Quand on fait un maxbetween ou last ou autre sur une donnée historisée d’un élément suivi conso (prix jour, conso veille, idem semaine, mois ou autre par exemple), si la donnée n’existe pas, la valeur restituée est « vide ».

Du coup, derrière si on a des calculs, tout part aux fraises. A la limite, mettre un NA ou 0 ne serait pas mal. En théorie, il me semble même qu’il faut sortir -1 ou -2.

Par exemple, sur un équipement radiateur SDO, la commande :

((maxBetween(#[Energie][Chauffage SdO][Conso Veille TOTAL]#,today 00:00, today 23:59) == NULL) ? 0 : maxBetween(#[Energie][Chauffage SdO][Conso Veille TOTAL]#,today 00:00, today 23:59))

Pourtant quand je passe par le testeur d’expression, il me donnera 0. Le ternaire est là car j’ai essayé de le détecter mais rien n’y fait, je ne sais pas le détecter.

Alors que dans le log du scénario, cela reste vide. vide ?! car le chauffage n’a jamais démarré dans l’historique du plugin. Et à mon avis, pas de démarrage, pas de valeur à 0 pour de « vrai ».

Bon j’ai fait la partie PV. J’ai réussi je pense à déduire des consommations de tes valeurs erronées.
J’obtiens pour le:
18/05 10010 Wh
19/05 5187 Wh
20/05 9128 Wh
21/05 10064 Wh

Dans adminer tu executes:

delete from conso_teleinfo where id_equipement = 1545 and rec_date between '2020-05-18' and '2020-05-21'

puis ensuite, tu exécutes la requêtes contenus dans le fichier suivant:
conso_teleinfo_PV1545_new.txt (262,4 Ko)

Ensuite une petite synchro et ça devrait être bon

Je suis bête… J’ai la synchro api pour le pv pour copier les données !

Voici le fichier pour l’équipement 554: ( A exécuter comme requête dans adminer après le delete
conso_teleinfo_ECS554_new.txt (550,8 Ko)

un petit delete auparavant:

delete from conso_teleinfo where id_equipement = 554 and ((rec_date between '2020-05-13' and '2020-05-21') or (rec_date = '2020-05-22' and rec_time <= '06:15:04'))

Et ensuite une synchro pour mettre à jour conso_jour

Je ne t’ai pas oublié, je vais voir demain !
Merci !

Hurmf, j’ai fait. A priori, OK.

Je relance une synchro totale par le plugin dans le tableau de bord.

Et … je m’inquiète. Car je n’ai quelques jours de données sur tous mes équipements comme si cela avait été purgé. Là j’ai un mega coup de stress…

L’élec, le pulse, l’eau etc tout semble perdu avant le 22/5.

Ce qui m’inquiète particulièrement c’est que si je cherche à voir mes données au 1/5 alors que j’en avais depuis 2/3 ans… bein c’est vide.

Je ne pige pas car je n’ai rien fait de plus que ta requete et l’import en txt…

Bon, je me stresse moins. Au pire je monte un backup et on doit pouvoir extraire la table teleinfo globale…
Mais je ne comprends pas pourquoi tout a disparu !

J’ai fait l’update sql pour l’eau chaude, pareil… on dirait que tu as corrigé en partie mais pas tout. Mais là encore, j’ai perdu tout avant.

Je viens de voir que ma table teleinfo save est plus vieille… j’attends ton retour !

C’est quoi l’import que tu as fait? . Je penses que c’est cela qui à vidé tes données. Le fichier txt, il faut l’ouvrir sur un éditeur genre notepad++ et fait un copier coller vers Adminer pour exécuter cette grande requête qui insère des données. Si tu as fait un import du fichier txt avec Adminer, je penses que cela à vider ta table.
Sinon effectivement avec un backup tu pourras restaurer ta table

Effectivement, j’ai fait un import du TXT puis voyant aucun changement, j’ai ouvert et fais un copier coller.
Le problème c’est que le volume de texte à traiter m’a fait planté adminer/navigateur lors du traitement (d’expérience je m’en doutais donc j’ai préféré au début envoyé le TXT).

Du coup, je ne sais pas trop comment procéder ?

J’ai une VM doublée de Jeedom que je peux restaurer à hier matin par exemple avant cette manipulation.

  1. Je passe par le plugin de cette VM double pour télécharger l’historique ?
  2. Ou je connecte ma VM Jeedom de production au backup ?
  3. Ou je fais tout à la main par adminer ?

Moi je ferais mon backup en passant par le plugin de ma VM double.
Ensuite dans mon fichier généré, je supprime la partie qui vide la table.
Puis je réimporte du plugin sur ma machine de prod. Comme cela tu ne perdras pas tes données du jour.
Fait une sauvegarde avant de ta prod au cas où.

Sinon pour les fichiers txt, le copier coller doit marcher. Je l’avais testé avant de te renvoyer les fichiers. Sinon tu découpes ton fichier en récupérant la ère ligne.

Je ne suis pas sûr de comprendre.
Je prends mon backup à jour sur mon second jeedom.
Je génère où, quoi ? Par le plugin, par adminer ?

  1. Tu récupères ton backup de ton second Jeedom (via le plugin) (bouton télécharger)

  2. Ensuite tu décompresses ton fichiers (si tu as choisi le format compressé)

  3. Tu ouvres le fichiers.sql avec un éditeur et tu supprimes la partie sélectionnée

  4. Tu recompresses au format gzip (si tu as choisi le format compressé)


    Pour les étapes 2, 3 et 4, si tu ne sais pas faire, envoies moi le fichier et je ferais la manip.

  5. Tu fais envoyer ta sauvegarde ainsi maj vers ton jeedom de prod (bouton envoyer)

  6. Puis bouton restaurer.
    Tu auras alors les données de ta sauvegarde + les données des jours suivants qui n’auront pas été effacées.

  7. Ensuite tu peux recommencer les manips de correction sans faire d’import

J’ai bien fait ce que tu m’as dit y compris le nettoyage du fichier SQL comme suit, sa compression.
J’ai chargé le backup, restaurer (d’ailleurs le bouton continue à tourner même quand le log indique que c’est OK/fini).

****************Import de l\historique *********************
Restauration de  l'historique save_2020-05-29_14_40_43.sql.gz
gunzip < /var/www/html/plugins/conso/core/class/../../ressources/backup/save_2020-05-29_14_40_43.sql.gz | mysql  -hlocalhost -ujeedom -pxxxxxxxxxxxxxxxxx jeedom
Restauration en cours ......
Restauration Terminée
[END CONSO_HISTORIQUE SUCCESS]

J’ai beau tenté une synchro, les données restent vides dans les graphes passées une semaine…

Je te donne mon fichier :

save_2020-05-29_14_40_43.txt (402,4 Ko)

A renommer en save_2020-05-29_14_40_43.sql.gz

ce qui est assez logique car le fichier démarre uniquement en date du 20/05… en data. Je vais voir et creuser de mon côté sur le second jeedom

Hurmf, il y a un truc bizarre sur cette VM de backup.
j’ai beau restauré ma sauvegarde en date d’il y 4 jours, 3 jours, 2 jours, 1 semaine, 2 semaines ; les données manquent. Rien avant 1semaine globalement.
Comme si le fait qu’à partir du moment où le plugin a été corrompu qu’importe sa restauration, il reste corrompu.
J’ai vérifié que ce soit par l’interface dashboard ou en exportant une sauvegarde les fichiers présents dans le SQL ne sont que de quelques jours avant et pas mes 3 dernières années.

Exemple : je restaure un backup de 23. Bien avant notre discussion donc, il y a 6 jours.
Mes modifs et erreurs datent du dimanche soit le 24.

le dashboard donne :

et on voit la date du 29 malgré la restauration ! Fort…

Je vais restaurer une image snapshot de ma VM de production.