Forum Domoticz en français

Bonjour à tous,

Suite aux problèmes de mesure avec mon Ecocompteur, j'ai pu obtenir un remplacement de l'appareil, ce qui m'a permis de commencer à faire quelques tests.
Contrairement à Lavabre et à Ziz (si j'ai bien compris), j'utilise Domoticz pour enregistrer les consommations instantanées à l'aide du fichier inst.JSON. L'objectif est de s'affranchir des erreurs de mesure de l'Ecocompteur sur les durées longues.
En utilisant un capteur virtuel du type "Electrique (instantané+compteur) alimenté par un script lua appelé par "HTTP/HTTPS Poller" je récupère sans difficulté la consommation instantanée et les différents cumuls en kWh des journées précédentes :
Problème : selon la temporisation de mise à jour réglée dans HTTP/HTTPS Poller (cinq secondes ou une seconde), les totaux en kWh sont différents (voir captures ci-dessus).

J'ai vu que Lavabre interrogeait son Ecocompteur toutes les 12 secondes, et que la dérive par rapport au Linky était quasi nulle. Je pourrais donc utiliser cette temporisation, mais j'aimerais déterminer la tempo optimale.

En revanche, dans son script du 31 janvier, ziz utilise une fréquence d'interrogation de seulement une seconde.

Mon compteur EDF étant beaucoup trop loin de l'Ecocompteur, je ne peux pas utiliser la référence Téléinfo pour savoir quelle est la temporisation idéale.

@Lavabre : je me demandais si tu pourrais faire un test d'interrogation sur cinq secondes et une seconde, pour savoir quel est le seuil de fiabilité en secondes pour les mesures ?

Bonjour,
1/ Heureux que vous ayez pu avoir un EC de remplacement !
2/ Pour ce qui est des tests en lecture directe via JSON, en ce qui me concerne j'ai commencé en bash avec un RPi Zero. En mettant une lecture toutes les 12 secondes (soit 5 par minute), le pi tenait la cadence. Avec une correction de -4.8% (de mémoire...), j'ai obtenu des résultats qui collaient parfaitement avec le Linky. Certaines heures à +0.18% par exemple, d'autres à -0.3% ce qui sur une journée complète ne laissait qu'une marge très réduite d'erreur.
Suite aux travaux de Ziz, j'ai tout réécrit en Python et ai fait plusieurs essais. Je suis descendu à 5 secondes d'écart entre deux mesures et franchement il n'y avait guère de différence... Prendre une mesure par seconde ne devrait pas apporter grand chose sur une journée. En fait la conso doit être (à mon avis) assez continue dans le temps : le chauffe-eau va fonctionner plusieurs heures de manière continue, le chauffage ne fait pas 10 marche/arrêt par minute etc. etc. La seule chose qui pourrait peut-être poser problème c'est le fonctionnement d'une plaque à induction. Celle que nous avons régule sa puissance par la durée de fonctionnement mais pas par sa puisssance : à 12 par exemple elle fonctionne en continue, à 6 une seconde sur deux, à 1 une seconde sur trois (c'est un exemple). En mesurant toutes les 12 secondes cela peut effectivement poser un problème, bien que les erreurs compensent également (un coup on mesure sur un temps d'arêt -> 12 secondes sans conso, un coup sur un temps de fonctionnement -> 12 secondes avec conso).
Au résultat, même avec une durée de fonctionnement importante, au bout d'une heure, je n'avais pas de dérive significative (pour mémoire juste après un reset, j'ai avec les fichiers CSV générés par l'EcoCompteur censé faire 1 mesure par seconde environ +5% d'écart par rapport au Linky. Et après vérification sur un autre EcoCompteur de prêt les chiffres étaient identiques).
BREF, tout cela pour dire que 1, 5 ou 12 secondes d'écart entre deux mesures, avec des appareillages "normaux" (conso constantes et sans marche/arrêt fréquents) cela ne change pas grand chose (bien sûr il doit y avoir une limite au delà de laquelle l'écart doit commencer à se faire sentir...).
Là où j'ai par contre eu des problèmes (FreeBox utilisée en mode routeur avec un switch derrière), c'est lorsqu'il y a eu des coupures de réseau internet. Curieusement sur ces périodes j'ai eu de gros écarts du style 20%. Le matériel (EcoCompteur/RPi) n'étant pas en cause je pense que le routage de la box durant ces périodes a du mal se faire (?)...
J'ai abandonné cette solution du fait que se rajoutait également le problème qu'en cas de soucis sur le RPi, on perdait tout...

3/ Ziz à cette période a développé sa solution qui est excellente et probablement la meilleure : Se fixer une limite à ne pas dépasser pour garder une précision optimale (30 kWh par exemple par voie de mesure), et un reset à minuit de l'ensemble dès que cette limite est atteinte. Ca nécessite en plus de conserver un historique et tout plein de choses à côté mais l'EC tourne seul dans son coin (il ne s'est jamais planté en 5 ans de fonctionnement continue chez moi) et si on loupe une journée pour une raison X, on peut toujours faire le reset le lendemain, il n'y a pas une grosse différence !
En ce qui me concerne, j'ai modifié son travail en Python car lui travaille sur des relevés horaires et journaliers de compteur et moi sur des relevés horaires et journaliers de consommation. J'y ai également ajouté le reset sur le compteur d'eau ce qui n'a pas été simple car je n'ai jamais pu trouver le registre à modifier de ce compteur à impulsion... Je me suis aperçu (par hasard...) que de passer le prix du M3 à Zéro me mettait également la conso à Zéro... Curieux mais c'est comme celà ! Donc au reset je passe ce prix à zéro avant de le remettre à sa valeur normale et ça marche impeccablement bien ! )

Depuis mars que mon appli python est fonctionnelle, hors période de chauffage j'ai un reset tous les 7 à 8 jours. En période de chauffe cela peut tourner à 1 reset tous les 3 jours. Au final, en ce qui me concerne ça ne me change rien puisque mes fichiers de conso horaire et journalier sont générés par le RPi. Si le Pi se plante l'EC ne peut être remis à zéro et le jour où il est à nouveau opérationnel il récupère tout le retard accumulé avant d'effectuer si nécessaire un reset.
Je tourne à environ +1% d'erreur depuis mars par rapport au Linky (un peu moins en période de chauffe).

J'ai envisagé la solution de faire calculer le taux d'erreur toutes les heures au RPi pour l'appliquer ensuite sur les 5 voies de mesures (un sorte de taux de correction flottant puisque visiblement la correction n'est pas tout à fait la même en cas de forte/faible conso), mais à +1% d'erreur sur 3 mois j'ai préféré garder la solution initiale !

Peut-être qu'avec une application domotique (si c'est possible...), l'déal serait d'aller récupérer dans un fichier les données horaires et/ou journalières DE CONSOMMATION ET PAS des données de relevé de compteur, et de faire effectuer un reset automatiquement dès le dépacement du seuil fixé sur une des 5 voies... ?

Merci beaucoup, Lavabre, pour cette réponse très détaillée.

Le problème que je rencontre (les totaux en kWh sont différents selon la temporisation de mise à jour) serait donc lié à la méthode de calcul de l'énergie consommée par Domoticz.

Hier, j'avais moins de 0,5 % de différence entre le calcul journalier de Domoticz et celui de l'Ecocompteur avec une temporisation de 5 secondes, et 7 % avec une temporisation de une seconde !!!

Comme je peux enfin écrire dans le répertoire SYS de l'Ecocompteur, j'ai créé suivant les conseils de ziz un fichier .json qui permet d'interroger en même temps la consommation instantanée en watts et les compteurs en kWh.
Je vais donc enregistrer moi-même les totaux en kWh et les injecter dans Domoticz.
La suite dans quelques jours ...

Bonjour Lavabre,

Comme je l'indiquais plus haut, j'ai donc créé un fichier TOTAUX.JSON dans le répertoire SYS de l'Ecocompteur : J'ai bien compris que les compteurs LG503 0 à LG503 4, (Intitulés "Puissance_xxxxxx" dans mon fichier) ne sont pas affectés par le bug de l'Ecocompteur, mais est-ce aussi le cas des compteurs LG536 2 à LG536 10 (Intitulés "Conso_xxxxxx" dans mon fichier) ?

Les puissances instantanées sont correctes (sous réserve d’un léger correctif d’environ -4.8%) étant donné qu’elles ne sont pas enregistrées par le système.
Leur cumul correspondant aux totaux des 5 voies de comptage sont ceux qui posent problème...
Le registre de la tic n’est pas impacté puisqu’il est récupéré toutes les secondes sur le compteur Enedis. Idem pour les compteurs à impulsion (eau/gaz).
Pour faire simple, en ce qui concerne l’électricité, toutes les mesures instantanées sont et restent correctes dans le temps, par contre les totalisateurs travaillant en float32 dérivent avec le temps qui passe !

Ok. Merci pour cette réponse.
Dernière question sur les compteurs de consommation du fichier totaux.json : peut-on considérer qu'il sont fiables au moins sur une journée, puisque je constate qu'ils ont 6 chiffres après la virgule, alors que les données du fichier log2.csv n'en ont que trois ?

Bon... J'ai pas du bien m'exprimer...
Le mieux est de prendre un petit exemple pour comprendre le problème !

Ci-dessous pour mémoire un petit tableau récapitulatif du float32 :


On considère un EcoCompteur avec deux voies de comptage utilisées sur les 5 (+ simple).
Sur la voie 2, j'ai le chauffage
Sur la voie 1 j'ai seulement une VMC de 50 Watts qui fonctionne à la demande
Ca fait 2 ans que mon EC est branché. Sur la voie 2 j'ai cumulé 5000 kWh et sur la voie 1, 100 kWh

--> A partir du graphique joint, je déduis :

1/ Pour la VMC, l'EcoCompteur ne pourra rajouter chaque seconde QUE des multiples de 14 Watts. Donc si la conso est >= 7 et < =14, il comptera 14. Si le conso est < 7 il comptera 0.
2/ Idem pour le chauffage, sauf que là on est sur un pas de 3600 Watts !

- A 10H00 je mets en route ma VMC de 50 Watts pour 1 Heure. Idem pour le chauffage qui consomme 7000 Watts.

De 10H à 11H, l'EC va compter :
-> En instantanné 50W (+4.8% environ) pour la V1 et 7000 W (+4.8% environ) pour la V2
--> En cumulé :
-> 56 Wh pour la VMC (4*14 est plus près de 50 que 3*14) au lieu des 50 du Linky, j'ai donc +12% d'erreur sur la voie 1
-> 7.200 kWh pour le chauffage à la place des 7000 Watts soit environ +3% d'erreur par rapport au Linky sur la voie 2
Au total il va me compter 7.256 kWh à place des 7.050 réels soit +2.9% d'erreur


- A 11H00 ma VMC tourne toujours avec 50W, par contre le chauffage diminue et ne condomme plus que 1700 Watts.

De 11H à midi, l'EC va compter :
-> En instantanné toujours 50W pour V1 et 1700W pour V2
---> En cumulé :
-> 56Wh pour la VMC, rien n'a changé pour la voie 1 on est toujours sur le même LSB Puissance
-> 0kWh pour le chauffage puisque la valeur d'incrémentation MINIMALE /seconde pour un compteur à plus de 4194.304kWh est de 3600 Watts ! A 1700 Watts on est en dessous de 1800W (la 1/2 de 3600W), donc c'est plus précis de compter 0 que de compter 3600 ! (Si mon chauffage avait tiré 1810W, il m'aurait compté 3600W).
Au total il va donc me compter 0.050kWh à la place des 3.650 réellement consommés........ Horreur !

C'est l'exemple extrême bien évidemment. Dixit le service recherche & développement de Legrand, sur les 5 voies au final les erreurs se compensent... Le problème c'est que ce n'est pas du tout le cas pusiqu'on s'aperçoit de la dérive qui augmente sans cesse et surtout en fonction des valeurs des compteurs et de la conso instantannée, on peut très bien imaginer que la conso du chauffage va être majorée fortement ete que celle de la recharge de la voiture électrique au contraire fortement minorée. Au final la somme des deux erreurs en cumulé peut effectivement se neutraliser et faire apparaître une faible erreur par rapport au linky mais en fait la conso de la voiture sera passée dans le chauffage !

Pour un électricien du dimanche on peut comprendre qu'il se fasse avoir de la sorte mais pour un géant comme Legrand... Je n'ai toujours pas compris comment ils ont pu pondre un tel système et que la réglementation RT2012 laisse faire !

Ce qui est particulièrement "couillon" c'est qu'ils auraient pondu des fichiers CSV avec des relevés de conso horaire et journalier au lieu de relevés de compteurs totaux, l'affaire était pliée ! A charge pour l'utiisateur de faire ses additions sous excel s'il souhaite avoir un relevé de compteur


Donc je pense que vous avez compris de vous même la réponse, les fichiers CSV sont impactés par le problème du Float32 (chaque voie de manière différente suivant la valeur atteinte) et les totaux via le JSON idem puisque ce sont les valeurs qui sont enregistrées dans les CSV. S'il y avait eu un JSON capable de ne récupérer QUE la conso de l'heure ou la journée passée(s) c'était bon !
Là on ajoute toutes les secondes une toute petite quantité d'électricité à une énorme correspondant à 2 ans (cf mon exemple) de conso ! En Float32 c'est pas super comme type de calcul ! ... Même avec 3 chiffre après la virgule
Donc le seul moyen de rétablir des données fiables, c'est de se fixer un seuil de précision accetable au delà du quel les compteurs doivent être remis à zéro !

En espérant avoir éclairci quelques lanternes....

J'avais bien compris cette problématique, mais je me demandais si l'information contenue dans les compteurs
~LG536 2 12724$ à ~LG536 10 12724$ était elle aussi touchée par le bug.
S'il est certain que les fichiers .csv et .bin sont affectés, je n'en étais pas sûr pour ces compteurs, qui sont au niveau le plus "basique" du stockage sur l'Ecocompteur.
J'ai donc mis un de ces compteurs à un chiffre élevé (autour de 10000 kWh de mémoire), et effectivement le bug est présent même sur ce compteur de base.

Bonjour à tous,

Nouveau sur ce forum, je vous remercie pour toutes les informations trouvées sur ce fil concernant l'écocompteur et sa dérive sur les totaux..
Souhaitant m'équiper d'un équipement de ce type mais sans trouver vraiment d'équivalent, je me demandais si, à votre connaissance, la nouvelle version de ce compteur (412033) souffrait encore du même bug ou si celà avait été (enfin) corrigé par Legrand ?

Merci d'avance pour vos réponses

Ziz a écrit : 19 févr. 2022, 16:29 En m'inspirant des requêtes http qui passent quand on paramètre l'écocompteur (notamment le tarif du kwh), je suis enfin arrivé à trouver un moyen de faire un reset des compteurs ! J'avais essayé dans un premier temps de le faire par telnet, avec la commande RESOBJ, mais pour une raison qui m'échappe, ça ne marche pas.
Bref, via des requêtes web, c'est finalement plus pratique, et ça donne :

Code : Tout sélectionner

http://192.168.xxx.xxx/wp.cgi?wp=536+2+12724+-1+-1+4+0.0
http://192.168.xxx.xxx/wp.cgi?wp=536+4+12724+-1+-1+4+0.0
http://192.168.xxx.xxx/wp.cgi?wp=536+6+12724+-1+-1+4+0.0
http://192.168.xxx.xxx/wp.cgi?wp=536+8+12724+-1+-1+4+0.0
http://192.168.xxx.xxx/wp.cgi?wp=536+10+12724+-1+-1+4+0.0

Hello,
Je débarque ici alors que j'utilise HomeAssistant mais je voulais remercier tous ceux qui ont participé à fournir cette mine d'informations. Ce bug de float est vraiment ridicule, mais le compteur 412032 étant bien pire vu que full cloud (et j'ai essayé les API, elles sont pourries, rate limitées, renvoient n'importe quoi, et bien sûr on va pas poller le cloud toutes les minutes pour les puissances...), c'est sur un 412000 que je vais partir.

Si je comprends bien, avec la technique automatisée si dessus pour reset les index, et avec le fait que la classe de sensors "total_increasing" de HomeAssistant (https://developers.home-assistant.io/bl ... ass_total/) a une fonctionnalité de détection de reset auto, je devrais être en mesure de mettre quelques curl en crontab et ça devrait être transparent...

n_estre a écrit : 15 août 2022, 12:06 Bonjour à tous,

Nouveau sur ce forum, je vous remercie pour toutes les informations trouvées sur ce fil concernant l'écocompteur et sa dérive sur les totaux..
Souhaitant m'équiper d'un équipement de ce type mais sans trouver vraiment d'équivalent, je me demandais si, à votre connaissance, la nouvelle version de ce compteur (412033) souffrait encore du même bug ou si celà avait été (enfin) corrigé par Legrand ?

Merci d'avance pour vos réponses

Ne prends surtout pas le 412033 si tu veux faire de la domotique. Il est complètement firewallé sur le LAN et le seul moyen d'accéder à ses données c'est d'utiliser le cloud (tout pourri, qui est plus est) Legrand/Netatmo.