Eco compteur Legrand

[Aile]

Bonjour à tous,

Je suis nouvellement inscrit sur le forum (merci de m'accueillir), et débutant en domotique pour ma nouvelle maison.

Ayant acheté l'écocompteur Legrand (412000), j'ai lu avec attention les neuf pages.
Merci à DenisMartin pour le plugin, et aux divers intervenants pour ces analyses très poussées.

J'ai bien compris que les compteurs internes étaient irrémédiablement affectés par l'erreur de comptage, mais qu'en est-il des données enregistrées sur Domoticz ? D'après ce que j'ai compris, ces données sont enregistrées "au fil de l'eau", la base domoticz.db ne devrait donc pas être affectée par ce bug ?
Quelqu'un pourrait confirmer ?

Merci

[Ziz]

Je ne suis pas sûr de bien comprendre cela :

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.

Si la puissance de la pompe est constante à 30/40 W, avec un index L1 de 150kwh, l'écocompteur devrait incrémenter la consommation de 56 Wh chaque heure. Que veut dire ce 15 ?

Autre point :

(incrémentation de 28 watts toutes les seondes pour une conso instantannée > 14W jusqu'à l'indice 66kWh.

J'ai l'impression que vous êtes décalés dans la lecture de mon tableau : en dessous de l'index 66 kwh, donc entre 33 et 66 kwh, le "LSB puissance" est 14W et non 28W. Le 1/2 LSB vaut 7W et non 14W.

[Lavabre]

Je ne suis pas sûr de bien comprendre cela :
"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."

Si la puissance de la pompe est constante à 30/40 W, avec un index L1 de 150kwh, l'écocompteur devrait incrémenter la consommation de 56 Wh chaque heure. Que veut dire ce 15 ?

En fait la conso de la PAC à l'arrêt se divise en 2 :
1/ La conso de l'électronique (ce que j'appelerais le "bruit de fond") qui est constante autour de 20W
2/ La conso du circulateur qui se déclanche de temps à autre (aléatoirement ?) afin de limiter la formation de "boues" dans la tuyauterie.
Le total des 2 faisant entre 30/45 watts.
Donc au départ, au fil du temps, on doit tout compter (bruit de fond seul, bruit de fond avec circulateur, chauffage), ensuite uniquement quand le circulateur fonctionne et lorsqu'il y a chauffage et in fine uniquement lorsque la PAC tourne (chauffage).

"(incrémentation de 28 watts toutes les seondes pour une conso instantannée > 14W jusqu'à l'indice 66kWh."
J'ai l'impression que vous êtes décalés dans la lecture de mon tableau : en dessous de l'index 66 kwh, donc entre 33 et 66 kwh, le "LSB puissance" est 14W et non 28W. Le 1/2 LSB vaut 7W et non 14W.

Oui je suis allé un peu rapide et volotairement pour simplifier en partant du principe que de 0 à 66kWh le minimum de conso était de 14 Watts et en sautant les paliers 8,16 et 33 kWh. De toute façon (en ce qui me concerne), la conso sur chaque tore est soit nulle soit au moins de 20/30 watts. Donc n'étant pas mathématicien confirmé, ça ne me changeait pas grand chose au résultat mais me simplifiat la vie !

[Ziz]

J'ai bien compris que les compteurs internes étaient irrémédiablement affectés par l'erreur de comptage, mais qu'en est-il des données enregistrées sur Domoticz ? D'après ce que j'ai compris, ces données sont enregistrées "au fil de l'eau", la base domoticz.db ne devrait donc pas être affectée par ce bug ?

Je ne connais pas Domoticz, et encore moins le plugin. Il faut regarder ce que récupère Domoticz :

• si il récupère uniquement les puissances instantanées, pour ensuite faire sa propre intégration et en déduire les consommations, il n'est pas affecté par le bug de l'Ecocompteur. Cependant, avec cette méthode, dès que la récupération des puissances tombe (arrêt domoticz, problème réseau, etc), on perd un morceau d'historique qui ne sera pas récupéré.
• si Domoticz récupère les index de consommation, il récupère en même temps l'erreur d'intégration de l'écocompteur

[Lavabre]

Sinon, pour les passionnés, il ya la possibilité de récupérer les données instantannées en bash (sous linux).
Je laisse un simple exemple ci-dessous qui récupère (environ) toutes les secondes l'intégralité des mesures instantannées (et donc justes) de l'EcoCompteur.
Attention, c'est un simple exemple qui n'est pas bon car je lui fais faire une pose de 1 seconde entre 2 mesures. A cette seconde il faut rajouter le temps de récupération des données, donc on est à 1 sec. + X. Au bout d'un moment il y a un décallage mais c'est juste pour donner une idée si un "bricoleur" veut faire ensuite le traitement des données en python, bash ou autre via un Pi par exemple...
Mais évidemment comme le dit Ziz, il ne faut pas de coupure au niveau du réseau sinon.... On retombe sur du boulot à la Legrand !

Code : Tout sélectionner

 #!/bin/bassh
Entree1=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree1')
Entree2=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree2')
Entree3=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree3')
Entree4=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree4')
Entree5=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree5')
Entree6=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree_imp0')
Entree7=$(curl -s 'http://192.168.0.8/data.json' | jq '.label_entree_imp1')

while true
do
  Data1=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data1')
  Data2=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data2')
  Data3=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data3')
  Data4=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data4')
  Data5=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data5')
  Data6=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data6m3')
  Data7=$(curl -s 'http://192.168.0.8/inst.json' | jq '.data7')
  DTM=$(curl -s 'http://192.168.0.8/inst.json' | jq '.Date_Time')

  echo $Entree1 : $Data1
  echo $Entree2 : $Data2
  echo $Entree3 : $Data3
  echo $Entree4 : $Data4
  echo $Entree5 : $Data5
  echo $Entree6 : $Data6
  echo $Entree7 : $Data7
  echo $(date -d @$DTM)
  sleep 1
done

exit

[Aile]

J'ai bien compris que les compteurs internes étaient irrémédiablement affectés par l'erreur de comptage, mais qu'en est-il des données enregistrées sur Domoticz ? D'après ce que j'ai compris, ces données sont enregistrées "au fil de l'eau", la base domoticz.db ne devrait donc pas être affectée par ce bug ?

Je ne connais pas Domoticz, et encore moins le plugin. Il faut regarder ce que récupère Domoticz :

• si il récupère uniquement les puissances instantanées, pour ensuite faire sa propre intégration et en déduire les consommations, il n'est pas affecté par le bug de l'Ecocompteur. Cependant, avec cette méthode, dès que la récupération des puissances tombe (arrêt domoticz, problème réseau, etc), on perd un morceau d'historique qui ne sera pas récupéré.
• si Domoticz récupère les index de consommation, il récupère en même temps l'erreur d'intégration de l'écocompteur

Bonjour, merci pour la réponse.

Pour l'instant, l'écocompteur n'est pas encore installé. Je n'ai donc pas pu faire de tests.
Je vais jeter un coup d’œil aux sources pour voir comment s'est géré.
Sinon, rendez-vous dans un peu plus de deux mois pour le résultat des courses ...

[Lavabre]

A dans quelques mois ou semaines...
Mais le délai dépend en fait de la conso totale sur chaque tore mais également de la puissance demandée.
Moi j'ai un délai de 2 mois en été car sur la voie 5 j'ai une conso avec une puisssance moyenne et très régulière sur cette dernière et moins sur les autres voies. Au bout de 2 mois cette voie passe un cap qui fait que les erreurs ne se compensent plus par rapport au Linky.
Par contre en hiver la conso de la voie 1 est très importante, et irrégilière et avec des pics de puissance élevés. La dérive de la voie 5 (et bien évidemment de la 1) est "masquée" pendant quelques temps, mais là encore au bout d'un moment les erreurs ne se compensent plus par rapport au Linky. Si par exemple le temps devient plus clément et que la voie 1 (chauffage) ne consomme pas beaucoup et sur très peu d'heures, on aura subitement une grosse dérive par rapport au Linky. Le lendemain si la vioie 1 est "plein pot", cette dérive aura quasi disparu...

Voila, tout ça pour dire que le "délai de 2 mois" n'est pas le même pour tout le monde et n'est constant qu'en cas de conso journalière identique (régulière et continue sur chacun des tores) !
Il suffit de se référer au tableau parfait de Ziz et au relevé de l'EcoCompteur pour estimer à l'avance le moment où l'erreur d'enregistrement des données par Mr Legrand ne sera plus acceptable en fonction du seuil de tolérance de chacun.

De mon côté, je vais essayer à temps perdu de dédier un Pi Zero pendant un mois à récupérer les données de mesure de l'Ecocompteur. On récupère tous les tores 1 à 5 ainsi que les entrées dédiées au gaz et à l'eau mais également le relevé du Linky et le groupe date/heure. En actualisant cela toutes les secondes, il sera intéressant de voir la valeur de la dérive sur chaque voie.
Autre chose intéressante avec ce système, il est possible de récupérer le pic de conso journalier (voire même horaire) puisqu'on a le relevé du Linky avec l'heure à la seconde près. Il suffit de conserver la conso maxi totale mesurée sur une seconde (par heure ou par jour), chose que l'EcoCompteur aurait très bien pu faire...
Sinon autre solution, c'est de récupérer cette donnée chez Enedis mais c'est uniquement journalier.

[Lavabre]

En première approche, j'ai fait un essai dans un simple shell de récupération de l'intégralité des données de mesure instantannées de l'EcoCompteur toutes les 10 secondes.
Ces données comprennent les 5 voies de mesure, les 2 à impulsion, la valeur du Linky et la time stamp de l'EcoCompteur.
En faisant divers essais de réglage de l'intervalle de récupération des données, je me suis aperçu que la récupération des données toutes les 10 secondes était semble-t-il un très bon compromis, moyennant un léger correctif constant à déterminer (% d'erreur de mesure EcoCompteur/Linky) et probablement propre à chaque appareil (autour des -10% environ par exemple chez moi).
Sur cette période d'essai il y avait des appareils à conso constante ainsi que le four à conso variable.
L'etrapolation des données sur ces 10 secondes (on considère que la conso a été constante duarnt 10 secondes) est parfaitement en phase à l'issue de la période avec le total récupéré du Linky.
Une interrogation toute les 10 seconde permet sur un RPi pas forcément rapide de tenir la cadence sans erreur peut éviter de saturer l'EcoCompteur par rapport à X interrogations par secondes...
Reste à modifier un peu mon shell pour compter sur une plus longue période et récupérer toutes les heures et tous les jours l'ensemble de mes données dans deux .CSV... Refaire un EcoCompteur quoi ! mais avec en prime l'here du pic de conso

Autre chose interressante et (semble-t-il) passée inaperçue, c'est que la "time stamp" est également au format 32B. Moralité le 19 janvier 2038 à 04:14:08 (heure de Paris), tous les EcoCompteur se mettront à indiquer le 13 décembre 1901 21h45... Ca aura au moins le mérite de lé rajeunir...
Bon ceci dit c'est dans un peu plus de 15 ans, et en coupant la synchronisation avec les serveurs de temps, il suffira de régler manuellement la date au 19 janvier 1938 à XXhOO pour être tranquille avec pile 1 siècle de retard... Se rajoutera bien évidemment le poblème des années bisextiles si toutefois Legrand a pris soin d'en tenir compte...

[Ziz]

J'ai aussi implémenté un script en python3 pour déduire les consommations à partir des puissances délivrées par l'écocompteur. Je vais l'utiliser en parallèle du fichier LOG1.csv pour l'instant. Plus tard, LOG1 sera peut-être un backup de ce script en cas d'arrêt.

Si ça intéresse quelqu'un, le fichier est ici :
Et les explications en tête de script :

Code : Tout sélectionner

#!/usr/bin/env python3

# Ce script interroge l'écocompteur avec une période selon le paramètre ACQ_PERIOD pour récupérer les puissances
# instantannées sur les 5 circuits.
# Il fait ensuite une intégration au pas de 1 seconde pour déterminer les consommations sur ces 5 circuits.
# 2 fichiers de sortie sont produits :
#   * powers.csv : fichier de debug pour avoir tous les relevés de puissance
#   * indexes.csv : fichier de consommation avec un pas de 1 heure
# Les fichiers sont sauvegardés toutes les SAVED_PERIOD secondes, ainsi qu'à la fermeture du script
#
# Au démarrage du script, une lecture du fichier des index est réalisée pour repartir des dernières consommations
#
# Erreurs gérées :
#   * si l'écocompteur ne répond pas, on ignore et on retente au pas suivant
#   * si le fichier d'index ne peut être ouvert au démarrage, on part de consommations nulles
#
# Tests possibles :
# Commenter la récupération des données de l'écocompteur et instancier inst avec des valeurs à tester. Par exemple,
# en mettant 1W de puissance constante sur C1, on vérifie qu'on a bien chaque heure précisement 1 Wh.
#
# Précision :
# python utilise naturellement des float 64 bits (au moins sur x64 et rpi3 testés). En 64 bits, la mantisse est de
# 52 bits, soit 29 bits de plus que les 23 bits de mantisse en 32 bits. La précision est donc multipliée par :
# 2^29 = 536 870 912 !
#
# Performance :
# Sur un RPI3, pour un pas demandé de 1 sec, le pas réel (sleep 1sec + temps d'exécution) est d'environ 1.1 sec.
# Ce 1/10 de sec supplémentaire englobe à la fois le temps d'exécution côté RPI3, et le temps de requête/réponse à
# l'écocompteur. Les deux systèmes supportent donc bien un pas de 1 sec
#
# Personnalisation :
# Modifier les constantes en début de scripts

[Lavabre]

Merci j’aurais aimé le faire en python mais ne maîtrise pas trop la chose d’ou le shell de mon côté...
Quelques observations :

Sachant qu’il y a un temps de traitement incompressible mais également imprévisible (occupation momentanée RPi sur une autre tâche par exemple), je pense qu’il vaut mieux faire un sleep variable à chaque boucle.
Si DeltaT est le délai souhaité entre deux mesures :
1/ enregistrer le timestamp0 du rpi au lancement du .py
2/ à la fin d’une boucle récupérer le timestamp du rpi dans timestamp1
3/ timestamp0 = timestamp0 + DeltaT
4/ TS = timestamp0 - timestamp1
5/ si TS Inférieur à 0, TS=0
6/ sleep TS

Ça permet de se recaler toujours sur une période régulière depuis le lancement du .py.
si le rpi s’est décalé de x périodes pour une quelconque raison, il va se recaler automatiquement. Peu importe en fait que la mesure soit effectuée en début milieu ou fin de période, ce qui importe c’est qu’elle soit bien effectuée dans cette période. Après il suffit de multiplier la valeur de mesure récupérée par le délais réel entre les deux mesures pour obtenir les Wh en partant du postulat que durant ce laps de temps la conso est restée constante.
Si le rpi a laissé passer 30 secondes pour un DeltaT de 1 seconde, il va faire une première mesure qui va être à multiplier par 30 puis 29 qui vont être à multiplier par zéro si elles sont toutes faites dans la même seconde. La 31 ieme sera recalée dans la bonne période et à multiplier par 1 (cas du Delta_T = 1).

- Prévoir une correction d’erreur de mesure par rapport au linky éventuellement variable en fonction de la puissance soutirée est également quelque chose que j’ai rajouté dans le shell. En effet à 1kW soutiré la correction peut être de -10% mais à 8kW c’est par exemple -4% d’ou l’intérêt également de prévoir une correction indépendante sur les 5 voies de mesure (en partant du principe que chaque voie ait un taux de correction identique ce qui est probable mais pas évident je suis d’accord...)

- un fichier csv journalier en plus du fichier horaire comme le faisait legrand ?

- recuperer en plus de la valeur du linky le pic de conso horaire et journalier dans le .csv est également interessant ?

- sorties à impulsion style compteur d’eau ? La c’est comme pour la valeur du linky, c’est pas la même chose au niveau traitement que les voies 1 à 5 puisqu’on récupère la valeur du compteur et non pas la consommation instantanée. Il faut calculer cette valeur en faisant la soustraction entre la valeur actuelle de la boucle - valeur de la boucle précédente.

Voilà quelques idées... merci pour le partage. S’il y a des évolutions logicielles ultérieures je suis preneur !