Eco compteur Legrand

[Lavabre]

Petite idée "naive" pour régler le problème...:

1/ Entre 00h02 et 00h59, on récupère les dernières données horaires des 5 tores du fichier horaire CSV de l’EcoCompteur
2/ On récupère ensuite les données cumulées des 5 tores via 1 requête JSON
3/ On soustrait pour chaque tore à la valeur JSON la valeur du CSV
4/ On réinjecte ces 5 valeurs dans les 5 tores de l’EcoCompteur

Moralité à 01h02 On a exactement la consommation de l’heure dans le fichier csv de l’eco compteur. Les suivantes rien ne change, par rapport à aujourd'hui, ce sera un cumulé de la journée.
A 00h02 le lendemain, on récupère exactement la conso du jour dans le fichier csv. Le fichier journalier ne contiendra plus de ce fait le relevé du compteur mais la consommation du jour... ce qui nous intéresse !
Pour le fichier horaire csv, il faut déduire comme actuellement de chaque heure (sauf la première bien évidemment) la valeur de l’heure précédente pour avoir un relevé de conso horaire journalière et pas un relevé de compteur.

La précision de l’EcoCompteur ainsi sera maintenue à son maximum constamment et avec un minimum de programmation en python !

[Ziz]

J'ai fait un script dans cet esprit, mais sans utiliser de requête json au final :

• il récupére le CSV journalier juste après minuit
• le concatène avec un CSV local à mon RPI qui contient l'historique des consommations complet. Ce n'est pas une simple concaténation, car le CVS de l'écocompteur subit régulièrement des resets. Du coup, il y a un recalage en valeur absolue des consommations données par l'écocompteur
• il en fait une synthèse (journalière, mensuelle, annuelle) dans un json pour une présentation d'une page web
• il regarde si un reset de l'écocompeur est nécessaire

.....

Voici une première version de ce script qui semble fonctionner. A voir après quelques jours si tout se passe bien ....

Dans le fichier joint, il faut personnaliser 2 ou 3 trucs, notamment :

Code : Tout sélectionner

ECOCPT_ADDRESS
CIRCUIT_NAME
CORREC_COEFF
LSB_LIMIT

Et ça doit ensuite marcher assez naturellement, enfin j'espère !
On peut jouer sur le niveau de log : en mode INFO, j'ai pas de log, sauf en cas d'erreur. En mode DEBUG, il y a quelques logs pour voir les transactions avec l'écocompteur.
L'ouverture de session ftp est très variable chez moi : quelques dixièmes à quasiment une minute. Je ne l'explique pas. Mais cela vient sans doute de l'écocompteur, car en regardant les traces réseaux, il est très long à répondre parfois. J'ai besoin de cette connexion ftp pour effacer le fichier LOG1.csv en cas de reset des compteurs.

Dans une future version, j'ajouterai sans doute un mail de notification en cas d'erreur, car je ne vais pas m'amuser à regarder les logs tous les jours. Mais si la partie critique plante, à savoir le raz compteur, et que le travail est fait qu'à moitié (le fichier n'est pas effacé), normalement ce sera détecté le lendemain et il s'arrêtera avant de pourrir le fichier d'archive des consommations.

Edit du 21/02 19:15 : mise à jour du fichier joint pour ajouter une notification par mail
Edit du 22/02 22:00 : mise à jour du fichier joint pour traiter le cas particulier du premier lancement où l'archive locale n'existe pas

[Lavabre]

J'ai un problème pour essayer votre appli Python car le fichier LOG1_ARCHIV.CSV n'existe bien évidemment pas par défaut.

J'ai essayé de le créer mais mes connaissances en python restant très basiques, je n'ai pas réussi malgré la création d'un CSV contenant les différents champs qu'il me semblait lui falloir...

[Ziz]

Ah ben oui forcément... J'avais oublié de traiter ce cas là pourtant inévitable. C'est corrigé dans le fichier en PJ du post initial. Tout n'est pas propre encore, par ex. si ce même fichier d'archive ne peut être sauvé à la fin (pb de droits), ça doit planter sans traitement propre. Idem pour le json. J'ajouterai quelques try l'occasion.

[Lavabre]

Juste une remarque concernant votre appli python :

Dans la déclaration de constantes, vous indiquez :
VAR_TO_RAZ = {(536, 0, 12705), (536, 2, 12724), (536, 4, 12724), (536, 6, 12724), (536, 8, 12724), (536, 10, 12724)}

Vous l'utilisez ensuite dans la fonction "raz_counters(address)" :
try:
type_var = 4
value = 0.0
for var in VAR_TO_RAZ:
family = var[0]
idx = var[1]
reg_nb = var[2]
url = f"http://{address}/wp.cgi?wp={family}+{idx}+{reg_nb}+-1+-1+{type_var}+{value}"
logging.debug(f"Appel de {url}")
requests.get(url)

Or un ensemble n'a pas d'ordre défini en python.
Print (VAR_TO_RAZ) donne par exemple :
{(536, 4, 12724), (536, 0, 12705), (536, 2, 12724), (536, 8, 12724), (536, 10, 12724), (536, 6, 12724)}

Vous uilisez systématiquement value = 0.0 ce qui ne provoque pas de problème dans la boucle puisque toutes les valeurs sont identiques, mais si on utilise des valeurs de value différentes, n'est-ce pas la porte ouverte pour entrer des données dans de mauvais compteurs...

Ne serait-il pas plus judicieux d'utiliser à la place la déclaration de contante :
VAR_TO_RAZ = [(536, 0, 12705), (536, 2, 12724), (536, 4, 12724), (536, 6, 12724), (536, 8, 12724), (536, 10, 12724)]
pour avoir une liste dans un ordre fixé et être certain dans la boucle de ce que l'on fait ?

[Ziz]

Il n'y a pas de problème à mon sens. C'est une ensemble de tuples. L'ordre de modification des registres de l'écocompteur est indéterminé, mais python ne va pas mélanger un élément d'un tuple avec un élément d'un autre tuple.

Si vous voulez valoriser les registres à autre chose que 0, les tuples qui sont aujourd'hui des triplets doivent devenir des quadruplets :

Code : Tout sélectionner

VAR_TO_RAZ = {(536, 0, 12705, 1.12), (536, 2, 12724, 2.23), (536, 4, 12724, 3.34), (536, 6, 12724, 4.45), (536, 8, 12724, 5.56), (536, 10, 12724, 6.67)}
.....
.....
value = var[3]

Dans l'exemple, 1.12 ne sera probablement pas affecté en premier, mais il sera bien affecté en utilisant les autres éléments de son tuple : (536, 0, 12705)

[Lavabre]

J'ai un peu adapté votre python à ma sauce...
Ca fonctionne parfaitement, tout s'est bien déroulé cette nuit.
Le seul problème que j'ai c'est la remise à zéro du premier compteur à impulsion...
J'ai essayé différentes requêtes à ces adresses :
data6m3 ~LG528 0 12205$
C6 ~LG538 0 12907$
c6_part? ~LG538 0 12908$
eauFroideImp1 ~LG538 0 12910$
c6m3_part? ~LG538 0 12914$

Mais rien n'a fonctionné...
Pourtant la requête JSON sur le ~LG538 0 12907$ fonctionne parfaitement !
Si vous aviez une idée sur la requête http://192.168.xxx.xxx/wp.cgi?wp=zzzz+z ... 1+-1+4+0.0 pour remettre à une valeur définie ce compteur d'eau, c'est la seule chose qui me manque !
Merci...

[Ziz]

Je n'ai pas de compteur à impulsion, je n'ai jamais creusé de ce côté là. Comme pistes, je dirais :

• il faut essayer de modifier le compteur "brut", et non une variable re-calculée dépendante de ce compteur. eauFroideImp1 par exemple si c'est le nombre d'impulsion détectée.
• si l'écocompteur comptabilise réellement un nombre d'impulsion, ce compteur est peut-être un entier. Et dans ce cas, il faut essayer de jouer sur le type de la variable à affecter. Le 4 dans la requête est je pense pour dire qu'on affecte une variable de type float. Mais je ne suis sûr de rien là dessus. Pour des types string, j'avais vu passer un autre chiffre. C'est en jouant avec le mode Inpecteur du navigateur que j'ai vu passer ces requêtes.

[Lavabre]

Je ne suis malheureusement pas parvenu à faire ce que vous indiquez sur le navigateur, et modifier la valeur "4" par une autre n'a rien donné.

J'ai essayé de lister toutes les valeurs dans les JSON et j'ai remarqué que les seules qui donnent le litrage du c6 sont :
"data6m3":"~LG528 0 12205$,
"data6":~LG538 0 12907$,
"data6":~LG538 0 12908$,
"c6m3_part?":~LG538 0 12914$
Toutes ces valeurs sont identiques et fonction du volume de l'impulsion réglable dans les paramètres.
Le volume de l'impulsion est accessible ici : "CNT1":~LG528 0 12204$, toujours pour l'eau
Ce dernier est également très bien modifiable par la requête http://192.168.0.8/wp.cgi?wp=528+0+1220 ... +4+0.00100
Dans ce cas, 1 impulsion = 1 litre ou 0.001 M3

Je me suis aperçu que si on règle cette variable à zéro, le volume total d'eau
sur tous les champs :

"data6m3":"~LG528 0 12205$,
"data6":~LG538 0 12907$,
"data6":~LG538 0 12908$,
"c6m3_part?":~LG538 0 12914$

Passe alors à zéro !

Si on remet la valeur de l'unité à 0.00100, le volume total de l'eau reste curieusement à zéro (ce qui semble montrer l’absence de compteur d’impulsion...) et le décompte repart normalement. C'est une manière pas très propre de remettre la valeur du compteur d'eau à zéro mais ça marche...
Bien évidemment par cette "méthode" impossible d'affecter une valeur particulière autre que zéro à ce champ !


J'ai essayé de trouver une association susceptible de retomber sur une valeur d'impulsion, mais mis à part celles listées ci-dessus je n'ai rien trouvé. Je ne comprends d'ailleurs pas pourquoi il y a plusieurs champs pour une même variable ?
Si vous avez une meilleure idée je suis preneur !

[Lavabre]

Problème du même genre (mais beaucoup moins gênant) pour remettre à zéro la répartition totale en € :
T1 ~LG535 0 12604$ correspond au prix de base du kWh. Il est parfaitement modifiable et a un effet sur le total ~LG536 0 12715$.
Si on le met à zéro, le total passe à zéro.

Le total des 5 voies :
"Voie1":~LG536 2 12715$
"Voie2":~LG536 4 12715$
"Voie 3":~LG536 6 12715$
"Voie 4":~LG536 8 12715$
"Voie 5":~LG536 10 12715$
ne se remet en revanche pas à zéro et une requête http dessus reste également sans effet