Compteur triphasé

[leboucher7]

Bonjour,
Je débute sous HA, j'étais sous jeedom avant.
Ma clé zlinky fonctionnait sur mon compteur triphasé, est-ce que je peux aidé d'une quelconque manière pour faire évoluer lixeeticdin vers une prise en charge des compteurs triphasés ?
Merci

[InnoGreenTech]

Bonjour, j'ai simulé les trames d'un compteur triphasé y compris les trames courtes, avec l'aide d'un arduino, puis j'ai modifié quelques que lignes du développement de hekmon. Cela semble bien fonctionner, grâce à Hekmon,car le travail est presque aboutit. Hekmon je peux vous envoyer la modification si vous le souhaitez, à l'occasion je ferais des tests pour le mode standard.

[hekmon]

Mon temps libre est assez limité mais avec un peu d'aide ca devrait être possible !

La principale particularité des compteurs triphasés est ce qu'Enedis appelle les "trames courtes" qui sont émises en burst lors d'un évènement qu'elles décrivent (voir p17 du document d'Enedis sur le TIC):

Pendant la présence d'un dépassement d'intensité de réglage sur l'une quelconque des phases (au moins) et pendant la minute qui suit la disparition du dernier dépassement, des cycles de 20 trames courtes suivies d'une trame longue sont émis

Ici donc le coeur doit être modifié afin que certains compteurs (ADIR{1..3} et IINST{1..3}) aient une durée de vie "limités". En effet puisque le thread de lecture continue du flux série mets à jour un cache en mémoire dans le module, si le module n'efface pas ces valeurs à la fin de l'évènement, celles-ci resteront en mémoire quand HA viendra les chercher: cela donnera l'impression, depuis HA, que l'évènement est encore en cours (il ne se terminera jamais).

Ici la clé du support d'un compteur triphasé sera donc la correcte détection par le module de la fin d'un évènement et l'effacement des valeurs du cache du module (les modules devront retourner "vide" hors d'un évènement).

Le core du module comporte déjà la détection de rotation d'une frame complète, les interrogations sont donc les suivantes:

• la fin d'un évènement devrait théoriquement pouvoir être détecté par l'enchainement de 2 trames longues, ce qui est facilement faisable... en théorie (cf point suivant).
• est-ce que les frames courtes comportent les mêmes caractères de fin que les trames longues ? Étant donné que certains des éléments du module se basent sur le compteur de frame cela pourrait avoir des conséquences imprévues.
• si même caractère de fin, comment à la fin d'une trame, correctement détecter le type de trame qui vient de passer ?
• comment designer des tests que je puisse faire faire à distance pour s'assurer que le module fonctionne correctement ? (moi qui est l'habitude de développer en faisant des tests en live et en y détectant des choses qui me paraissent bizarre au moment ou elles surviennent, difficile de fonctionner comme ca à distance...)

Donc pour la suite je dirais:

• création d'une branche de développement v1.3.0-beta
• utilisation du travail de @InnoGreenTech comme point de démarrage (merci ! serait-il possible d'avoir une merge request pour le récupérer ?) sur cette branche
• N releases beta sur cette branche en avançant à tâtons avec vos les retours
• avant une release finale v1.3.0 il me faudra un retour ici de plusieurs personnes ayant un triphasé qui confirment le bon fonctionnement (mais vous pourrez continuer d'utiliser la version beta sans soucis)

Qu'est-ce que vous en dites ?

[hekmon]

Je rajouterai un petit bémol cependant, ces trames courtes sont émises en boucle de 20 pour une bonne raison: lors d'un évènement une granularité supplémentaire est voulue pour suivre l'évolution de l'évènement.

Actuellement le design du module est fait en "pull": c'est HA qui vient chercher l'info "quand ca lui chante" (toutes les 30 secondes actuellement, voir #1 pour plus de details). Ce qui est un peu contraire à la nature de d'un évènement ponctuel et rapide.

Une des solutions serait d'avoir ces compteurs en push et non en pull, mais cela va augmenter un peu la complexité du module (et son temps de dev/tests). Peut être à faire dans un second temps.

[leboucher7]

Super !
merci de t'intéresser à mon problème, comme je l'ai dit je suis actuellement sur jeedom puisque cette fonction d'analyse en triphasé m'est indispensable dans le sens où je m'en sers pour gérer un délestage. J'ai conserver HA sur un deuxieme SSD je peux donc switcher rapidement entre l'un et l'autre pour vous faire des retours sur les différentes releases.
Pour ce qui est de développer je ne m'y suis jamais encore penché sur jeedom, donc sur HA...

[leboucher7]

Les fichiers de config du lixee sous jeedom ne t'aideraient en rien ?

[InnoGreenTech]

Ok pour moi,

Il faut juste que je me remette dans le bain des commandes github

[hekmon]

@leboucher7 pas d'inquiétude sur le dev, votre rôle sera le testing "en conditions réèlles" ;)

@InnoGreenTech si cela peut aider:
https://docs.github.com/fr/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork
https://docs.github.com/fr/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

[hekmon]

Pardon pour le long moment sans nouvelles... Je ne me suis pas contenté de rajouter le triphasé mais j'en ai profité pour revoir toute l'intégration du plugin à HA et préparer une v2:

• plus de configuration YAML mais directement dans l'UI (config flow)
• option temps réel pour certains senseurs de base (feature nécessaire pour les burst en tri phasés mais appliqués à d'autres si l'utilisateur le souhaite)
• ajout d'un périphérique agrégeant tous les senseurs
• détection du constructeur
• nouveau nom de plugin (plus universel)
• support de plusieurs linky en // si nécessaire
• et bien évidement ajout du support triphasé et de ses senseurs

Alors les détections de frame courtes ont été développées "à l'aveugle" et avant de pouvoir finaliser la sortie de cette v2 j'aurai besoin des logs de debug de l'intégration pendant que ces trames sont émises pour bien valider le fonctionnement @leboucher7.

Une beta arrive bientôt avec les instructions d'installation et de configuration pour les logs debug :)

Pour le teasing:

[keweki]

Bravo pour ce teasing : l'ajout de la fonctionnalité temps réel est vraiment une plus value !
J'en ai profité pour regarder mon HA que j'ai délaissé depuis plusieurs semaines : plus aucune remontée du plugin... En vérifiant si le câblage n'avait pas bougé sur mon linky : je me suis aperçu que mon compteur est passé en mode standard sans aucune demande de ma part :( suis-je le seul dans ce cas où Enedis ce serait-il lancé dans un déploiement de mise à jour qui basculerait le mode historique en mode standard ? J'hésite à demander un retour arrière auprès d'Enedis pour justement pouvoir encore profiter de ce plugin : la prise en charge du mode standard est-elle dans les tuyaux ? Encore bravo pour tout ce travail réalisé !

[hekmon]

La 1ère beta est disponible ici.

Prenez bien le temps de lire le nouveau manuel sur la page de la branche de développement notamment pour la migration v1 -> v2 (la branche principale reste pour le moment sur la dernière version stable soit la v1.2.0).

Pour valider cette beta j'aurai besoin d'analyser les logs de l'extension en mode debug lors d'un passage en rafale des trames courtes d'un compteur triphasé comme discuté @leboucher7 .

Pour activer les logs en mode debug simplement pour l'extension voici le bloc de configuration à avoir:

logger:
  default: info
  logs:
    custom_components.linkytic: debug

Attention c'est très verbeux :)

Pour les autres en monophasé vous pouvez aussi profitez de la beta, notamment du nouveau mode temps réel.

Bonne fêtes à tous !

[hekmon]

@keweki tout d'abord merci !

Je n'ai jamais entendu parler d'un compteur qui passerait automatiquement en mode standard pour être honnête 🤔

Concernant la prise en charge du mode standard je dirais qu'elle est voulue... mais pas (encore) prévue. Ajouter le triphasé m'aura nécessité tout le (peu de) temps libre que j'avais ces 3 dernières semaines et une fois la version finale déployée je pense faire une petite pause sur le code. Et vu les gros changements que celui-ci implique, la seule manière sereine que j'envisage est d'y passer moi même pour être capable de le tester moi même pendant son développement.

Donc oui... mais un (autre) jour :)

Honnêtement si vous n'êtes pas producteur d'énergie vous n'avez aucun impératif à être en mode standard. Effectivement peut être qu'envisager le retour en arrière est une solution plus simple et plus rapide. Et si vous contactez Enedis pour savoir la raison du changement, je serai curieux de la connaître !

[leboucher7]

Super boulot,

Je fais ça juste après les fêtes, là j'ai pas le temps.

Merci pour ton implication 

[Makimax35]

Bonjour, de mon côté, j'ai migré de la v1 à la v2 en 30 secondes et tout fonctionne à merveille (pour ma part monophasé historique). C'est vraiment appréciable d'avoir une solution simple à installer, légère, rapide et efficace.
Le mode temps réel fonction parfaitement aussi. L'interrogation est au niveau de ce qui est historisé des 24 entités et de ce qu'il est possible de limiter mais j'imagine que c'est un autre sujet. Pour ma part la consommation via le module energy est important pour comparer des années / mois, et la puissance instantané en temps réel pour rechercher un "récepteur coupable".
Encore merci pour le travail et le partage.

EDIT : J'ai fait une erreur désolé, mon module n'est pas un GCE mais un Cartelectronic : https://www.cartelectronic.fr/teleinfo-compteur-enedis/17-teleinfo-1-compteur-usb-rail-din-3760313520028.html