cdlog2

bonjour,

Pouvez vous être plus précis. De quel dossier partagé parlez vous ?.

cdt

Bonjour,

La Doc du WES précise qu’il faut respecter l’ordre de câblage L1 et L2 de la téléinfo d’un Linky respectivement vis à vis des bornes 1 et 2 des entrées TIC du compteur côté WES.

L1 sur borne1 et L2 sur borne2. Vérifier Votre câblage ainsi que l’isolement des fils entre eux. Utilisez une seule paire ( 2 fils torsadées )

Parfois vous pourriez avoir un mauvais contact aux bornes du Linky, Tirer un peu sur les fils pour vérifier que la gaine plastique des fils ne rentre pas dans les plots de connections côté Linky.

Par ailleurs, êtes vous sur que le compteur Linky est bien configuré en mode Standard. (par défaut il est livré en mode historique). Essayez provisoirement de passer le compteur 2 production en mode historique pour Test. Enregistrer la config, fermer le navigateur, faites un Reset WES.

Si le problème existe toujours,  revenez dans le mode standard de la même manière (enregistrement config + Reset WES ).

Votre compteur Linky est très proche du WES, 1,2m d’après vos renseignements. Je n’ai pas l’expérience de ce qui suit, mais on sait que la tension de la téléinfo en sortie du Linky est plus faible qu’un compteur lamda d’un autre type et cela peut poser problème lorsque le WES est un peu trop loin du compteur Linky.

Par contre vue la vitesse de transmission en 9600 bauds en mode standard, ne pourrait il pas à l’inverse y avoir une saturation du Photocoupleur côté WES vue la proximité et y avoir une transmission un peu déformée. Je sais que parfois un ajout d’une résistance de 680ohms connectée entre L1 et L2 côté Linky pourrait peut être régler le problème ?

Peut être une question à poser à Nicolas ou à tester.

Cdt

Re: J’ai vérifié le circuits Hard interne au WES concernant les Tics et je m’aperçois que le Photocoupleur utilisé est le modèle V02630 composé d’une seule Led avec une diode externe connectée en tête bêche. Donc le schéma que j’ai présenté plus haut ne convient pas. Il faut inverser Tic1 et Tic2 du Schéma

Ci joint mon Schéma rectifié afin de l’adapter aux connexions TIC du WES. Il faut bien respecter le sens des Cnx TIC1 et TIC2 au niveau des bornes de raccordement.

De même il est précisé dans la Doc du WES qu’il faut respecter l’ordre des connections L1 et L2 de la téléinfo du Linky vis à vis des bornes Tic1 et Tic2 côté WES lors d’une liaison filaire directe.

Cdt

Bonjour

Juste pour rappel, le mode de transmission téléinfo du Linky est en mode :

– Standard = bauds:9600 parité:odd(impair) data-bits:7 stop-bit:1
– Historique = bauds:1200 parité:even(pair) data-bits:7 stop-bit:1

Donc il faut être sur du mode programmé pour votre contrat Enedis.

Si vous avez la main un peu bricoleuse et pour enlever toute ambiguïté concernant votre problème, vous pour réaliser le schéma ci-joint en volant sur un BreadBoard par exemple pour test.

Ce petit module permet d’étendre votre liaison Téléinfo Linky sur une longue distance. Il est alimenté en 5Volt.

Vous pouvez connecter la sortie de ce petit module sur un UART USB pour essais (convertisseur sérial USB (FTDI))
avec 3 fils : RXD, 5volt, GND. Dans cette configuration il faut connecter la résistance de 10k ohms en Option dans le schéma. Vous pourrez lire la téléinfo sur un PC depuis le Port Serie FTDI détecté via Hercule ou Terminal par exemple ou directement depuis un Arduino en mode réception sérial sur RX. Dans ce cas le +5volt et Gnd est fourni par le Arduino.

Vous pouvez aussi réaliser la connexion directement au WES via 3 fils : RXD, 5volt, GND.

Comme ce module ne consomme pratiquement rien, cous pouvez utiliser le 5volt et GND de la Cnx 1WIRE du WES et raccorder RXD sur un point Téléinfo du WES et l’autre point Téléinfo du Wes relié au 5volt 1WIRE comme précisé dans le schéma.

Comme l’interface Téléinfo dans le WES est un Opto Coupleur, une résistance doit normalement être mise en série dans la liaison, donc il est inutile de rajouter la résistance de 10k mise en Option dans le schéma dans le cas d’une liaison avec le WES.

Normalement ce module devrait fonctionner et résoudre votre problème de distance. Peut être à essayer ?

Mais si le problème vient du Linky exemple: Pb vitesse Transmission, seul un essais avec un Arduino vous permet de débuguer le problème.

Cdt

Si vous avez une autre paires de disponible dans votre câble, vous pourrez doubler vos fils comme suit :
Suivant les câbles téléphonique les couleurs par paire sont les suivants

ex: câble A
Blanc – bleu
Bleu  – bleu
Jaune – bleu
marron – bleu

ou

ex: câble B
Blanc – gris
Bleu  – incolore
jaune – orange
marron -violet

Les couleurs de droite s’appellent les accompagnants.

Comme il semble que votre section de 5/10 soit 0.5mm ne serait pas suffisant en section vue la longueur de 50m, Si vous avez une paire disponible dans votre câble et afin de limiter la diaphonie par l’utilisation de paires torsadés, essayez de doubler les fils en utilisant 2 paires pour la liaison mais en utilisant un fil de chaque paire pour LI et pour L2

exemple afin de conserver le même sens des torsades des 2 paires :

Si votre câble de type A  >> L1 = Blanc+Bleu  L2 = les 2 accompagnants bleu+bleu
Si votre câble de type B  >> L1 = Blanc+Bleu  L2 = les accompagnants gris+incolore

Cela vous donnera une section de 1mm en gardant la protection du déphasage entre les fils.

cdt

Génial Nicolas. En version V0_7G2, le data.cgx me renvoie <DEMAIN>…</DEMAIN>, texte vide.

Cdt

Je constate chez moi, dans la Réponse du WES à la requête Data.cgx en vers. 0.83H, une erreur dans le décryptage de l’Identifiant DEMAIN pour tous les 3 groupes TICs. Le résultat rendu par mon WES pour cet Identifiant ne respecte pas la règle des Balises du format CGX.

Je constate que cet Identifiant est rendu comme suit : <DEMAIN/>. Ce format peut ne pas être bien interprété par votre Parser XML Python
Les commandes WES pour ces Identifiants dans le fichier Data.cgx sont formatées ainsi pour les groupes Tic1, Tic2, Tic3:

c Td1 <DEMAIN>%s</DEMAIN>
c Td2 <DEMAIN>%s</DEMAIN>
c Td3 <DEMAIN>%s</DEMAIN>

Par contre la réponse à une requête data.cgx rendu par mon WES en 0.83h et pour les 3 Cdes Tics est le suivant : <DEMAIN/>
Normalement le WES devrait rendre une réponse avec une <balise d’ouverture>, Value , une </balise de fermeture> , <DEMAIN>…</DEMAIN>

Si vous lancez une requête data.cgx via votre navigateur ( http://192.168.x.x/data.cgx) et que vous constatez le même défaut que moi concernant la balise <DEMAIN> dans les Groupes <TICx> , alors il y a une forte chance que votre problème provienne de cela.

Si cela est le cas chez vous, Supprimer provisoirement ces 3 lignes (voir les 3 Cdes ci-dessus) de votre fichier Data.cgx, cela devrait corriger votre problème en principe ?!..

réponse partielle de mon WES à la requête Data.cgx :
<tic1>
<OPTARIF>Pas dispo.</OPTARIF>
<ISOUSC>0</ISOUSC>
<PTEC>NON Dispo !</PTEC>
<PAP>0</PAP>
<IINST>0</IINST>
<IINST1>0</IINST1>
<IINST2>0</IINST2>
<IINST3>0</IINST3>
<TENSION1>0</TENSION1>
<TENSION2>0</TENSION2>
<TENSION3>0</TENSION3>
<IMAX>0</IMAX>
<IMAX1>0</IMAX1>
<IMAX2>0</IMAX2>
<IMAX3>0</IMAX3>
<PEJP>0</PEJP>
<DEMAIN/>                                      // ici la réponse n’a pas un format correct CGX standard
<BASE>000000000</BASE>

Cdt