Valeurs des index doublées

[MarcDesmilles]

Bonjour,
Suite à un plantage de mon Jeedom Atlas j’ai constaté des anomalies enregistrées dans les tables conso_teleinfo et conso_jour…
J’ai voulu corriger les valeurs enregistrées par le plugin Suivi-conso en utilisant Adminer.
Je me suis occupé d’un équipement « enfant » (je ne sais pas encore si le problème est lié à la notion « enfant ») et j’ai constaté que la valeur de l’index enregistrée par le plugin dans conso_teleinfo était le double de la valeur réelle lu dans l’équipement source (bouton tester…).
J’ai déjà eu des problèmes concernant des valeurs fausses enregistrées par le plugin. J’ai toujours eu du mal à arrêter l’anomalie. Et là encore je ne m’en suis pas sorti…
J’ai commencé par d’abord désactiver l’équipement, corriger les valeurs de conso_jour, modifier l’équipement à plusieurs reprises en le réactivement à chaque fois… rien à faire, après chaque réactivation le plugin continuait à enregistrer une valeur d’index ayant un écart de 312295 (le double de valeur réelle au moment du plantage…)…
J’ai fini par désactiver l’équipement ayant l’ID 202 et j’en ai créé un nouveau ayant l’ID 209 qui lui s’est bien mis à recevoir la bonne valeur de l’index.

1. qu’elle procédure faut-il suivre pour régler un tel disfonctionnement ? Parce ce que j’ai d’autres équipements à corriger
2. qu’elle procédure dois-je suivre pour rassembler les deux équipements 202 et 209 en un seul ? Sans doute avec l’outil « Changement ID équipement », mais je suppose qu’il vaut mieux respecter des règles ???

EDIT : à titre d’exemple, voici des captures d’écran de la valeur des index enregistrées par suivi-conso pour un autre équipement que je voudrais corriger aussi

Le max d’hier est bien repris en min d’aujourd’hui
Mais le max d’aujourd’hui est égal au double du min ou à la somme entre le min et la conso considérée du jour. La conso de cet équipement aujourd’hui est de zéro. Le max du jour id_max_hp devrait donc être 115934 et la conso hp devrait être 0

A 6h40 l’index enregistré par suivi-conso est le double de la valeur réelle

[superbricolo]

Déjà pour éviter ce genre d’anomalie, je te conseille de te mettre en mode FGD212 et de renseigner l’info « Variation max autorisée entre 2 mesures ». Comme cela si ton module de mesure déconne et envoie un pic de consommation, celui-ci ne sera pas pris en compte.

Après pour corriger je ferais une requête comme ci-dessousi. Et surtout, ne pas s’amuser à désactiver et réactiver l’équipement, car pour moi tu peux faire pire. Ensuite, il faut toujours corriger conso_teleinfo puis synchroniser, car si tu corriges conso_jour, la correction sera écraser par la synchronisation automatique
Si l’index ne correspond pas à l’index du module de mesure, cela n’a pas d’importance

update conso_teleinfo set hchp = hchp + 231868 - 115934 where id_equipement = 204 and rec_date =  '2023-11-10' and rec_time <= '06:36:50'

Et ensuite dans l’onglet outil, tu fais « synchroniser »

Et sinon pour recopier ton équipement 202 vers le 209:

insert into conso_jour (select timestamp, rec_date	,periode	,hp	,hc	,hp2	,hc2	,hp3	,hc3	,idx_max_hp		,idx_min_hp		,idx_max_hc		,idx_min_hc		,idx_max_hp2		,idx_min_hp2		,idx_max_hc2		,idx_min_hc2		,idx_max_hp3		,idx_min_hp3		,idx_max_hc3		,idx_min_hc3		,209	,temp_max	,temp_min	,temp_moy	,dju	,dju_clim	from conso_jour where id_eq = 202 and rec_date <= '2023-11-09')	

Il faut caler la date dans la requête pour essayer de mettre à jour une date qui existe déjà dans l’équipement 209, sinon la requête echouera

[MarcDesmilles]

Bonjour et merci pour ton aide.
Pour la correction j’ai fait comme tu m’as dit sur l’équipement 208.
La table conso_teleinfo contient maintenant jusqu’en début de journée une valeur index hp dans les 303 kW. L’équipement, auquel je n’ai pas touché, continue d’envoyer des valeurs de l’ordre de 303 kW
Mais, après synchronisation, dans conso_jour, la valeur min du jour est restée à 150475 W => conso du jour 152.677 kW

EDIT EDIT : non, ne tiens pas compte de mon message, la synchronisation a bien mis à jour le min de la journée aussi… je n’avais pas dû actualiser la requète

[MarcDesmilles]

@superbricolo

Et sinon pour recopier ton équipement 202 vers le 209:

insert into conso_jour (select timestamp, rec_date	,periode	,hp	,hc	,hp2	,hc2	,hp3	,hc3	,idx_max_hp		,idx_min_hp		,idx_max_hc		,idx_min_hc		,idx_max_hp2		,idx_min_hp2		,idx_max_hc2		,idx_min_hc2		,idx_max_hp3		,idx_min_hp3		,idx_max_hc3		,idx_min_hc3		,209	,temp_max	,temp_min	,temp_moy	,dju	,dju_clim	from conso_jour where id_eq = 202 and rec_date <= '2023-11-09')	

Il faut caler la date dans la requête pour essayer de mettre à jour une date qui existe déjà dans l’équipement 209, sinon la requête echouera

Pour un autre équipement, le 204, avant ton message, j’avais « corrigé » et « accordé » conso_teleinfo et conso_jour et créé un nouvel équipement, le 210.
Dans l’ancien équipement, le 204, j’ai supprimé la ligne du jour dans conso_teleinfo
Ensuite j’ai utilisé Outils/Changement ID equipement pour déplacer les données de l’ancien équipement 204 vers le nouveau 210. Il n’y avait plus de lignes 204 dans les tables.
J’ai supprimé l’équipement 204

Qu’en penses-tu ? J’ai bon ?

[superbricolo]

Oui oui, très bien. Moi j’ai tendance à utiliser des requêtes, car c’est plus naturel pour moi. Mais les outils dans le plugin font aussi bien l’affaire.

[MarcDesmilles]

@superbricolo

Déjà pour éviter ce genre d’anomalie, je te conseille de te mettre en mode FGD212 et de renseigner l’info « Variation max autorisée entre 2 mesures ». Comme cela si ton module de mesure déconne et envoie un pic de consommation, celui-ci ne sera pas pris en compte.

Abordons ce dernier sujet que je ne comprends pas. Peux-tu m’expliquer le mécanisme ?

Après le plantage de ce matin les commandes des équipements (fils en majorité, mais je ne suis pas sûr…) cochés FGD-212 (sans variation max…), en HP/HC avec un index virtuel, recevaient une valeur de l’équipement source, par exemple 300000 et enregistraient dans conso_teleinfo 600100.

Comment ce 600100 a été calculé ? Les 300000 venant de l’équipement source + 300000 de hchp précédent + 100 de hchc précédent ? C’est çà ?

Si je mets la valeur 1000 dans le paramètre « Variation max… » que se passe-t-il la première fois, puis tant que cette commande essaiera d’enregistrer 600100 ou une valeur supérieure (c’est à dire tout le temps après le plantage) la variation va toujours être supérieure à la « Variation max… »

[MarcDesmilles]

@superbricolo

Déjà pour éviter ce genre d’anomalie, je te conseille de te mettre en mode FGD212 et de renseigner l’info « Variation max autorisée entre 2 mesures ». Comme cela si ton module de mesure déconne et envoie un pic de consommation, celui-ci ne sera pas pris en compte.

Après pour corriger je ferais une requête comme ci-dessousi. Et surtout, ne pas s’amuser à désactiver et réactiver l’équipement, car pour moi tu peux faire pire. Ensuite, il faut toujours corriger conso_teleinfo puis synchroniser, car si tu corriges conso_jour, la correction sera écraser par la synchronisation automatique
Si l’index ne correspond pas à l’index du module de mesure, cela n’a pas d’importance

update conso_teleinfo set hchp = hchp + 231868 - 115934 where id_equipement = 204 and rec_date =  '2023-11-10' and rec_time <= '06:36:50'

Et ensuite dans l’onglet outil, tu fais « synchroniser »

Désolé, mais je ne m’en sors pas avec un équipement HP/HC + FGD212 + index virtuel hchc

Cet équipement avait enregistré des index en hphc (index = à celui de l’équipement source), mais aussi des index en hchc dans un index virtuel.
Après le plantage cet index virtuel est passé de la valeur 1111 à 0 à 8h40 (pendant les HP).
Pour cette prise Frient j’avais créé un équipement de remplacement. J’ai « réparé » l’ancien et le nouveau équipements je les ai alignés, j’ai fusionné les valeurs de l’ancien dans le nouveau…
Mais le nouvel équipement a toujours la commande de l’équipement virtuel qui envoie 0 et non pas 1111.

Pour l’instant, en attendant tes conseils j’ai retiré FDG212, et dans la commande de l’index HC j’ai mis « +1111 ».
Mais je ne peux pas rester comme ça…

[superbricolo]

D’abord, ce n’est pal plugin SuiviConso qui génére l’anomalie, c’est ton module qui donne l’information de consommation au plugin qui donne une info erronée ( peut-être à un moment donnée une valeur à 0 et ensuite la valeur revient avec + tes 100 par rapport à la conso précédente). Après SuiviConso travaille par différence, donc s’il y a une grosse différence, il l’a prend en compte.

• Tu commences donc par interdire les valeurs à 0 sur ton module de mesure en mettant une borne mini à 1 sur la commande correspondante
• Ensuite tu lis ceci pour l’explication de l’utilisation du variation max: Consommation equipements - #6 par superbricolo
  -Pour finir toutes tes anomalies + tes correctifs un peu hasardeux sont trop compliquées pour continuer par échanges sur le forum. Je te propose de m’ouvrir un accès sur ton Jeedom, je te corrige tout ça, je te mets les bons paramétrages avec les bons contrôles et je te renvoie sur le forum les modifs apportées. Je crois que l’on va gagner du temps.

[MarcDesmilles]

Désolé de t’avoir tant mis à contribution…

@superbricolo

D’abord, ce n’est pal plugin SuiviConso qui génére l’anomalie, c’est ton module qui donne l’information de consommation au plugin qui donne une info erronée ( peut-être à un moment donnée une valeur à 0 et ensuite la valeur revient avec + tes 100 par rapport à la conso précédente). Après SuiviConso travaille par différence, donc s’il y a une grosse différence, il l’a prend en compte.

J’avais vérifié les valeurs enregistrées par l’équipement source : pas d’anomalie repérable dans l’historique
J’avais également vérifié les valeurs reçues dans le paramétrage de l’équipement dans suivi-conso, avec le bouton « Tester » : la valeur reçue par ce test était conforme aux valeurs enregistrées par l’équipement source.
Et pourtant dans la table conso_teleinfo l’index hchp était le double de la valeur reçue lors du test, sans jamais revenir à la valeur de l’index de l’équipement source

Mais, comme toi, j’en ai marre. J’ai supprimé les valeurs de cet équipement dans conso_teleinfo et conso_jour en utilisant Outils/Spprimer un équipement. Et je suis reparti à zéro sur cet équipement.

@superbricolo

• Ensuite tu lis ceci pour l’explication de l’utilisation du variation max: Consommation equipements - #6 par superbricolo

Oui, j’avais déjà lu ce sujet. Pour l’équipement Frigos j’ai mis 500 W.
Mais avec ce qui m’est arrivé ce matin je ne sais pas à quoi ça aurait servi, puisque la valeur enregistrée dans conso_teleinfo ne redescendait pas à une valeur cohérente par rapport à la valeur avant plantage.
Cette valeur est par exemple passée de 300000 à 600000, à cet instant je suppose que le paramètre à 500 bloque l’enregistrement de ces 600000. Mais ensuite, les valeurs suivantes restaient à 600000. La différence passe à 0 ou elle reste à 300000 ?

Allez, je vais en rester là.

Encore merci et bonne soirée.

[superbricolo]

En mode FGD212 on gère un index virtuel, donc si à un moment il y a un pic non contrôlé, l’index augmente et ne redescendra jamais et ce n’est pas grave puisque l’on travaille par différence.
Le fait d’avoir le paramètre variation max actif empêchera l’enregistrement du pic, et aussi l’augmentation de l’index. Et tu n’auras aucune erreur dans tes relevés.
Donc l’index reste à 300000. Et c’est comme cela que ça marche:
Ton module donne 300000 et l’index SuivConso est à 300000. Ton module donne une valeur à 0, la différence avec le dernier relevé est négative (-300000), on n’enregistre pas. La valeur du module repasse à 300010, la différence est 300010 alors on bloque aussi puisque tu as mis 500.
Maintenant le module dit 300020, la différence est alors de 10, on enregistre dans SuiviConso.

Donc pour ton frigo, l’index n’aurait pas augmenté, et pas d’anomalie dans les graphes. Si ça n’a pas marché et que c’était bien paramétré, c’est qu’il y a eu un autre problème

Et donc, je le redis, il faut bloquer les valeurs à 0 dans ton module de mesure si tu es sur qu’il ne repasse jamais à zéro, en agissant sur la borne mini de ta commande

Et pour info l’historique de ton module ne fait pas forcément apparaitre la valeur à 0 s’il est moyenné.
Je trouve dommage, d’avoir supprimé. Je trouve que c’est mieux de toujours corriger quand on peut. En général on y arrive. C’est pour cela que je te proposait de le faire. Mais j’ai besoin de voir les données en live pour le faire.

[MarcDesmilles]

Mon module source n’est pas moyenné. L’historique de la commande est correct. Je l’utilise par ailleurs à plusieurs autres endroits dans Jeedom. Le bouton Tester m’indiquait la bonne valeur de la commande. La valeur enregistrée dans conso_teleinfo valait le double. Ca ne m’est pas arrivé seulement avec cet équipement.

La procédure que tu m’as indiquée ce matin a fonctionné. Je l’ai appliquée sur un équipement qui n’avait que l’index hchp qui contenait des valeurs ; l’index hchc était à 0 depuis la création de l’équipement, il s’agissait d’un équipement lié au photovoltaïque (l’injection je crois). Sur un équipement dans lequel les deux index hchp et hchc contiennent des valeurs, j’appliquerai la même technique à hchc…

J’ai mis la valeur Mini à 1 dans les paramétrages de toutes les commandes des équipements source.

[superbricolo]

Bah je ne sais pas alors, C’était pourtant le scénario le plus probable. Il faudrait que je voie les données pour peut-être arriver à comprendre. Tu parlais au début d’un plantage de ta Jeedom Atlas…

[MarcDesmilles]

@superbricolo

Il faudrait que je voie les données pour peut-être arriver à comprendre. Tu parlais au début d’un plantage de ta Jeedom Atlas…

Ben les données suivi_conso de maintenant ne sont plus représentatives de celles que j’avais ce matin.
D’une part, j’ai essayé de me débrouiller tout seul, pour deux équipements j’ai appliqué la procédure que tu m’as indiquée…
Mon impression c’est que les équipements « Parents » ou « Seuls » ne sont pas concernés par le phénomène que je tente de te décrire.
Ce sont les équipements « Enfant » avec FGD212 activé et donc des index virtuels.

Pour essayer de comprendre, et essayer de trouver une solution, j’ai désactivé le FGD212. La valeur mémorisée dans hchp devient « la bonne » valeur. Pour reprendre l’exemple et essayer d’être clair dans conso_teleinfo j’ai :
depuis 6h → 6h20 hchp = 300000
plantage à ~6h25, plus accès à l’Atlas, débranchement/rebranchement entre 6h20 et 6h30
depuis 6h45 → 7h00 hchp = 600000
à 7h je désactive FGD212 en ne mettant rien dans le paramétrage de la commande HC de l’équipement
à partir de 7h05 hchp = 300000
je ne peux/veux pas rester avec ce paramétrage, je recoche FGD212
à partir de là disons 7h10 hchp = 600000

[superbricolo]

Oui là, forcément si tu changes de mode en cours de route, ça génère des écarts importants. En mode FGD212 et FGD211, l’index ne suit pas forcément l’index réelle, et ce n’est pas un problème. Mais si tu passe d’un mode à l’autre, ça génère des problèmes. Je rappelle que la consommation d’une journée transmise dans conso_jour, c’est le max - le min de la journée de conso_teleinfo pour l’équipement.

Tu dis aussi que le redémarrage de l’Atlas a doublée l’info. Je persiste tout de même à dire que SuiviConso à reçu une valeur à 0 puis après à nouveau une valeur à 300000. la différence de 300000 - 0 a été donc ajouté à ton index virtuel qui était de 300000 auparavant.

[MarcDesmilles]

OK, ce n’est pas le dernier plantage, je verrai la prochaine fois.
Je pense que la prochaine fois, je désactiverai un équipement sans le toucher et je créerai un nouvel équipement qui repartira à zéro. Mais je pourrai alors te donner la main pour que tu examines l’ancien équipement auquel je n’aurai pas touché.

Autre question : j’ai paramétré l’injection PV en tant que « Enfant » de la consommation Enedis Linky. C’est une connerie, l’injection n’est pas une partie de la consommation…
Je voudrais essayer de mettre l’injection en tant que « Enfant » de la production PV, ce qui, si je réfléchis bien, me donnerait d’une part l’autoconsommation et d’autre part le surplus de production.

Puis-je, sans perte de données, changer l’équipement « Parent » ?

L’ancien équipement (consommation) est en HC/HP et le nouvel équipement (production) est en HP. L’injection en TEMPO n’a que l’index hchp qui évolue.

[superbricolo]

Le fait de changer de parent ne fait jamais perdre des données.
Par contre si le pere était en hp/hc et que tu passe avec un un père en normal. Alors tu ne vas plus voir dans les graphiques de l’enfant les infos hc puisque tu es en tarif base.

Par contre ce que je ne comprend pas, c’est que si tu en Tempo, tu n’as pas lieu d’être en hc/hp dans le paramétrage. Et même ta production devrait être en Tempo, si tu veux comparer quelques chose. Ah oui cest vrai, en tempo tu n’as pas d’heures creuses dans la journée, donc toutes ta production/injection et en hp. Mais bon tout de même, tu as la couleur des jours.

Pour moi il faut tout mettre en Tempo, comme çà tu tarifies bien en fonction des couleurs des jours, tu peux comparer les économies réalisées et tu visualises toujours ton historique en heure creuse

[MarcDesmilles]

@superbricolo

Le fait de changer de parent ne fait jamais perdre des données.

OK, super, je vais passer, l’injection, ou surplus de production en « Enfant » de la production PV.

@superbricolo

Par contre si le pere était en hp/hc et que tu passe avec un un père en normal. Alors tu ne vas plus voir dans les graphiques de l’enfant les infos hc puisque tu es en tarif base.

L’ancien « Parent » c’était la consommation Enedis Linky va la TIC, il est en Tempo avec 6 index (HP/C x 3 couleurs).
Mais comme l’injection, Index EAIT dans la TIC, n’a qu’un seul index (pas de HC/HP, pas de couleurs), j’avais coché FGD212 ce qui avait, en quelque sorte, fait passer l’injection en HP/HC (désolé pour le raccourci que j’ai pris dans mon message précédent).
Et de plus, en Tempo, la journée de 6h à 22h, est entièrement en HP, et pour avoir de l’injection il faut de la production PV et donc du soleil… Dans conso_teleinfo hchc est toujours à 0 pour cet équipement Injection.

Quant à la production PV, elle m’appartient, c’est ma production. Elle est complètement indépendante de ma consommation et de mon contrat. HP/HC et Bleu, Blanc, Rouge, je ne connais pas en production PV.
Je consomme une partie de cette production, c’est mon autoconsommation (qui vient à la place ou en plus de ma consommation Linky ENEDIS), et j’injecte sur le réseau, via le Linky et l’index EAIT une partie de l’électricité produite en surplus.
Cet équipement Production PV, je l’ai mis en HP parce que je n’ai qu’un seul index et pas de contrat.
Et donc, c’est pourquoi je dis que, si je passe l’injection en « Enfant » de la production PV elle passera de HC/HP en HP (mais avec un index hchc toujours à zéro).

Remarque : l’injection est rachetée par EDF à 0,10 € /kWh pour les anciens contrats et à un tarif qui évolue chaque trimestre pour les installations faites après le 01/11/2022 (je simplifie…)
Il n’y a pas de tarif de rachat des kWh injectés dans suivi-conso, mais c’est un détail.

@superbricolo

Pour moi il faut tout mettre en Tempo, comme çà tu tarifies bien en fonction des couleurs des jours, tu peux comparer les économies réalisées et tu visualises toujours ton historique en heure creuse

Si je mets tout en Tempo et que je ne peux renseigner que la première commande, parce que je n’ai qu’un seul index sans distinction HC/HP ni des couleurs de Tempo, qu’est ce que je mets dans les 5 commandes suivantes ?
Comment se comporteront le plugin et le panel ? Je n’arrive pas à imaginer ce que cela va donner…
Peux-tu m’en dire plus sur ces équipements à un seul index ?

Petite précision, lorsque j’essaye de répartir la consommation globale de la maison entre les frigo, la MAL, le LV, la piscine, le VE (tous ces équipements n’ont qu’un seul index)… comme j’ai une double alimentation électrique (ENEDIS et PV), il faut que je répartisse la totalité de ma consommation, c’est à dire celle qui vient du réseau via le Linky, plus celle qui provient de la production PV (l’autoconsommation). C’est pourquoi le parent des équipements à répartir n’est pas l’équipement consommation TIC. J’ai un autre équipement ConsoTot qui fait la somme de la consommation Linky et de l’autoconsommation produite par la production PV. Mais on en parlera plus tard peut-être un jour…

Je te montre mes paramétarges :
Le paramétrage de l’équipement principal, la consommation Tempo via la TIC Linky ENEDIS

Le paramétrage actuel de l’injection. Enfant de la consommation, donc en Tempo, mais avec FGD212 coché car un seul index EAIT (Energie Active Injectée Totale). C’est dans ce paramétrage là que je voudrais changer l’équipement parent

Si pour l’équipement injection, je décoche FGD212 en le laissant « Enfant » de l’équipement consommation Tempo, j’obtiens cette grille ci-dessous. Qu’est ce que je mets dans les 5 dernières commandes ? Zéro ? (je crois que j’ai essayé).
Mais de toute manière, dans la réalité, l’injection n’est pas liée à la consommation. Dans le camembert statistique, l’injection ne peut pas être une partie de la consommation…

Et enfin le paramétrage de la production PV, en simple HP d’après moi… Les panneaux sur mon toit ne connaissent pas HC/HP et Tempo

[MarcDesmilles]

@superbricolo

Le fait de changer de parent ne fait jamais perdre des données.

EDIT : OK, c’est bon, j’ai corrigé dans conso_teleinfo en appliquant, en fait, la requête inverse à celle que tu m’avais indiquée hier. J’ai déduis 1848664 à toutes les lignes concernées du 10/11 et 11/11. Puis j’ai fait une synchronisation…

OK, mais dans mon cas c’est la pagaille…
J’ai modifié le « Parent » de l’équipement Injection vers 14h et je n’y ai pas touché.
Je suis passé du Parent consommation Temp HC/HP au Parent production PV en HP. J’ai décoché la case FGD212

L’index de hchp min du 10/11 dans conso_teleinfo est 3699811

On voit dans conso_teleinfo que après mon changement de Parent vers 14h l’index hchc a continué de progresser.
A 17h22 sans doute précisément j’ai fait une Synchronisation. Et l’index hchc a reculé à la valeur 1853463

Dans conso_jour le min et max ont récupéré ceux de conso_teleinfo, mais ne sont plus ceux de la journée du 11/11.
Mais on voit en fait, que l’index a repris la valeur de l’index de l’équipement source qui a été perturbé par les problèmes rencontrés dans la journée du 10/11

[superbricolo]

@MarcDesmilles

Et de plus, en Tempo, la journée de 6h à 22h, est entièrement en HP, et pour avoir de l’injection il faut de la production PV et donc du soleil… Dans conso_teleinfo hchc est toujours à 0 pour cet équipement Injection.

Cela a un intérêt de se mettre en Tempo, si tu veux voir combien tu as économisé sur une période sachant que tu as des jours bleus blancs et rouge avec tarifications différentes. Là tu n’auras que la consommation de pertinente, l’économie réalisé tu ne pourra pas l’avoir.
Après je sais que comme tu n’as pas de batteries et vue des horaires HC du Tempo, tu n’as pas d’utilisation de ta production sur les HC, je te l’avais dit:

oui c’est vrai, en tempo tu n’as pas d’heures creuses dans la journée, donc toutes ta production/injection et en hp. Mais bon tout de même, tu as la couleur des jours.

@MarcDesmilles

Il n’y a pas de tarif de rachat des kWh injectés dans suivi-conso, mais c’est un détail.

Il y a type « Elect prod » qui permet de gérer un tarif différent de celui de du type électricité

@MarcDesmilles

Si je mets tout en Tempo et que je ne peux renseigner que la première commande, parce que je n’ai qu’un seul index sans distinction HC/HP ni des couleurs de Tempo, qu’est ce que je mets dans les 5 commandes suivantes ?

Il faut se mettre en mode FGD212 et le plugin va gérer des index virtuels en fonction du PTEC en cours, donc générer 6 index.

@MarcDesmilles

Petite précision, lorsque j’essaye de répartir la consommation globale de la maison entre les frigo, la MAL, le LV, la piscine, le VE (tous ces équipements n’ont qu’un seul index)… comme j’ai une double alimentation électrique (ENEDIS et PV), il faut que je répartisse la totalité de ma consommation, c’est à dire celle qui vient du réseau via le Linky, plus celle qui provient de la production PV (l’autoconsommation). C’est pourquoi le parent des équipements à répartir n’est pas l’équipement consommation TIC. J’ai un autre équipement ConsoTot qui fait la somme de la consommation Linky et de l’autoconsommation produite par la production PV. Mais on en parlera plus tard peut-être un jour…

Je comprend, c’est normal. Pour cela tu fait un parent avec ta conso linky + ton autoconsommation. Le mieux pour moi est de se mettre ne mode FGD212 et l’index que tu mets est la somme des index HPJB + HCJB + HPJW + HCJW + HPJR + HCJR + Autconso et tu mets à jour ton PTEC correctement. 6 index virtuel seront générées. Et tu mets tous tes sous-équipement à ce parent. Comme cela tu auras la répartition de consommation dans le camembert.

L’injection puisqu’elle est fille de ton Linky (SuiviConso), génère donc 6 index virtuels en fonction des HP seulement (puisque le jour) mets en fonction des couleurs du jour.

@MarcDesmilles

Si pour l’équipement injection, je décoche FGD212 en le laissant « Enfant » de l’équipement consommation Tempo, j’obtiens cette grille ci-dessous. Qu’est ce que je mets dans les 5 dernières commandes ? Zéro ? (je crois que j’ai essayé).
Mais de toute manière, dans la réalité, l’injection n’est pas liée à la consommation. Dans le camembert statistique, l’injection ne peut pas être une partie de la consommation…

Il faut laisser en mode FGD212, et effectivement, je suis d’accord, cela n’a pas d’intérêt d’avoir l’injection fille de la consommation. Moi je ferais plutôt une hiérachie père = production et fils = injection. Cela te permet d’avoir un camembert où tu aurais la catégorie « indéfinie » qui serait l’autoconsommation. Si astuce, si tu veux nommer l’autoconsommation dans le camembert, tu fait un fils de la production qui aurait comme index Production - injection.
Et là l’avantage d’être en Tempo c’est de chiffrer ton autoconsommation en fonction des couleurs des jours.

[superbricolo]

@MarcDesmilles

J’ai modifié le « Parent » de l’équipement Injection vers 14h et je n’y ai pas touché.
Je suis passé du Parent consommation Temp HC/HP au Parent production PV en HP. J’ai décoché la case FGD212

L’index de hchp min du 10/11 dans conso_teleinfo est 3699811

On voit dans conso_teleinfo que après mon changement de Parent vers 14h l’index hchc a continué de progresser.
A 17h22 sans doute précisément j’ai fait une Synchronisation. Et l’index hchc a reculé à la valeur 1853463

Il ne fallait pas décocher FGD212 c’est cela qui te fait reculer ton index. Avant tu avait un index virtuel et en décochant tu passes avec l’index réel, et donc ça te fausse ta journée