Eco compteur Legrand

[RemoveBeforeFlight]

Merci pour ta réponse.

Si je venais a mettre un tore sur l'entrée, cela serait pour vérifier dans un premier temps que mon éco compteur est bien impacté par le problème.

L'explication du problème lié à la précision en Float32 est élégante, cependant, je demande a être convaincu car si cela intervient toujours au bout d'une même durée malgré la variation saisonnière de consommation, cela ne fonctionne pas. Il serait intéressant d'avoir les valeurs des différents compteurs au moment ou ça commence à dériver afin de pouvoir vérifier si cela intervient à chaque fois lorsque l'on passe un segment de précision (en Float32, la précision du nombre stocké est d'autant plus grande que le nombre stocké est proche de 0, on a ainsi des "plages" de précision en fonction de la valeur à représenter).
Sur mon coin de table j'ai des idées pour corriger ce genre de problème, j'ai du mal à comprendre pourquoi Legrand n'agit pas...

Bref, plus j'y pense, plus ça me fait chier d'acheter un truc quasi certainement buggé.

Du coup je suis en train de regarder ce qui se fait ailleurs... je pourrais potentiellement me rabattre sur un Shelly Pro 4PM. Du coup potentiellement je remettrai à plus tard ma mesure par poste sur la maison, me contentant dans un premier temps d'"une mesure sur les équipements piscine/extérieur (PaC/filtration/éclairage/prises extérieures). Ce qui m’intéresse dans ce device c'est aussi qu'il permet de commander les composants : j'ai pour but de domotiser ma filtration et mon chauffage de bassin (pour travailler sur les périodes ou la PaC aura le meilleur rendement et en essayant d'allumer ces équipements uniquement au moment ou notre production électrique n'émet pas blinde de CO2).

[Lavabre]

Petite rectification : suite à un mail de Legrand ce jour, le téléchargement des données à été rectifié depuis leur site et effectivement il est désormais possible de récupérer les infos de la nouvelle génération d evocompteur au format csv ou xls jusqu'à la 1 /2 heure.
Il devait être question d’alarme par mail à paramétrer en fonction de critères définis par l’utilisateur mais toujours rien vu de tout cela !

[marcomatic]

Salut à tous et bonne année 2022 !!

je suis dégouté, ça fait deux ans que je cherche pourquoi mon compteur affiche n'importe quoi en pensant que c'est moi qui me suis mélangé une phase et un neutre... Et c'est seulement maintenant que je trouve cette discussion !

J'ai contacté Legrand plusieurs fois, leur dernière réponse est:
"Nous revenons vers vous pour faire suite à l'étude de vos données transmises précédemment.

Les valeurs mesurées dans le tableau csv ont été comparées aux ratios
calculés sur la page écran avec les graphiques.

Nous trouverons des valeurs relativement proches et cohérentes entre le calcul et la réalité.

Nous vous informons par ailleurs que l'éco-compteur n'a pas pour vocation de faire des calculs, mais de donner à titre indicatif des valeurs de consommations. Il s'agit d'un outil de sensibilisation pour améliorer les consommations. Sa classe de précision ne permet pas de faire ce que vous souhaité."

Et j'ajoute que j'avais mis le doigt sur un autre problème: mes heures creuses sont de 23h à 7h, mais dans les graphiques les couleurs des colonnes correspondent à 22h-6h (sans par contre affecter les calculs) mais ça aussi ils s'en foutent.

Donc tout ceci pour vous dire merci, je viens de faire un reset, après avoir récupéré les csv, je n'ai plus qu'à écrire un petit programme qui va récupérer les données automatiquement pour les mettre dans une BDD....
Ou alors peut-être que Domoticz peut récupérer les données malgré les reset? pas sûr

Si j'aurais su - j'aurais pas acheté Legrand.

[Lavabre]

Bonjour.... Et meilleurs voeux également !
Pour ce qui est du "Reset", franchement un Raspberry Pi Zero W (il existe désormais la version 2, quatre fois plus rapide) à 15€ fait intégralement le travail !
Toutes les heures à XXH03 il faut aller récupérer en FTP les 3 fichiers CSV (2 horaires et 1 journalier), mettre en forme et stocker le résultat sur le RPi dans deux fichiers distincts.
Pour le reset, à XXH05 par exemple vous appuyez dessus puisque tout vient d'être sauvegardé et à l'heure suivante XX+1 H 03 votre RPi rajoute les nouvelles données à l'ancien fichier horaire qu'il possède.

En ce qui concerne le fichier journalier, il y aura forcément une erreur (à moins de faire un Reset à minuit 5...) puisque la journée ne sera pas complète ce jour là.
il faudra la calculer manuellement à partir du fichier horaire qui lui sera correct (sous réserve que vous n'ayez pas attendu des plombes pour le Reset après la récupération des données par le RPi à XXH03... -> Si vous faites le Reset à XXH50 par exemple, vous aurez perdu pratiquement 1 heure de données. Si vous le faites à XXH05, vous ne perdez que 5 minutes).

Voila, je fonctionne ainsi depuis plus d'un an, et c'est quasi complètement automatisé puisque le Pi calcule tous les jours le pourcentage d'erreur par rapport au Linky sur 24H et dès qu'il descend à +2% il m'avertit par SMS et mail qu'un reset est nécessaire ! Sinon il m'envoie par mail les données de la veille au format CSV en ayant pris soin de modifier les points par des virgules (+ simple pour moi après), et le tout avec un résumé (total par rubriques) de la journée !

Bonne journée à vous !

[Ziz]

Bonjour et merci pour les pistes précieuses fournies dans ce fil de discussion.

J'avais des doutes sur la précision de mon Ecocompteur Legrand, car j'ai noté des divergences entre la consommation affichée par mon monosplit et la consommation chauffage de mon Ecocompteur.

J'ai donc fait quelques tests, et je suis convaincu que la piste du float 32 bits est la bonne.

Dans un codage 32 bits, la précision est dépendante du nombre qu'on encode. Dans notre cas, plus l'index de consommation d'un circuit est élevé, plus l'incrément de consommation entre 2 pas d'intégration est grossier. La mesure de puissance me semble bonne. Par contre, à chaque pas d'intégration, de 1 seconde à priori, on ajoute une consommation faible (car sur une durée courte) à un index grand (car sur plusieurs mois/années).
Voici un petit tableau pour fixer les idées sur la précision selon l'index courant :

lsb.JPG (44.21 Kio) Consulté 2148 fois

La colonne "LSB conso" représente la plus petite valeur d'incrément de consommation possible du fait du codage float 32bits. La colonne LSB puissance représente la puissance pour avoir ce LSB conso pendant une durée de 1 seconde.
La colonne 1/2 LSB puissance est simplement la moitié de la précédente, pour connaître le seuil d'arrondi.
Je m'explique sur un exemple :
Sur mon ecocompteur, le circuit "Eclairage" a un index courant de 952kWh. Dans le tableau, ça nous situe entre 524 et 1049, le LSB conso est donc 0.0625 Wh. L'index augmente d'un nombre qui est un multiple de cette valeur forcément. Cela correspond à une puissance de 225W pendant 1 sec.

• Si on a une puissance de 225W exactement, l'index va augmenter de la consommation réelle.
• Si on a une puissance de 150W par exemple, donc plus que 113W (= 225/2), l'arrondi fait que l'ecocompteur va encore compter une consommation équivalente à une puissance de 225W.
• Si on a une puissance de 50W (< 113W), l'arrondi fait que l'écocompteur compte une consommation nulle !

Pour vérifier ça, j'ai fait quelques tests en allumant des lampes pendant une heure à puissance constante sur mon circuit d'éclairage, ou bien en branchant une lampe halogène de 400W sur mon circuit cuisson. Mon circuit cuisson a un index de 1713 kWh, donc un LSB puissance de 450W.
Voici la synthèse dans ce tableau

circuits.JPG (20.28 Kio) Consulté 2148 fois

Ces tests vérifient bien les explications de dessus. Il y a simplement un écart de 2% environ entre la consommation LSB attendue sur une heure et la consommation renvoyée par l'écocompteur : 439 Wh vs 450 Wh et 220 Wh vs 225 Wh. Pourquoi ? Sans doute un autre bug dans l'implémentation Legrand : on peut imaginer que le temps réel n'est pas respecté, et le pas d'une seconde dure en fait un tout petit peu plus à cause des temps de calcul (sleep 1 sec + temps de calcul grosso modo).

Si quelqu'un veut faire des tests avec d'autres niveaux d'index, il suffit de mettre une consommation constante pendant une heure, et de regarder comment évolue le fichier LOG2.csv. Je peux vous guider plus si mes explications ne sont pas claires.

L'informatique embarquée n'est pas le métier de Legrand décidément .... Si vous regarder les dernières lignes de mon tableau, vous pouvez voire que sur des index importants (mais réalistes), Legrand ne va pas faire la différence entre 3650 W et 10 000W par ex ! Les deux seront comptés comme 7200 W. Honteux non ?

[Lavabre]

Merci pour tout ce travail de recherche très documenté et particulièrement intéressant.
Les explications sont particulièrement claires et censées et correspondent à la dérive observée avec le temps qui passe.
Deux choses ne collent cependant pas (et très curieusement!) Avec ce que j’observe depuis 4 ans :
1/ l’ecocompteur est parfaitement en phase avec le linky avec une erreur très régulière entre +4 et +6% pendant environ 2 mois (50 jours en moyenne), et SUBITEMENT d’un seul coup ce taux d’erreur se met à baisser sans discontinuer. Ne devrait on pas avoir une dérive régulière ?
2/ le délais avant d’observer cette dérive est constant qu’on soit en hiver ou en été. Or je me chauffe à l’électricité et ai donc une conso nettement supérieure en hiver sur ce poste (les autres restants identiques). Donc si on se base sur vos travaux et conclusions, je devrais constater une dérive beaucoup plus rapidement en période de chauffe après un reset qu’en période estivale (pas de clim en été susceptible de remplacer le chauffage), CE QUI N’EST PAS LE CAS PUISQUE ETE COMME HIVER le délais pour observer cette dérive est identique !
Curieux non ?
Votre explication est très certainement la bonne mais il doit y avoir encore autre chose derrière.... ?
Si vous avez une idée ça m’intéresse fortement !

PS et pour info: suite à diverses réclamations chez Legrand, ils m’ont envoyé un modèle identique tout neuf qui présente exactement les mêmes symptômes, ce qui confirme bien quelle que soit l’explication que nous sommes en présence d’un défaut de conception de cet appareil.

[Ziz]

J'ai essayé d'expliquer l'erreur sur l'intégration numérique réalisée par Legrand. Je ne dis pas qu'il n'y a pas d'autres problèmes dans cet écocompteur. Dans mes tests, je compare la mesure de puissance instantanée réalisée par l'écocompteur sur un tore et la consommation après une heure sur ce même tore. Mais rien ne prouve que la mesure de puissance est fiable par ex. A première vue, elle ne semble cependant pas aberrante : la lampe halogène de chantier marquée 400W dans mon test a bien été mesurée par l'écocompteur à une puissance d'environ 400W (ça oscillait entre 395 et 405).

Le problème d'intégration est bien au niveau de l'index de chaque tore. Il y a toujours une erreur numérique, c'est inévitable, reste à voir si elle est négligeable par rapport à la mesure. C'est cela que Legrand aurait dû s'assurer dans l'implémentation de l'intégration.
Dans votre cas, le chauffage en hiver est sans doute l'index qui grimpe le plus vite. Mais les puissances en jeu sont également importantes. L'erreur relative la plus importante n'est donc peut-être pas celle du chauffage.
Quand le problème survient (à 2 mois donc), il faut regarder les 5 index, et voir le LSB correspondant à chaque index. Les profils d'erreurs sont vraiment spécifiques à chaque installation, chaque répartition des tores et chaque profil de consommation.
Pour illustrer, je vais prendre un cas d'école :

• si vous avez un index (tore) qui mesure la consommation de petits appareils (box, tv en veille, radio réveil, etc)
• si le LSB de ce circuit après deux mois bascule à 113W, car l'index a lui-même basculé au dessus de 262kWh
• si la nuit la puissance cumulée de ces appareils en veille est de 50W (< 113/2)
• alors l'écocompteur va comptabiliser 0Wh par heure pour ce tore la nuit. Et les 50 Wh par heure réellement consommés seront comptés dans "Autres" du coup.
• avant basculement du LSB à 113W, le LSB était à 56W. Du coup, les 50W étaient comptabilisé à 56 Wh / heure.
• dans ce cas d'école, on a donc bien un saut soudain assez imprévisible de manière intuitive.
• PS : dans cet exemple, je mets volontairement de côté l'erreur de 2% d'intégration systématique constatée dans mes tests. Cela permet d'avoir des chiffres plus lisibles vis à vis de mon tableau de LSB.

Ce n'est qu'en regardant vos puissances instantanées et index courants que vous pourrez mieux comprendre ce qui se passe après 2 mois.
L'écocompteur produit une ligne toutes les heures entières et 2 min (00:02, 01:02, 02:02 etc). Si vous voulez vérifier le comportement de l'index d'un circuit, mettez une puissance stable sur ce circuit pendant une heure entière (de 9:02 à 10:02 par ex à l'heure ou j'écris). Observez la puissance instantanée mesurée par l'écocompteur le temps du test : elle doit être stable. Après la fin de l'heure (10:02), il faut comparer la variation d'index de ce circuit (dans LOG2.csv) avec cette puissance observée précédemment.

[Lavabre]

Merci de votre réponse que j'ai un peu anticipée !
En effet, depuis un peu plus de 6 mois, je note les dates exactes des Reset qui sont effectués syatématiquement dans les mêmes conditions(dès que la dérive est observée).
Ci-dessous, j'ai donc les différentes valeurs pour environ 150 jours et 3 Reset. Les deux premières périodes sont strictement sans chauffage et la troisième avec. EcoCompt correspond à la somme totale des lignes de mesure 1, 2, 3 4 et 5. Je n'ai pas mis l'eau puiqu'elle ne nous intéresse pas ici.

- Du 24/7 au 13/09 (52 jours sans chauffage) :
EcoCompt: 503.2 - L1: 39.6 - L2: 0.3 - L3: 72 - L4: 103.7 - L5: 287.5

- Du 13/9 au 02/11 (51 jours sans chauffage) :
EcoCompt: 492.3 - L1: 40.8 - L2: 0.3 - L3: 73 - L4: 107 - L5: 270,2

- Du 05/11 au 11/01 (67 jours AVEC chauffage) :
EcoCompt: 1309 - L1: 521.6 - L2: 180.8 - L3: 150.7 - L4: 138.9 - L5: 377

Si on suit votre raisonnement :
Dans les deux premiers cas la ligne L5 passe le cap des 262 kWh avec un LSB à 225 (c'est la seule ligne) mais avec une conso faible ;
Dans le troisième cas les lignes L1 et L5 dépassent largement le cap des 262 KWh mais avec une conso totale nettement plus élevée et une puissance instantannée soutirée également nettement supérieure (chauffage) qui doit peut-être "masquer" un temps l'imprécision liée et au passage de l'index > 262 sur le L5...
Effecivement cela se tiendrait avec également le fait qu'on soit passé de 51 jours 2 fois en période estivale à 67 jours en période hivernale...
Je continue ma relève précieusement mais cela prend du temps... 2 mois à chaque fois !
Si les données vous intéressent faites le moi savoir je vous les communiquerai !
Merci pour toutes vos explications et temps passé sur le sujet !
Dernière chose (et par simple curiosité), n'étant pas mathématicien, serait-il possible de savoir comment vous déterminez l'index et le LSB dans votre tableau ? Thank's

[Lavabre]

Je vous confirme que votre expliquation est la bonne :
Le 11 janvier ma ligne L1 est à 521KwH et dépasse donc le seuil des 262. Si la conso est supérieure à 56W/s on incrémente 113 watts toutes les secondes, en dessous rien (cf. votre tableau).
Pour info ma ligne L1 correspond à une pompe à chaleur et la ligne L2 aux résistances additionnelles.
Le circulateur de la PAC tourne à intervalle réguliers même si cette dernière n'a pas besoin de chauffer. Cette conso tourne autour de 30/40 watts/heures en moyenne.
Les heures où la PAC ne chauffe pas pour les journées avant le 11 janvier, la ligne L1 est à 0.
Après le Reset du 11 janvier 15H00, la ligne L1 passe à 30/40 watts toutes les heures quand la PAC est à l'arrêt (incrémentation de 28 watts toutes les seondes pour une conso instantannée > 14W jusqu'à l'indice 66kWh.
Aujourd'hui 27 janvier, l'indice L1 affiche 150Kwh. On est donc au seuil de 28W pour incrémenter la ligne L1 toutes les secondes de 56 watts et effectivement on est passé de 30/40 watts aux heures hors fonctionnement de la PAC à 15 en moyenne.

Vous avez vu juste et je tiens désormais l'explication du problème données à l'appuie !
Merci, cela faisait 4 ans que je cherchais à trouver l'explication rationnelle à mes observations...

[Ziz]

Pour comprendre le tableau des LSB, il faut comprendre le principe de codage des float 32bits. Sans se pencher dans le détail de la norme IEEE-754, on peut jouer avec https://www.h-schmidt.net/FloatConverter/IEEE754.html

Le LSB ne bouge pas tant qu'on ne touche pas à la partie exposant de la représentation. Par contre, le LSB double à chaque fois que la partie exposant est incrémentée de 1 (c'est une puissance de 2).

Si on prend le nombre 131072, qui est 2^17, tous les bits de la mantisse sont à 0 :

131072.PNG (9.27 Kio) Consulté 2088 fois

Pour voir le LSB pour cet exposant, il suffit de passer le bit de poids faible de la mantisse à 1 pour voir l'effet sur la valeur représentée :

131072_lsb.PNG (9.45 Kio) Consulté 2088 fois

Maintenant, on peut faire le même exercice avec 2^18 : on ajoute un à l'exposant :

262144.PNG (9.17 Kio) Consulté 2088 fois

Et on joue avec la mantisse pour constater que le LSB a doublé (la puissance de 2 additionnelle est passée par là) :

262144_lsb.PNG (9.81 Kio) Consulté 2088 fois

L'écocompteur va chercher à ajouter chaque seconde un nombre assez grand (conso depuis toujours) et un nombre très petit (conso sur une seconde). Par exemple, si l'index est représenté par un exposant 18 :

• 262144 + 0.01 => 262144 car 262144.01 n'est pas représentable, un arrondi est fait, à la valeur du dessous. Et chaque second, le "problème" se reproduit, donc l'index ne bouge jamais
• 262144 + 0.02 => 262144.03125 car 262144.02 n'est pas représentable, un arrondi est fait, à la valeur du dessus cette fois

J'ai joint à ce post le fichier excel dans un zip. Il peut être étendu dans les 2 sens, j'ai retenu uniquement les index les plus plausibles.