Merci donc je restore, je stoppe le daemon tout de suite, je supprime les données du jour et je change les id via des requêtes avant de remettre le daemon en route …
En espérant que ça commence pas à travaillé avant que le daemon soit stoppé ou alors je vide les infos après avoir désactivé les équipements.
Quel est la tête de la requête pour modifier les id du coup ?
Ah oui mais en faisant ça je paume les données du jour si c’est pas restoré … ?
update conso_teleinfo set id_equipement = numero_new where id_equipement = numero_old
tu n’es pas obligé d’arrêter le daemon. Tu peux peux choisir de faire ton import et tes transferts entre 2 synchro ou désactiver la synchro dans le moteur de tâches. Sachant que la syncrho se fait toutes les 3 heures. D’ailleurs c’est la synchro qui pose pb par le daemon. Donc heures synchro: 3h, 6h, 9h, 12h, 15h etc …
Bon c’est encore pire, voila ce que j’ai fais :
Déjà la table conso_jour a été repeuplée :
Nouveau « delete from conso_jour » sur Jeedom V4
Mise à jour des anciens ID vers des ID temporaire :
update conso_teleinfo set id_equipement = 261 where id_equipement = 61
update conso_teleinfo set id_equipement = 287 where id_equipement = 87
update conso_teleinfo set id_equipement = 263 where id_equipement = 63
update conso_teleinfo set id_equipement = 275 where id_equipement = 75
update conso_teleinfo set id_equipement = 262 where id_equipement = 62
update conso_teleinfo set id_equipement = 201 where id_equipement = 101
update conso_teleinfo set id_equipement = 276 where id_equipement = 76
update conso_teleinfo set id_equipement = 202 where id_equipement = 102
update conso_teleinfo set id_equipement = 264 where id_equipement = 64
update conso_teleinfo set id_equipement = 203 where id_equipement = 103
je regarde la table conso_teleinfo et je constate que des données fraiches ont été insérée donc le fait de laisser tourner les équipements sur la V4 ne semble pas une bonne idée.
select distinct id_equipement from conso_teleinfo :
261
262
263
264
65
275
276
287
99
100
201
202
203
59
60
67
58
66
61
62
63
64
delete from conso_teleinfo where id_equipement=59
…
delete from conso_teleinfo where id_equipement=64
Puis passage des id temporaire vers les nouveaux id :
update conso_teleinfo set id_equipement = 58 where id_equipement = 261
update conso_teleinfo set id_equipement = 59 where id_equipement = 287
update conso_teleinfo set id_equipement = 60 where id_equipement = 263
update conso_teleinfo set id_equipement = 61 where id_equipement = 275
update conso_teleinfo set id_equipement = 62 where id_equipement = 262
update conso_teleinfo set id_equipement = 63 where id_equipement = 201
update conso_teleinfo set id_equipement = 64 where id_equipement = 276
update conso_teleinfo set id_equipement = 65 where id_equipement = 202
update conso_teleinfo set id_equipement = 66 where id_equipement = 264
update conso_teleinfo set id_equipement = 67 where id_equipement = 203
Lancer de « tout synchroniser » et voila la tête de ma conso réseau, ça fait flipper 
Note : c’est le cas pour d’autres équipements et par contre la conso d’hier semble ok sur tous (mais pas eu le courage de vérifier là du coup).
C’est dingue non ?
@superbricolo, cette table conso_jour elle sert à quoi en fait ?
On peut la vider et la synchronisation recrée équipements par équipements un résumé des données à chaque jour c’est ça ?
Un équipement, un jour, la consommation de cet équipement sur la journée ?
Donc le problème, si je supprime les données de conso_jour, reste bien localisé à conso_teleinfo c’est ça ?
Parce que si ça se trouve comme j’ai fais les updates vers les id temporaire alors que des données live étaient insérées, un équipement a peu être pris les données d’un autre.
Exemple :
ID 61 insere un index de 100
Conversion 61 vers 261 puis 261 vers 58
ID 58 insère un index de 9000 … Du coup on passe d’un index 100 à un index 9000 donc ça délire.
Je pense qu’en faisant les mêmes manip mais en ayant pris soin de désactiver les équipements avant ça devrait éviter l’insertion des nouvelles données pendant les changements d’id right ?
Il y a quelque chose que je ne trouve pas normal. Après ta première migration vers les ID temporaire, les anciens ID ne devrait plus être présent. Exemple tu renommes 61 en 261. 61 ne doit plus exister hors tu en a encore quand tu fais le select distinct. Forcément après ça se mélange.
Après je ne comprend pas pourquoi ça fait cela.
Sinon pour les données Live ça ne doit poser de problème puisque cela ne concerne que le jour J. Ce que tu restaures doit normalement pas concerner le jour J. Ou au pire tu ne devrais avoir que des problèmes sur le jour J.
La conso_jour est le récapitulatif de de toutes les données de conso_teleinfo pour chaque jour.
Si tu n’as plus conso_teleinfo et encore conso_jour, tu n’auras pas de problème car tous les graphiques, stats, etc… sont calculés à de conso_jour. Conso_teleinfo ne sert que pour le graphique Consommation du jour et pour générer conso_jour
Ça me paraît normal du coup que le select distinct remonte par exemple l’ID 61. Imagine que tu lances la requête 61 → 261, l’ensemble des 61 n’existe plus et on lance la requête suivante MAIS comme l’équipement 61 récupère les données il insère une ou plusieurs données pendant que l’on modifie les autres ID.
Je vais recommencerai demain les mêmes étapes mais en désactivant les équipements de la V4 avant de restaurer pour éviter ce phénomène.
Je croyais que le 61 était l’ancien historique de la V3
C’est le cas regarde les éléments à convertir.
61 est l’ancien id de ma conso en V3 mais c’est aussi un nouvelle id (pour frigo et prises cuisine).
C’est bien pour ça que si des nouveaux id communiquent avec Jeedom V4 après le restore et avant le changement de tout les id je ne risque pas d’avoir des résultats identiquent.
Oui dans ce cas il vaut peut-être mieux arrêter le daemon. Mais surtout cibler le renommage par date alors.
update conso_teleinfo set id_equipement = 261 where id_equipement = 61 and rec_date < '2020-04-21'
pour ne pas toucher la journée en cours (pour la date tu mets la journée en cours)
tu mets aussi la date pour le select distinct
C’est bon, l’ensemble des données cibles est bien identiques aux données de la source !! Je suis partis sur ce que j’avais dis car à force de se planter on comprend bien mieux comment l’outil agit.
Je ne sais pas si c’est une opération que beaucoup ont du faire ou vont devoir faire mais ça doit pas être trop compliqué à scripter en fin de compte.
Il faut juste permettre de saisir une table de correspondance, désactiver les équipements, faire tourner des requêtes pour migrer les ID source vers des ID temporaire, refaire tourner les requêtes pour migrer les id temporaire vers les id cible en suivant la correspondance fournie, lancer la synchronisation puis réactiver les équipements !
a+ et merci pour ton aide sur ce sujet @superbricolo
Bravo, bien content que tu ais réussi. 
Je suis dégouté !!!
Figure toi que ce matin les données ne sont plus bonnes alors qu’hier je n’avais aucune différence de consommation.
Exemple parlant avec la PAC (qui ne tourne pas) :
En V3 :
En V4 :
Alors tu vas voir maintenant on va rire…
Voilà les données issues de la V4 avec les données sauvées (jusqu’à 18:00:55) et les nouvelles données (à partir de 18:30:22).
On remarque que l’index n’est plus le même. Avant : 1993326, après 1970492.
Bon on pourrait se dire que je me suis planté donc je vais revérifier dans les 2 équipements (V3 et V4) en testant la commande et ce que je vois me glace le sang !!
V3 :
V4 :
→ Même valeur pour l’information reçu des équipements et visiblement l’information enregistré sur la V4 est cohérente (1970492)
Mais alors il est où le problème !?
Et bien en V3 il y a ça d’enregistré dans la table :
Je risque pas d’y arriver du coup ! la V3 a l’air d’enregistrer une valeur (1993326) qui n’est pas celle que la commande « Consommation » doit récupérer (1970492) !!
Évidemment c’est le cas pour d’autres circuits. Mais qu’est ce qui se passe pourquoi ce comportement en V3 ?
Ta pac, c’est un équipement paramétré type FGD212 ? SI c’est le cas il y a un index artificiel qui s’incrémente en fonction des écarts de l’index de ta commande qui apporte la valeur. Regardes la table Conso_TMP. C’est certainement ça ton écart.
C’est pour cela que ta restauration doit se faire sur les journées précédentes et pas sur la journée en cours.
J’ai bien la case « Je n’ai que la consommation de mon équipement (Exemple FGD-212) » de cochée oui. Apparemment il ne fallait pas ce n’était pas nécessaire ? Le truc c’est que c’est le cas aussi sur ma V4, j’ai re-coché les mêmes options.
Du coup pourquoi cette différence de comportement ?
V3 :
V4 :
Si je décoche ce paramètre coté V3 pour les équipements il se passe quoi ? les index de la table conso_histo reprennent la valeur non corrigé ? ça pourrait arranger les choses non ?
J’arrive pas à comprendre ce que ça changerait et même comment le faire puisque le restore doit restorer toutes les valeurs pas juste les données du jour-1
il ne faut décocher cette case surtout. Je te demandais juste pour savoir comment était paramétré ton équipement.
Cette index virtuel s’adapte quelque soit l’index passer par le module. Il est là pour compenser les cas ou l’index du module devient inférieur à celui précédent (cas des modules zwave) Et il est là pour donc toujours augmenter. Il peut donc être différent d’une installation à une autre démarrer à un moment différent. Il a pu évoluer suite à tes différents essai d’import.
Le problème que tu as c’est que à cause que tu importes des données sur la journée en cours dans conso_teleinfo et que tu as potentiellement des index <>, la conso du jour qui est le calcul des index max - min de conso_teleinfo te ressort des consommation qui n’existes pas.
C’est pour cela que je te conseille de si tu fais ton import aujourd’hui.
En V4 tu as tes données du 22, sur ton V3 tu as les données inconnu à 22/04/2020.
Tu supprimes les données < au 22 dans conso_teleinfo et conso_jour de la V4
tu exportes sur ta V3 les données <= au 21/04/2020
tu réimportes sur ta V4
Tu fais tes changements d’ID avec la condition de la date <= 21/04/2020
Comme cela sur ton jour en cours tu n’auras pas des index multiples.
Sur ma V4 en revanche je peux faire sauter se paramètre « Je n’ai que la consommation de mon équipement (Exemple FGD-212) » du coup, il ne me sert à rien c’est juste (récupération depuis un ecocompteur Legrand) ?
Comment fais-tu cela ?
Si tu as toutes les autres infos qui sont nécessaires, tu peux effectivement faire sauter cette coche.
Pour faire avec la date, c’est facile avec adminer.
Mais sinon
tu stoppes tout
tu renommes avant tes ID de la V4 en en ID temporaire
Tu supprimes les données jusqu’au 21 dans les conso_teleinfo
tu importes tes données de la V3
tu supprimes les données du 22 pour les ID de la V3
tu vides conso_jour
Et ensuite tu migres tout ton petit monde sur les bons ID
et une synchro
Je dois être bête mais en remportant les données de la V3 ça écrase bien l’ensemble de la table conso_teleinfo ? donc les données du jour de la V4 sauteront aussi, que j’ai changé les id avant ou pas ?
Non pour moi ça importe sans vider la table. Enfin je ne mettrais pas ma main à couper.
Bizarre parce que avec tout les imports que j’ai fais j’ai l’impression que si la table n’était pas vidé à chaque import il me semble que je m’en serais rendu compte.
Sinon faut utiliser adminer pour sauver les données du jour de la V4 et les réinjecter après avoir supprimé les données du jour issu de la V3.
Quel Binz 
