Forum Domoticz en français

Non je n’utilise pas domoticz, j’ai fait un shell en bash sur un raspberry pi zero.
Il fonctionne parfaitement (cf. Tableau de données) mais le pauvre sature un peu avec... la gestion des nombres à virgule en bash est assez lourde...

Du coup je suis en train de me mettre au Python (ça fait un moment que c’était un projet en attente... ) dans l’attente de tout migrer en python. Mais c’est un peu long car je pars de zéro et seul...

Pour ce qui est du plugin domoticz, s’il récupère les données de conso en temps réel et fait ses calculs lui même, ça doit le faire ! Si le développeur a prévu un taux de correction c’est encore mieux, parfait même !
S’il récupére les données toutes les heures directement sur le fichier csv du Legrand, ça ne présente aucun intéret !

Pour ce qui est de Legrand, j’ai eu une fois une réponse du service recherche et développement comme quoi l’erreur liée au float 32b se corrigeait d’elle même avec le temps... Quand je leur ai demandé comment j’avais pu alors m’apercevoir du problème, je n’ai jamais eu de réponse !

C’est d’autant plus regrettable cette affaire qu’il ont fait un appareillage de mesure très précis et très fiable quelle que soit la puissance soutirée (cf mon tableau qui colle au wh près au linky sur 24hoo) et qu’ils ont tout gâché par la suite de par leur traitement des données !

Lavabre a écrit : 11 févr. 2022, 20:44 Du coup je suis en train de me mettre au Python (ça fait un moment que c’était un projet en attente... ) dans l’attente de tout migrer en python. Mais c’est un peu long car je pars de zéro et seul...

Tu peux sans doute t'inspirer du script en Python proposé par ziz le 31 janvier à 23:05 ?

Lavabre a écrit : 11 févr. 2022, 20:44 Pour ce qui est du plugin domoticz, s’il récupère les données de conso en temps réel et fait ses calculs lui même, ça doit le faire ! Si le développeur a prévu un taux de correction c’est encore mieux, parfait même !
S’il récupére les données toutes les heures directement sur le fichier csv du Legrand, ça ne présente aucun intéret !

Je lis sur le source du plugin : Donc, non !

Bonjour à tous,

Comme je ne désespère pas que Legrand répare mon Eco Compteur, je me suis fait un petit script lua qui récupère uniquement les données temps réel piochées à l'adresse http://ip.de.l.ecocompteur/inst.json
Je pense ainsi pouvoir résoudre le problème des arrondis, puisque c'est Domoticz qui va enregistrer les données.

J'ai créé un matériel "HTTP/HTTPS poller", et j'ai créé autant de dispositifs que de capteurs :

On a bien les consommations, même si les montants restent délirants (et encore, j'ai resetté l'éco compteur )

Le script (librement inspiré d'un membre du forum : Enamaryn) pour ceux qui sont intéressés :

Pour répondre à la question précédente, il est parfaitement possible d’écrire dans le répertoire SYS de l’eco-compteur.
Je viens en effet de créer un nouveau fichier JSON adapté à ce que je souhaite faire, c’est à dire récupérer dans une seule requête la valeur du linky, les 5 tores de mesure et les deux compteurs à impulsion (de base pour avoir ces infos il faut faire deux requêtes sur deux fichiers JSON distincts (INST.JSON et DATA.JSON et accessoirement virer tout le reste qui m’est inutile.

Le nouveau fichier JSON à rejoint ceux de Legrand dans SYS et tout fonctionne parfaitement bien quand on fait une requête dessus.

Bref, le répertoire SYS est bien accessible en lecture ET en écriture !

En pièce jointe un exécutable Python permettant de récupérer ses infos sur l'EcoCompteur.
Merci à Ziz pour sa version dont je me suis largement inspiré !

Pour que cela fonctionne, il est nécessaire de placer le fichier JSON rpi.json koint dans le répertoire /SYS de l'EcoCompteur (via FTP par exemple...). Ce rajout permet avec une seule requête d'obtenir toutes les mesures instantannées des 5 entrées tores, les valeurs des deux compteurs à impulsion (eau/gaz) ainsi que la valeur du Linky. Avec les JSON "de base" de Legrand cela nécessite 2 requêtes.
Ce fichier JSON corrige également un souci lié à la valeur du Linky qui est précédée de 0 (nombre variable en fonction de sa valeur) et qui sans rentrer dans les détails posait un problème lors de l'acquisition.

Le programme tourne en boucle et une suggestion sous Linux est de le lancer en SSH via screen ce qui permet de détacher l'application du terminal et donc de le laisser tourner après fermeture du terminal.

Il récupère les données sur l'EcoCompteur en fonction du pas fixé dans les constantes. Durant ce laps de temps la puissance soutirée est supposé constante. Un taux d'erreur est appliqué en fin d'heure correspondant à l''erreur de mesure des tores.
Par exemple chez moi, j'ai -4.22% d'erreur entre ce que me donnent les tores et la réalité. Il est à noté que cette valeur est constante et n'est pas liée à la puissance soutirée. J'ai donc gardé 1 seule valeur de corresction contre 5 au départ (une pour chaque tore en fonction de la puissance mesurée).
Un pas de 10/12 secondes (1 mesure toutes les 10 à 12 secondes) donne d'excellents résultats puisqu'on est en dessous de 1% d'erreur. Inutile (à mon avis...) d'aller récupérer des données toutes les secondes (l'EcoCompeur se mettant à jour 1 fois par seconde).
Pour info, sur un Raspberry Pi Zero (pas le 2W !) qui ne fait que ça, une boucle prend moins de 1/10 de secondes pour s'exécuter.

Un fichier horaire CSV est généré tout comme un fichier journalier (création au besoin si non présent).
Dedans figure la date, l'heure, la valeur de conso du Linky sur 1 heure (ou 1 journée), le total de l'EC sur 1 heure (ou 1 journée), le % du taux d'erreur, et les consommations horaires (et journalières) d'eau et de gaz.

Enfin le pic de charge (maximum de puissance soutirée) dans l'heure (et la journée) est indiqué avec son heure.
Pour info, ce pic de charge est calculé par l'addition des mesures des 5 tores.

Enfin, deux alarmes sont prévue (SMS et mail) en cas de conso d'eau anormale (constantes fixées en début de fichier). L'alarme SMS fonctionne via l'API de Free (pour les autres j'ignore s'ils le font...). il suffit de rentrer ses valeurs perso et on reçoit immédiatement un SMS dès que la Conso dépasse le seuil fixé sur 1 heure (1 seule alarme /heure).
J'ai également rajouté une alarme du même type sur 3 heures car par exemple une fuite d'eau (chasse qui fuit par exemple) peut ne pas être assez conséquente sur 1 heure pour déclencher l'alarme mais cumulé sur 3Hoo, ce ne sera pas le même cas... A régler suivant les besoins de chacun ! ;-) Cette alarme se déclenchera comme l'autre qu'une fois par heure.
Cette alarme est décativable en la mettant sur false à l'initialisation

Voilà, de quoi s'amuser si vous souhaiter personnaliser selon vos besoins ! ;

Je découvre avec ces posts qu'on peut déposer des fichiers Json personnalisé, et c'est fort pratique ! Merci Lavabre pour les explications fournies, qui m'ont permis d'améliorer l'interface entre l'ecocompteur et mon système domotique.

J'ai découvert au passage ce post qui contient une liste très utile sur les registres possibles :

DenisMartin a écrit : 29 avr. 2018, 15:38

Je me suis du coup créé un fichier json personnalisé qui permet de récupérer puissances et surtout consommations sans attendre la création du csv : On retrouve les 5 circuits que j'utilise, avec un nommage personnalisé pour le json.

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 : Chaque requête positionne la valeur du registre de consommation d'un circuit. Ex :

• circuit 1 : registre "536 2 12724", ce sont les 3 premiers paramètres
• valeur à positionner 0.0, c'est le dernier paramètre.
• les 3 autres paramètres (-1, -1, et 4), je ne sais pas à quoi ils correspondent. Quand on écrit une variable, j'ai l'impression qu'on a souvent (tout le temps ?) -1 et -1 et ensuite un quelque chose qui pourrait indiquer le type peut-être. 4 ici, par analogie avec ce que je vois passer quand j'enregistre la page Paramétrages/Unités

Du coup, maintenant, en plus de la récupération quotidienne des consommations du csv, je vais pouvoir aussi faire un reset quand ça devient nécessaire (dépassement d'un seuil d'index par ex., fonction les LSB désirés). C'est plus facile à automatiser qu'avec un trombone D'ailleurs, le trombone fait un reset un peu violent chez moi : je perds la conf réseau et les noms de circuit

J'abandonne la piste de récupérer les puissances très fréquemment pour faire l'intégration moi-même, car je n'ai pas de RPI dédié pour ça, et le faire via mon RPI domotique/HC, il y aura des trous à chaque fois que je dois le redémarrer.

@Lavabre : il y a peut-être une piste à creuser pour appliquer la correction d'erreur de xx% directement à la source sur l'écocompteur. Le fichier IC.OBI contient PROP_IC_VOL_TO_KWH_COEFF qui me semble être utile pour ça. Je n'ai pas creusé, car je n'ai pas de comparaison possible pour faire un recalage. Je n'ai que des consommations partielles que je ne peux pas confronter aux valeurs du Linky.

Bon très bien pour ces infos Ziz... et merci !

je vais très probablement m'orienter moi aussi sur cette voie là.

En ce qui me concerne j'ai un Pi Zéro qui est dédié à la gestion d'une centrale météo (enregistrements en base de données, gestion des stats, site html, archivage etc etc.) et qui donc tourne en 24/24.

J'ai dans l'idée de me refaire une petite appli en Python qui récupère toutes les heures les données directement via une requête JSON sur l'EcoCompteur (donc pas dans le CSV de ce dernier), et recrée les CSV de conso (pas la valeur du compteur) horaire et journalier avec les corrections d'erreurs qui vont bien.
Si à XXh00, le total d'un tore est supérieur à la précision souhaitée, on sauvegarde les fichiers CSV (au cas où...) et on remet tous les tores à zéro via la petite requête web qui va bien...
L'heure d'après on recommence à récupérer les données via la requête JSON et on continue les enregistrements. Moralité niveau utilisateur les fichiers CSV sont sans interruption et on conserve la valeur de précision que l'on souhaite au niveau de l'EcoCompteur !

C'est le "meilleur des deux mondes"... S'il y a une panne de réseau, la récupération à XXhoo sera à zéro sur tous les tores, mais récupérable ultérieurement éventuellement via l'EcoCompteur qui aura continué de son côté son comptage dans ses propres fichiers CSV !

Reste plus qu'à refaire mon fichier Py... Thank's Ziz...

Pour ce qui est d'aller modifier des fichiers de données directement au niveau de l'EcoCompteur, je ne suis pas trop partant en l'absence de documentation claire sur le sujet... Rajouter un fichier JSON ne présente aucun risque. Bidouiller des paramètres en aveugle peut très bien marcher puis bien plus tard causer des problèmes qu'il sera ensuite difficle de résoudre... Donc je préfère ma solution de correction d'erreur via le RPi !

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

Il me reste à valider la partie reset, je verrai ce qui se passe ce soir à minuit. Ensuite, je diffuserai ce script sur le forum.

Le résultat est ici : https://fliz.myds.me/stats/
Le json produit est https://fliz.myds.me/stats/consumptions.js

Bonjour

je viens de lire les 13 pages et je n'ai pas trouvé une solution qui me parait plus simple.
Contexte : je suis sous domoticz avec une connexion à la téléinfo de mon linky. Et mon problème est que j'aide un copain qui a acheté cet écocompteur legrand (ancienne version) avec un domoticz sur PI.
Nos 5 tores fonctionnent mais on voudrait comme j'ai sur mon domoticz, l'info du linky avec une visualisation toutes les 5 mn de la conso.

Nativement ce n'est pas possible à priori, puisque le compteur linky et donc son index de conso total, ne sert dans l'éco compteur qu'à faire une soustraction entre les tores et ce total, pour alimenter simplement le "Autres".

Pourquoi ne pas simplement interroger comme pour la téléinfo dans domoticz, toutes les 5 mn l'index Linky, et le passer à un compteur sous domoticz qui calculera la différence entre l'index de maintenant et l'index d'y a 5 mn ? cela permettra d'avoir des W (et non des VA qui sont les valeurs instantanées et sans intérêts). C'est ce que fait le plugin téléinfo de domoticz (bon, il interroge beaucoup plus souvent pour avoir en visu le conso instantanée, raffraichie toutes les 30s ou 1mn, mais ce n'est pas un besoin ici)

Je ne sais pas faire, mais je sais que ca répondrait au besoin général : avoir une courbe quotidienne dans domoticz, avec un point toutes les 5 mn, de la conso des 5 dernières minutes, ainsi que les barres toutes les heures de l'énergie consommées.

Pour cela il faut faire une requête non pas sur "inst.json" mais sur "data.json" et de récupérer l'index base ou HC/HP.

En somme faire comme ALLE a fait sur cette page mais avec data.json. Mais je ne sais pas faire.
Quelqu'un saurait faire ou ma solution n'est pas une bonne solution ?

fredclo a écrit : 20 févr. 2022, 19:24 Nativement ce n'est pas possible à priori, puisque le compteur linky et donc son index de conso total, ne sert dans l'éco compteur qu'à faire une soustraction entre les tores et ce total, pour alimenter simplement le "Autres".

Comme écrit quelques posts au dessus, il faut créer un fichier json dans le répertoire SYS avec ce contenu : Les consos des 5 tores sont mises à jours à la seconde. L'index de base (à adapter si c'est un tarif HP/HC)est mis à jour toutes les 5 sec je pense, c'est issu du téléinfo.
index_init est l'index à la dernière initialisation du compteur (première mise en service ou reset), et conso_total vaut index_base moins index_init.

Pour préciser mon précédent post, la "puiss_totale_apparente" ("~LG526 9 12005$") est la puissance apparente renvoyée par le linky. C'est différent de la puissance active mesurée par les tores. Il ne faut pas chercher à comparer les deux. La puissance apparente n'est pas utilisée pour la facturation, mais uniquement pour déclencher la disjonction du linky en cas de sur-consommation vis-à-vis de l'abonnement souscrit.
Par contre, cette puissance apparente n'est pas naturellement récupérée par l'écocompteur. Il faut aller patcher le fichier TI.OBI, en ligne 59, BBRHPJR doit être remplacé par PAPP. Un redémarrage est ensuite probablement nécessaire pour prendre en compte de patch.