linkytic
linkytic copied to clipboard
hekmon
Compteur triphasé
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
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.
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 ?
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.
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...
Ok pour moi,
Il faut juste que je me remette dans le bain des commandes github
@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
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:
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é !
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 !
@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 !
Super boulot,
Je fais ça juste après les fêtes, là j'ai pas le temps.
Merci pour ton implication
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
@Makimax35 merci pour le retour 👍
Concernant les sondes compatibles avec le temps réel, en monophasé il n'y en a que 3 (les autres ne présentent pas d'intérêt à l'être), le détails est sur le nouveau manuel (mais encore sur la branche de développement).
Hello @leboucher7 , avez-vous eu l'occasion de tester l'intégration sur votre compteur triphasé ?
L'intégration est prête à passer en v2 avec toutes ses nouvelles améliorations. Idéalement je préférerai la publier avec un retour de test sur le module triphasé, mais si vous n'avez pas le temps dans l'immédiat je pense la publier en stable avec seulement la partie triphasé marquée comme beta dans le manuel. Si correction il doit y avoir cela pourra se faire sur les versions suivantes.
Dans le cas où vous pensez pouvoir le tester d'ici février, pas de problème pour attendre encore un peu et tenter une v2 avec un module triphasé testé :)
Merci encore.
Bonjour
je souhaite savoir si il est possible d'obtenir l'injection vers le réseau ? si oui avez vous une procédure a me conseiller ?
rylo
Bonjour
je souhaite savoir si il est possible d'obtenir l'injection vers le réseau ? si oui avez vous une procédure a me conseiller ?
rylo
Sans vouloir trop m'avancer, il me semble qu'un Linky qui injecte de l'électricité dans le réseau est configuré en mode standard, mode qui n'est pas encore supporté par l'extension malheureusement.
Il est possible de vérifier sur le linky le mode du TIC actuellement configuré.
merci pour ton retour.
je viens de contrôler je suis bien historique mode TIC
Étrange, le document (voir section 6.1.1 page 15) du standard TIC ne parle pas de compteurs pour l'injection de courant pour le mode historique 🤔
j'ai les panneaux depuis 1 mois peut être le temps de faire la mise a jour du compteur. en historique c'est possible d'indiquer l'injection ?
Oui, je confirme que vois bien dans le document Enedis décrivant le TIC des compteurs pour l'énergie injectée en mode standard.
Donc de votre côté je dirais qu'il faut passer votre compteur en mode standard et partir sur une intégration Home Assistant qui supporte ce mode (certainement du côté d'un dongle zigbee + une intégration comme zigbee2mqtt vers Home Assistant pour rapatrier tout ca). Je compte un jour rajouter le support du mode standard dans cette extension mais je ne peux pas vous dire quand :)
Ce que je trouve étrange c'est qu'Enedis n'ai pas passé votre compteur en mode standard après votre déclaration (que ce soit pour l'auto consommation seule avec la CACSI ou la revente ce que vous semblez sous entendre, plus d'infos ici).
ok merci, je vais contacter Enedis demain pour en savoir plus sur le sujet je reviendrai faire un retour demain. je ne voudrais pas que cela pose soucis plus tard.
J'ai eu enedis mon dossier n'est pas encore a jour ils ont beaucoup de demandes et il avait l'air de me dire que c'etait pas obligé de passer en standard.
J'ai eu enedis mon dossier n'est pas encore a jour ils ont beaucoup de demandes et il avait l'air de me dire que c'etait pas obligé de passer en standard.
Intéressant, on en apprend tous les jours ! Par contre dans ce cas, vous n'aurez aucun compteur transmis sur le TIC mentionnant l'énergie injectée sur le réseau :)
tu veux dire que le TIC transmet l'injection seulement si on est en standard ?
tu veux dire que le TIC transmet l'injection seulement si on est en standard ?
De ce que je vois, oui. Pour être plus précis je dirais "les informations d'injection". L'injection est peut être possible mais non visible au travers du TIC en mode historique. Plus de détails dans le document de référence comme indiqué ici: https://github.com/hekmon/linkytic/issues/2#issuecomment-1414335370
Bonjour @hekmon , J'ai un compteur triphasé aussi et j'essaie de faire marché votre intégration (2.0.2) sur Home Assistant. De ce que j'ai compris de la doc il faut normalement que le module soit raccordé aussi directement à la box domotique. Dans mon cas j'utilise un Dongle Zigbee SONOFF pour récupérer les infos du ZLinky TIC. Comment bien configurer le module pour se connecter au TIC en remote ? J'ai essayé les différents protocol proposé par PySerial mais en vain.
Merci par avance.
Bonjour @YpNo,
Malheureusement cela ne fonctionnera pas :
- Mon module est uniquement à destination de ceux qui récupèrent la connexion série du TIC directement. Il va s'occuper de lire cette connexion série, la découper et la vérifier pour ensuite faire remonter les informations dans Home Assistant.
- Dans votre cas, votre module ZLinky se charge déjà de cette découpe : c'est lui qui gère la lecture de la connexion série. Une fois ces informations extraites, il va ensuite les repackager dans un autre protocole de transmission (le zigbee). Vous devez ensuite récupérer ces informations encapsulé dans le protocoles zigbee au travers ZHA (fonctionnement out of the box depuis peu) ou Zigbee2MQTT (qui lui même réencapsule la data en mqtt, un autre standard de communication que beaucoup utilisent avec Home Assistant).
Pour faire plus simple, cette intégration Home Assistant est faite pour le TIC-DIN mais pas le ZLinky_TIC !
Merci pour la réponse @hekmon, J'utilise déjà l'intégration avec ZHA mais je trouve votre module beaucoup plus complet ! C'est dommage :)
Bonjour, je début sou HA et j'ai installé Xilee sous ZHA . Il s'en mis à jour en V14 Mon problème est que mon compteur est reconnue comme un monophasé alors que c'est un triphasé (il manque les Tensions, intensité etc..) J'avais fait un essais sous HA via ZigBee2MQTT et j'avais tout les registres mais il frizzait rapidement ... Je suis donc revenu sous ZHA Question : avez vous un tuto pour récupérer les registres spécifique Linky Tri manquant ? Merci d'avance Alain
