cdlog2

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

Ok je vous suis sur le sujet. Je n’ai pas essayé l’envoie de Mail donc je ne peux que me remettre à votre expérience.

Je pense que l’on peux expliquer le pourquoi du comment. Il suffit d’interpréter quelque peu la logique de Nicolas.
On peut supposer que chaque ligne de programme est constituée d’une structure commune définie pour chaque lignes de Prg.
Dans cette structure on devrait trouver divers Flags dont pour les plus utiles pour la gestion des Actions :

Flag Status : permet de connaître l’Action en cours : noactive , isactive
Flag TypeProcess : permet de connaître le type du process de l’objet définie en action : Circle, StopOnce, TimerCount
Flag TypeObjet : permet de connaître le type d’objet mis en oeuvre dans l’action soit : SW, Rl, mail, requête etc
Flag ActDone : permet de savoir si l’action est active si True ou pas encore active = False.
Var valTimer : Valeur d’une tempo si déclaré pour valider l’action

et certainement pleins d’autres variables ou flags spécifiques.

Donc déjà on peut élaborer des scénaries : 2 états possibles concernant la comparaison sur la source : ScrCompar = False ou True

Les lignes sont scrutées de façon cycliques ligne par ligne. Pour chaque ligne on teste la comparaison sur la Source.
Si SrcCompar = False, on positionne le Status de l’action à noactive, ActDone = False et on passe à la ligne suivante.

Si ScrCompar = True, On commence par tester le Status de l’Action. si Status = noactive on sait que l’action n’est pas encore activée et que l’on est en phase d’init. Donc on initialise certains Flag, en autres on met le compteur ValTimer = 0 et on passe le Status à isactive.
Ensuite on lance la procédure défini par le TypeProcess avec le TypeObjet en argument.

C’est dans cette procédure que l’on va déterminer si l’objet est un TypeProcess Circle, StopOnce, TimerCount.

On comprend que le TypeProcess TimerCount, va lancer un décompte sur un Timer pour ensuite activer l’action suivant le type Objet et mettre ActDone = True. On reste dans cet état tans que ScrCompar = True

Le TypeProcess Circle permet de réagir en boucle >> c’est le cas de notre SW8 = ON si Source SW7 = ON > SW8 revient en auto en ON en boucle

Pour terminer arrive le TypeProcess StopOnce. C’est notre action Mail. En effet je suis certain que Nicolas fait une analyse particulière pour les Mails et les Requêtes mis en Action. C’est pourquoi, lorsque le Mail à été envoyé, ActDone passe à True et il doit y avoir une discri du genre :

Si Status = isactive et ActDone = True et si TypeProcess = StopOnce > alors on ne réagit plus.

C’est une explication comme une autre, mais je suis certain qu’il y a une gestion Spécifique pour les Actions Mails et Requêtes. en plus cela semble Logique d’envoyer 1 seul Mail relatif à un test Positif d’une Source.

Seule un ScrCompar = False sur la Source permettra de réinitialiser les Flag Actions et autoriser de relancer un Mail dès que ScrCompar = True.

Cdt

si vous faites

Si SW1 état = ON >>>> email « blablabla ALERTE »

Si SW1 état = OFF >>>> email « blablabla FIN ALERTE »

Rien n’arrêtera l’envoie de mail en rafale dans votre exemple. SW1 sera soit ON ou OFF et un mail associé sera envoyé les uns après les autres suivant  la condition de SW1.

C’est pourquoi il faut faire jouer un 2eme SW de verrouillage afin qu’un seul mail soit envoyer et bloquer les autres tentatives. Ce 2eme SW doit être monté sur le Test SW1 mais avec un léger retard par rapport au test SW1 de l’envoie du mail. Ceci pour éviter d’avoir le verrouillage d »envoie des mails en même temps que la demande d’envoie de mail. Un léger retard de 1s suffit.

Le 2éme SW de verrouillage servira comme 2éme condition de test pour l’envoie des mail via l’option « Actif suivant SW « .  Cela fonctionne comme ceci >> SI SW1 = ON >>>>  email « blablabla ALERTE » uniquement si le SWx de verrouillage = OFF,  puis 1 seconde après on positionne SWx à ON pour bloquer tout autre envoie de mail sur le test SW1 = ON, on fait l’inverse pour la fin Alerte avec SW1 = OFF.

Mon exemple donné ci-dessus fonctionne parfaitement bien.

Attention par contre il faut corriger le bug dans le Fichier PROGRAM.HTM  comme spécifié dans mon dernier POST.  Nicolas prétend que le PB n’est pas visible dans Chrome,  mais avec Firefox, IE et autres le pb est bien présent. Je pense que Nicolas va implémenter cette correction dans sa prochaine release.

Il faut ouvrir et éditer le fichier program.htm avec un éditeur de texte et enregistrer le fichier après modification. Il faut faire ensuite CTRL+F5 avec le navigateur pour effacer le cache du navigateur afin de prendre en compte la modif du HTM.

Cdt

Bonjour,

Vous pouvez effectivement gérer des alertes en utilisant des SW de cette manière par exemple pour 3 types d’alerte :

Si tempExt < 1° >>>> Sw1 = ON tant que condition vrai            // Température extérieur < 1°
Si InpFeu = ON >>>> Sw2 = ON tant que condition vrai           // Détection incendie sur Input 1
Si InpAlarm = ON >>>> Sw3 = ON tant que condition vrai       // Détection Intrusion Alarme sur input 2

Si SW1 == ON >>>> Envoie Mail « Warning ! Temp extérieur < 1°… »   >>>> actif suivant SW7 = OFF     // si aucun mail déjà envoyé
Si SW2 == ON >>>> Envoie Mail « ALERT FEU : feu détecté … »        >>>> actif suivant SW7 = OFF     // si aucun mail déjà envoyé
Si SW3 == ON >>>> Envoie Mail « ALERT Alarme : Intrusion …. »      >>>> actif suivant SW7 = OFF     // si aucun mail déjà envoyé

Si SW1 = ON >>>> SW7 = ON si condition vrai pendant tempo 10s     // Tempo à régler pour laisser le temps d’envoi de 1 ou 2 mail
Si SW2 = ON >>>> SW7 = ON si condition vrai pendant tempo 10s    // Tempo à régler pour laisser le temps d’envoi de 1 ou 2 mail
Si SW3 = ON >>>> SW7 = ON si condition vrai pendant tempo 10s    // Tempo à régler pour laisser le temps d’envoi de 1 ou 2 mail

Vous pouvez autoriser la Relance des Alertes Mail soit en Auto au bout d’une tempo longue comme ceci

Si SW7 = ON >>>> SW7 = OFF si condition vrai pendant tempo 600s    // On Relance les mails d’alertes au bout de 10mn par exemple

Ou bien Manuellement depuis votre portable si vous avez un accès au WES de l’extérieur via votre BOX, vous pouvez envoyer une requête HTTP  Wifi pour remettre SW7 à OFF pour autoriser de relancer les messages d’alerte

Cdt