Go Down

Topic: Decodeur TIC Linky (Read 18195 times) previous topic - next topic

MicroQuettas

Bonsoir Jeff,

Je vais essayer de répondre à vos interrogations :

Quote
Et si je comprends bien la manip pour la configuration du tarif, c'est la même logique, il faut décommenter ce que l'on veut sans oublier de re-commenter ce que l'on ne veut pas. Exemple MONO BASE il faut décommenter les lignes 35 et 37.
Coté simulation avec cette configuration nous n'avons alors accès qu'au renvois des infos de la puissance apparente, de l'intensité instantanée et l'index selon le tableau que tu as inclut dans LinkyHistTIC.H. Si j'ai bien compris
C'est exactement cela. Le décodeur ne capture que ce pourquoi il est configuré. La raison c'est que tout a un coût en termes d'occupation mémoire et de performances et qu'il est inutile de charger la mule pour des infos qui ne changent jamais, comme l'adresse du compteur (ADCO).

Quote
La première c'est qu'il y a un délai de 2 mn si la connexion ne se fait pas.
Exact, il réessaie après un délai de quelques minutes. Même chose pour l'acquisition de l'heure.

Quote
Chrome fonctionne à merveille sur les téléphones et EDGE sur pc met un peu de temps, préférez un autre navigateur.
Sur les téléphones et tablettes j'ai aussi Chrome qui marche bien. Sur les PC, j'utilise Firefox, aussi bien sur W7 et W10 que sur Ubuntu 18. Ca marche très bien. Je n'ai pas essayé Edge.
Si vous avez des points particuliers, signalez les, c'est comme cela que l'on améliore un projet.

Quote
De là vient une question, est ce que ça doit fonctionner avec ces anciens compteurs, à priori oui au regard de la doc Enedis.
En principe oui car la TIC "historique" envoyée par les Linky est la même que la TIC des anciens compteurs électroniques.
Vous pouvez utiliser le décodeur pour voir tout ce qu'il "sort" d'un compteur. Pour cela :

  • décommentez la ligne 31 du LinkyHistTIC.h,
  • commentez la ligne 32 du même, comme cela
    Quote
    /********************** Configuration switches ************************/
    #define LINKYDEBUG true     /* Verbose debugging mode */
    //#define LKYSIMINPUT true    /* Simulated Linky input on Serial */
  • raccordez votre démodulateur comme suit : GND sur GND, VCC (résistance de tirage - "pullup") sur +5V, signal sur la pin 10
  • réglez le terminal série de l'IDE sur 9600,
  • tout ce qui sort du compteur sera affiché, mais seules les valeurs pour lesquelles le décodeur est configuré seront capturées


Quote
commencer à travailler sur le délesteur.
Avec le décodeur publié la partie Arduino ne devrait pas être trop compliquée. C'est la partie secteur qu'il faut soigner car il y a de la tension (400V entre phases si vous êtes en tri) et de la puissance. Cela ne supporte pas l'à-peu-près. il faut des composants (relais) de qualité et respecter les règles de l'art en matière de câblage et d'isolation.
Vous pouvez sans problème faire la mise au point en simulant des trames et en allumant des LEDs avant de commander les relais.
Publiez votre ébauche, je suis sûr que vous recevrez de l'aide sur ce site.

Je termine avec un mot sur la publication. C'est pour moi une façon d'essayer de rendre tout ce que j'ai reçu des publications sur ce site et sur d'autres. Dans le serveur, il y a des parties que je n'aurais pas su faire sans les publications : la gestion du temps Unix, le client NTP, les transmissions AJAX (merci J-M-L) pour ne citer que les principales.
Donc, quand vous aurez un délesteur qui marche, rendez ce que l'on vous a apporté en publiant votre projet.

Bonne soirée, bon WE et surtout bonne bidouille,

Fred de MicroQuettas





peperounez

#106
Dec 21, 2019, 12:11 pm Last Edit: Dec 28, 2019, 10:47 am by peperounez
Bonjour Fred,

Merci pour ton retour et désolé pour ce temps mis à répondre, 8h d'informatique font que je n'ai pas trop envie de bidouiller sur du code. Dommage car je pense que les expériences partagées apportent à tous et qu'on est souvent en attente d'une réponse sur nos propre post ou sur celui des autres face aux questions posées.

Allez j'attaque sur le pourquoi du comment des difficultés que je rencontre sur la mise ne marche de ton décodeur. C'est parti!!!

Je pense que le problème que je rencontre sur le fonctionnement de mon montage vient du fait que j'utilise un optocoupleur (VO2630) particulier, il inverse les états, les 0 deviennent des 1 et vice et versa. Je m'en doutais un peu et j'ai fait ce test:
    -       transmission entre deux arduinos via la liaison série (TX/RX).
                    En direct ça fonctionne (heureusement  :) )
                    Avec l'optocoupleur, aucune réponses.

La chance que j'ai, c'est que cet opto est double, il me suffirait alors de passer dans le second.

Mais ce n'est pas le seul problème, le montage figé que j'ai ne commute qu'avec une certaine tension.
Encore une fois j'ai la chance de pouvoir extraire les optos de leur socle et les monter sur une platine d'essais et faire le montage que je souhaite, notamment mettre une diode en entrée pour redresser la sinusoïde. Car en plus d'inverser le signal, il n'y a pas de diode inverse intégrée comme pour le SFH620.

En attendant j'ai testé le montage sur simulateur électronique informatique avec ton code. Je m'évite de flasher et reflasher le programme, c'est le matériel qui va me remercier  :). Le but étant de m'affranchir de l'utilisation de la fonction debug du démo.

La configuration du démo retenue : MONO 30A
1er test : envois de trames en caractères ASCII en héxadécimal à partir d'un tableau, test concluant
2ème test : envois de trames avec la fonction println, test concluant
3ème test :Envois de la trame avec les mêmes conditions que le 1er et 2ème envois mais à travers des optos de même type que ceux en ma possession et monté doublé, test concluant.

Bref ça fonctionne. Si ça intéresse je mettrais le montage en cascade de ce type d'optos inverseur dès que j'aurai fait un montage qui fonctionne.

J'ai juste remarqué une chose concernant le checksum. Je me suis appuyé sur la doc Enedis pour le calcul de celui-ci et ai remarqué que pour que mes tests fonctionnent il ne fallait pas que j'applique celui trouvé dans mon calcul mais celui que tu mets comme exemple lorsqu'on utilise le mode Debug du démo.
Je m'explique à partir de cet exemple IINST 004
    Le calcul du checksum en version Enedis donne en hexa 0x3B pour correspondance du code ASCII le caractère ";"
    Ta trame elle présente le caractère code ASCII "[" qui en Hexa est  0x5B

Ta trame, d'après mon analyse ne prendrait pas en compte le caractère "0" rencontré deux fois dans la trame dans le but d'avoir un affichage propre 4 est mieux que 004.

Je me pose alors la question, puisque le cheksum est modifié pour le mode débug, est il utile de retenir celui-ci, sachant qu'il y a un caractère de fin de trame recherché et que ce dernier ne peut être détecté que si on a détecté le caractère de début de trame, entraînant alors la capture des caractères de la trame. A moins de ne vouloir s'affranchir d'une interruption ou une mauvaise réception de la trame.

Ce qui entraîne la question du traitement des caractères inutiles comme les "0". Le traitement demandant de la ressource matériel, je suis partisan de limité cette ressource pour la dédiée à d'autres tâches. Et je me dis que le cheksum étant déjà fourni par Enedis, pourquoi se fatiguer et ne pas prendre ce qu'on nous donne pour effectuer une comparaison entre le checksum fourni et le checksum calculé. N'ayant pas approfondi le code sur ce point, je pense que c'est l'idée qui est appliquée en ce qui concerne le checksum, mais certainement aussi pour les valeurs d'intensités permettant de procéder à la mise à jour  de la donnée si celle-ci est différente de celle en mémoire.

Je te remercie des avertissements prodigués sur les règles de l'art à appliquer lorsque qu'on interface des systèmes basse et haute tension. Etant électromécanicien de métier, mais pas que, je connais bien le sujet, et tu as raison de le souligner, car il vaut mieux prévenir que guérir!!!
Je voulais aussi te remercier pour avoir éveillé ma curiosité sur ce qu'est le décodage de trames. Je n'ai avancé sur mon projet que sur cet aspect, même si le cheminement pour aboutir est déjà bien tracé, il faut le mettre en oeuvre, même si je suis persuadé que je n'en n'aurai pas besoin personnellement. Le challenge est toujours intéressant à relever, ne serait-ce que pour partager avec autrui.

Je termine en souhaitant à tous de passer de joyeuses fêtes de fin d'année.
Etant en congé, je vais pouvoir avancer sur mon projet et espère vous le présenter prochainement, mais il y a encore du travail tant coté programmation que coté montage électronique.

Cordialement,

Jeff

MicroQuettas

Bonjour Jeff,

Il y a beaucoup de choses dans ton post.
Je vais répondre d'abord sur la checksum.
  • il n'y a qu'une checksum Enedis, c'est la même partout et en particulier pour le debug (autrement cela ne servirait à rien de débugger avec une checksum différente de celle envoyée par Enedis !?),
  • pour mettre au point le décodeur, je me suis fait une moulinette pour calculer les checksums sur un tableur. Je l'ai publiée dans le post #47, bien penser à activer les macros du tableur,
  • il s'agit toujours du mode "historique", car en mode "standard" la zone couverte par la checksum et les séparateurs sont différents,
  • pour les intensités, le Linky transmet les nombres avec 3 digits (un format "%0d3"),
  • les routines atoi() et atol() utilisées dans le décodeur sont toutefois plus futées, puisqu'elles acceptent les représentations avec ou sans 0 non significatif, c-à-d que le décodeur accepte 004 = 04 = 4,
  • à condition que les checksums soient correctes dans tous les cas.

En pratique avec les checksums, cela donne :
Quote
IINST 4 ;
IINST 04 +
IINST 004 [
La suite au prochain post pour la réponse sur l'optocoupleur. Pour l'instant, je dirais juste que les optocoupleurs sont inverseurs ou non selon la façon dont on les utilise. Le tien est plutôt une bête de course par rapport à ceux que j'utilise, mais il doit être alimenté.

A+ et bonne bidouille,

MicroQuettas

peperounez

#108
Dec 24, 2019, 06:28 pm Last Edit: Dec 28, 2019, 11:06 am by peperounez
Bonjour Fred,

Merci de ton retour sur le sujet.

Je reprends tes réponses pour les points énumérés


  •   Sur la trame j'ai l'inverse de toi, entre la ligne 1 et la ligne 3 dans ton exemple, si je fais le calcul via la calculatrice en mode programmateur sur windows. Une erreur de frappe??? Pour éviter de perturber tout le monde sur le sujet j'ai retiré mon simulateur. La mise en ligne de celui-ci n'avait pour but que d'avertir et comprendre les trames, ainsi IINST(symbole espace)004(symbole espace) ne donnera pas la même checksum que IINST(symbole espace)4(symbole espace) Il faut respecter l'architecture de la trame telle qu'elle est émise par Enedis, si on veut comprendre celle-ci et pouvoir vérifier ce qu'on envois en mode simulation. Un oubli tel que le symbole espace et le simu ne répondra pas.
  • (3 et 4) Je ne retrouvais plus ta moulinette (milles excuses je n'ai pas fait l'effort de la rechercher croyant qu'elle était sur le post du serveur) , merci pour en avoir rappeler l'existence et le post où la trouver. Le but est atteint, on sait où aller chercher et surtout qu'il y a un outil qui permette de comprendre les rouages de la trame tout en vérifiant le résultat attendu. Et tant pis si on a l'impression de rabacher
  •   (5.) atoi() et atol() , je ne connais pas leur fonctionnement, je comprends mieux l'écriture de trame donnée en exemple, je n'ai pas la prétention d'être un programmeur. Le peu d'infos que j'ai glané sont que avec la fonction atoi(), il y a apparemment quelques précautions à prendre sur son utilisation, le retour n'est pas toujours celui souhaité.


Dernière info sur l'optocoupleur utilisé et suite à une recherche du signal avec un oscilloscope. J'ai réussi à obtenir ce que je souhaitais. Le problème étant la mise en cascade des deux optos. Si le premier sort bien l'inverse de l'entrée, l'attaque du second se heurtait au fait qu'il n'y avait pas assez de tension pour la commutation, ou plutôt devrais je dire de courant, car un opto c'est une led, et une led ça fonctionne en intensité. La modif de la résistance de tirage a solutionné le tout, je suis passé de 10 kOhms à 400 Ohms et le second opto s'est mis à commuter, je me retrouve bien avec le même signal de départ, en sortie du second opto.

Je viens de faire le montage avec les optos inverseurs montés en cascade et ai envoyé les trames directement à partir d'un autre Arduino. Résultat, ça fonctionne, le problème étant bien la résistance de tirage du montage qui est fait sur la platine toute prête avec mes optos.

Allez, c'est l'heure, j'ai gagné un tour de traîneau avec un vieux monsieur habillé en rouge et avec une barbe blanche. Je reviendrai donner des nouvelles.

Je te souhaite de passer un joyeux Noël et te remercie pour ton aide au travers des confirmations et explications donnée.

Cordialement,

Jeff


MicroQuettas

#109
Dec 28, 2019, 05:37 pm Last Edit: Dec 28, 2019, 05:47 pm by MicroQuettas Reason: Link to pictures added
Bonsoir Jeff,


J'espère que le vieux monsieur au traîneau a été généreux...

Comme promis, je reviens sur les optocoupleurs. Ils sont inverseurs ou non selon la manière dont on les utilise. Voici deux façons très courantes de l'utiliser (il y en a d'autres) :

Montage inverseur :



Montage non-inverseur :



Pour le vôtre, j'ai regardé sa notice. Il doit être alimenté en 5V, et je n'ai pas vu qu'il fonctionne en 3V3. Cela peut limiter son utilisation sur des platines 3V3 comme les ESP8266. Il est également très rapide... trop ? avec le risque de commuter sur les zéros de la sinusoïde du Linky ? Pour cela, il faut faire un essai, idéalement avec un oscillo sur un vrai signal Linky.

Bonne bidouille,

Fred de MicroQuettas


Go Up