Hello
Encore moi avec mes sempiternelles questions
Dans l’attente de mon TIC Linky, j’avais créé un index estimatif basé sur la consommation Enedis à J-1 que j’avais augmentée d’une grosse journée pour être large, et j’incrémentais un compteur HP et un compteur HC avec la conso de la veille appliquée sur le jour même.
J’ai enfin reçu mon TIC hier et je voudrais repasser en réel, en essayant de conserver tout le mois de décembre (je n’avais que quelques jours en novembre).
J’ai donc imaginé de lancer des sql sur conso_teleinfo, et conso_jour en faisant, jour par jour, un j-1 dans les date (en commençant pas le 1er décembre) et en soustrayant des hchp et hchc le différentiel entre l’ancien index prévisionnel à aujourd’hui et le dernier relevé en réel à 23h59 hier.
Je devrais avois ainsi en J-1 le bon index Enedis récupérée à J.
Ensuite, je supprime les journées d’hier et d’aujourd’hui en double dans chaque équipement et corrige les id.
Est-ce faisable ou est-ce que je pédale dans la choucroute ?
Au niveau SQL, je m’en sortirai si j’ai la réponse aux questions suivantes :
- Dans conso_teleinfo, il y a un timestamp. Si je fais un -1 dans les dates, le timestamp ne sera plus bon. Faut-il le modifier ou est-ce qu’il n’est utilisé que pour le calcul de la date et de l’heure une fois pour toutes ?
- Dans conso_jour, faut il mettre à jour les 2 index max et min, plus le hc et le hp en plus de la date et période ? (et le timestamp si besoin) ? Ou bien des choses vont se recalculer ?
Nota : Je ne risque pas grand chose si je me plante, au pire je perdrai mon historique que je n’aurai de toutes façons pas si je ne fais rien.
Merci d’avance
Hello
Du coup j’ai fait ma manip dans mon coin, ça semble bon.
Dans conso_teleinfo, j’ai modifilé la date (-1), le hp (-x) et le hc (-y).
Dans conso_jour, j’ai modifié la date (-1), la période (pour correspondre à la date), les idx_min et _max de hp (-x) et hc (-y).
Ensuite j’ai supprimé les données de la journée d’hier sur le nouvel équipement, et ai changé l’id de l’ancien pour celle du nouveau dans les 2 tables.
Bien entendu, j’ai désactivé l’ancien équipement et changé le parent pour tous les fils et filles.
Je n’ai donc pas touché au timestamp, j’espère que ça ne va pas avoir un impact pour des calculs ultérieurs.
Je suis preneur de l’info.
Merci d’avance
J’ai quand même du cafouiller quelque part, mais je ne sais pas où.
Finalement, les timestamp doivent avoir une importance
les journées du 6 et du 7 se mélangent dans la base en fonction de leur timestamp. Uniquement ces 2 journées là les lignes du 6 et du 7 s’alternent en fonction de leur horaire…
En journalier, la journée du 6 reste correcte mais j’ai 1,5 fois la valeur sur le 7.
Je ne sais pas corriger ça, du reste je ne sais pas corriger un timestamp en SQL
Merci
Je te réponds ce soir, si je peux pour te trouver un bout de requête pour corriger tes timestamps
Hello
Merci beaucoup.
Je ne sais pas si ça suffira, il y a des valeurs étranges, en plus, dans la table jour, avec les données HP max du 7-12 bien supérieures aux données min du 8-12.
Enfin je peux essayer.
Il me manque un info essentielle : est-ce que la table jour se construit à partir des données de la table teleinfo, ou est-ce qu’elle se construit toute seule à partir des données fournies ?
Si c’est le 1, alors inutile de chercher à comprendre ce qui se passe dans la table jour, je dois me focaliser sur la table teleinfo.
Merci encore
effectivement la table jour se construit à partir de conso_teleinfo. Et tu peux forcer cette maj avec la synchro dans l’onglet outil du panel
OK, ça limite un peu le champ de recherche.
Je n’arrive pas à comprendre pourquoi ce sont les données du 6 et du 7 qui sont mélangées, et pas celles des jours précédents. Si les timestamp étaient les seuls en cause, pourquoi ne serait-ce pas le foutoir partout ?
Mais est-ce que le plugin exploite les timestamp ou les dates ?
Parce qu’en affichage, c’est juste peut être - je ne sais pas pourquoi - parce que les données du 7 étaient dans l’équipement à l’origine et que les autres y ont été transférées.
J’ai lu que les timestamp « MariaDB » en début de table étaient de zones spécifiques qui s’implémentaient automatiquement à la création de l’enregistrement. Du coup, je ne sais même pas si elles sont modifiables.
Recréer manuellement toute une journée avec 3 enregistrement (début, implémentation en une fois de l’index d’une journée, fin), c’est faisable ?
Merci
Pour info j’ai essayé le sql sur la journée du 24/11/2021 (qui peut être perdue).
update conso_teleinfo set timestamp = timestamp - 86400 where id_equipement = 1232 and rec_date = ‹ 2021-11-24 ›
Je reçois le message :
[MySQL] Error code : 23000 (1062). Duplicate entry ‹ 1637708431 › for key ‹ timestamp › : update conso_teleinfo set timestamp = timestamp - 86400 where id_equipement = 1232 and rec_date = ‹ 2021-11-24 ›
Dans ce que je comprends, le timestamp sert en fait de clé unique (ce qui est bizarre de mon point de vue parce que ça voudrait dire qu’on ne peut pas créer deux enregistrements de la même table à la même seconde…)
J’ai fait la même requête pour un enregistrement unique à une heure précise ( rec_time = ‹ 01:05:22 ›) , et c’est passé. Ca n’est donc pas un problème de requête.
Je ne connais pas bien du tout MySql, j’imagine qu’en dupliquant la table pour tous les champs sauf les timestamp, en la triant pas date, on obtiendrait des timestamp corrects. Mais je ne sais pas faire et surtout, je vais arrêter de tout casser avec mes paris.
Est-ce que la solution de rebâtir la journée du 6 et du 7 avec des index globaux et valides est faisable ? Et comment ?
Merci d’avance
Le plus simple: Tu vires les données dans conso_teleinfo pour le 6 et le 7 et tu corriges tes conso dans conso_jour. Et du coup cela ne bougera plus.
Ah, la mise à jour de conso_jour par conso_teleinfo ne marche que dans un seul sens ? S’il n’y a plus de données la la seconde pour une journée, ça ne va pas effacer les infos de conso_jour ?
Merci
non cela ne vas rien faire. Il ne synchronise que si il y a des données pour la journée concernée
OK, donc maintenant c’est bon, après un refresh…
Je surveille…
Merci de ton aide