Posts made by Géryko

Bonjour Charles,

1,4 2,5 et 5 sont des exemples ( d'ailleurs erronés.)

En fait, il faut regarder la courbe du document Enedis-NOI-CPT_54E-1.pdf courbes page 29

Pour 1,3 le délai est de l'ordre de 300 sec ? c'est la limite.
Je rectifie les valeurs
avec 1,4 fois la puissance souscrite, la coupure a lieu en 220 s,
avec 2.5 fois la puissance souscrite, la coupure a lieu en exactement 40 secondes,
avec 5 fois la puissance souscrite, la coupure a lieu en 10 secondes. (arrondi)
et avec 10 fois la puissance souscrite, la coupure a lieu en 3 secondes.

A+

Bonjour à tous,
Autre réponse :
Voir le document Enedis-NOI-CPT_54E-1.pdf courbes page 29 ( version 3 du 01/06/2018)
en résumé :
avec 1,4 fois la puissance souscrite, la coupure a lieu en 120 s,
avec 2.5 fois la puissance souscrite, la coupure a lieu en exactement 40 secondes,
avec 5 fois la puissance souscrite, la coupure a lieu en 9.5 secondes.
et avec 10 fois la puissance souscrite, la coupure a lieu en 0,2 seconde.

PS : J'ai trouvé une explication.
byte 49d = 31h = chiffre 1 = phase 1.
Donc problème de conversion.

Bonsoir à tous,

Compléments pour mon interrogation.
J'ai créé une trame fictive pour tester ADPS avec IINST = 31A.
La trame reçue :
ADCO 031762023755 | OPTARIF BASE | ISOUSC 30 | BASE 11176 | PTEC TH..
IMAX 90 | PAPP 480 | HHPHC A | MOTDETAT 000000 | IINST 31
Les trames suivantes avec en plus, ADPS 31

La callback "void ADPSCallback(uint8_t phase)" renvoie : {"ADPS":49}
Je m'attendais à avoir : n = numero de la phase 1 à 3 et non 49 !
Que se passe-t-il ?

Bonjour à tous,

Je prends ce sujet au vol, quelque chose m'interpelle.
Ce n'est pas en mesurant des résistances qu'il faut résoudre ce problème.
Personnellement, j'ai eu des cas assez bizarres sur l'adaptation compteur/capteur de TIC.
Un montage personnel qui fonctionne très bien à mon domicile avec 50m de câble
ne fonctionne pas chez un ami en utilisant ce même câble !

Si le montage comporte un potentiomètre, c'est bien pour effectuer un réglage ?
Comment réglez-vous ce potentiomètre ? (notice - mode d'emploi ?)
Il faudrait utiliser un oscillo pour voir le signal en sortie de l'opto coupleur.
Sans oscillo, régler en observant la lecture des trames (ou une DEL en sortie du transistor de réception ?)
Les schémas de ces 2 modules se trouvent-t-ils sur le site de Charles H.?

Bonsoir à tous,

Je m'amuse bien avec la librairie LibTeleinfo ! Super et bravo.

Je m'interroge sur les avertissements de dépassement, mode historique, ADPSCallback

• étiquette ADPS en monophasé.
• étiquettes ADIR1 à ADIR3 en triphasé (trames courtes).
  Dois-je utiliser cette callback pour délester ?
  Avantages : je n'ai qu'à attendre l'appel, et que ce soit en monophasé ou en triphasé.

Si j'ai bien compris, elle n'est pas indispensable ? (puisqu'il suffit de comparer les IINSTx avec ISOUSC)
Inconvénient : je dois surveiller ADPS et les ADIRX.
Elle pourrait être indispensable si la callback apportait quelque chose que je ne connais pas.
(exemple : élimination des pointes de courant très brèves. Intégration)
(questions : Faut-il prendre une marge de sécurité ?
de quel délai dispose-t-on pour délester ? ce n'est pas très clair pour moi.)
Ai-je bien compris ?
Merci pour vos réponses, même très brèves.

Bonjour à tous,

Je pense avoir trouvé la solution !
La fonction void IRAM_ATTR fonction_ISR() { ... } doit se trouver en amont du setup en non après.

Qu'on se le dise.
ça peut paraitre évident mais ... il faut le savoir et personne n'en parle.
A+

Bonjour à tous,
J'utilise la bibliothèque LibTeleinfo.h et comme j'ai de l'espace disponible, je voudrais ajouter
une fonction gadget en utilisant une interruption extérieure sur pin 15. (sur ESP32)
Je voudrais éviter de modifier le xx.h et le xx.CPP. Comment se sortir de là ?
Bien évidemment je ne suis pas programmeur pro.

Voici ce que j'ai fait (raccourci) :
boolean drapeau = 0;
void setup() {
pinMode(15, INPUT_PULLUP); //Configuration du pin en entrée pullup
attachInterrupt(15, fonction_ISR, FALLING);
}

void IRAM_ATTR fonction_ISR() {
drapeau = 1; // Code de la fonction (traitement par la suite)
}

Me donne :
error: 'fonction_ISR' was not declared in this scope

Merci d'avance à qui pourrait m'aider.

Bonjour Charles, et très heureux de ta réponse rapide.

<quote>extraire ou ? dans quoi dans le code de l'ESP32 local ? Tu veux les envoyer ailleurs, MQTT/HTTP pour les traiter ? ... </quote>
Je m'explique :
Je lis et j'affiche les trames, j'imagine qu'elles sont en mémoire dans mon ESP32.
Je sais utiliser les callback (en boucle while)
Je ne sais pas aller rechercher, lorsque j'en ai besoin, une information bien précise. (ex . "IINST")

En voyant le code sur ta réponse, je pense que tu as répondu à ma question.
C'est tellement simple !
il ne me reste plus qu'à tester. (m'amuser mais cela pourra surement servir à d'autres ?)

Concernant ma question 2 : mea culpa. Je n'avais pas vu ce dossier trames.
C'est tout ce qu'il me fallait.

Un peu de temps pour décanter, j'ai bien progressé et je t'en remercie.
(Je ne suis pas programmeur mais je me débrouille)

J'ai d'autres questions plus fines à voir mais rien d'urgent.
(je n'ai pas encore fait de recherches et je ne voudrais pas "réinventer la roue")
Règles du délestage : intensités, durées, ...
Règles du "re lestage" : intensités, durées, ...
J'ai découvert Tasmota mais aucune expérience à ce jour.

Bonjour à tous,
Comment extraire des données avec la librairie LibTeleinfo pour esp32 de Charles-Henri Hallard

J'utilise et je teste la librairie citée dans le titre du sujet. ( V2.01 2020-08-11 )
Tout va très bien pour afficher les données mais je ne sais pas extraire des données reçues et vérifiées, pour les traiter ensuite.
Exemple simple : je veux surveiller l'intensité pour délester si nécessaire.
Comment extraire l'intensité qui a été enregistrée je suppose ? (ainsi que d'autres données)
Ne sachant pas le faire pour l'instant, j'ai créé "mon" tableau 2D et j'y place toutes les étiquettes et datas mais cela ne me semble pas logique.
Ainsi, je peux choisir et utiliser n'importe quelle information vérifiée à tout moment.

Question 1 : Y a t-il une solution "plus propre" ? Comment faire ? un/des exemples svp ?

Nota :
Je ne dispose que de trames "Historiques" sur mon compteur Linky monophasé, pour des tests réels.
Je sais également me transmettre des trames fictives directement sans passer par le port série, ce qui est bien pratique pour réaliser des tests.
Je voudrais bien tester des trames "Standard" mais où les trouver ?
Je ne sais quasiment pas lire l'anglais.
Je suis retraité, presque octogénaire, pas de projet bien précis

Question 2 : Quelqu'un pourrait-il me remettre une trame complète STANDARD et réelle ? (en MP ou fichier joint éventuellement)
exemple pour historique
<STX>
ADCO 031762023755 @
..... ...... .....
MOTDETAT 000000 B
<ETX>
Merci d'avance à quelqu'un qui pourrait m'aider.

Bonjour,
Autre possibilité, mettre :
(strlen(me->value) > 9) ? SERIAL_DEBUG.print(me->value) : SERIAL_DEBUG.print(atoi(me->value));

Mais transformer String en nombre ne sert quasiment à rien pour l'afficher ?
(hormis effacer le zéros non significatifs et revérifier qu'il ne s'agit bien que de chiffres)
Une double erreur peut provoquer un checksum OK.

Bonsoir à tous,

J'ai trouvé et résolu le problème.

Dans le fichier .ino il y a : Serial.print(atol(me->value));
Il faut : Serial.print(me->value);
Car "atol" convertit en long alors que (me->value) = 12 chiffres.
Merci

Bonsoir à tous,

Le viens de faire des tests complémentaires.

Si ADCO est < à 2147483647 c'est OK ( 7fffffff (hex) 2^31 )
Si ADCO est > à 2147483647 c'est mauvais.

Mais je ne comprends pas comment cette valeur est déclarée ?
Il n'y a que du char dans la librairie LibTeleinfo.h et LibTeleinfo.cpp !

Quelqu'un peut-il m'aider à résoudre ce petit problème ?
Merci

Bonjour à tous,

Retour d'expérience.
J'étais surpris de voir que l'auteur du sujet dans 'Démystifier le décodage Téléinformation et l’optocoupleur SFH620"
http://hallard.me/demystifier-la-teleinfo/
attachait beaucoup d'importance à R1 et R2, très peu à R3. L'article est toutefois très bien et je le félicite.

Je considère que c'est surtout R1 et R3 qui sont les valeurs critiques de ce montage. R2 ne l'est pas.
Je viens de faire quelques mesures et tests pour évaluer la plage de fonctionnement du montage en faisant varier les tensions.
J'ai la plage la plus large pour R1 = 2700 Ohms et R3 = 6900 Ohms (R2 = 10 K fixe) transistor BS170 opto 814.
Les valeurs préconisées sont donc convenables mais ne pas s'en écarter dans le mauvais sens.
Soient R1 = 2700 et R3 = 8200 en valeurs classiques normalisées.

Nota 1 : grosse surprise dans l'utilisation de transistors BS170. Les 3 bornes étaient inversées !
J'ai vérifié avec un montage précédent que j'avais réalisé en 2017. C'est différent.
J'ai vérifié les datasheets.
Mes transistors sont marqués BS170 et il faut les connecter comme les 2N7000 !
Qu'on se le dise.

Nota 2 :
[On peut voir sur le site de Charles que le potentiel de l'entrée opto est flottante sur l'oscillo.
Il aurait fallu la référencer au 0V (GND de l'oscillo) c'est à dire mettre une patte à GND]

A+

Bonjour,

@Nicolas
Je ne connais pas Remora ni jeedon mais je suppose que tu programmes nodemcu (esp8266) avec l'IDE Arduino ?

• Nom de la bibliothèque ?
• Normalement, le changement de point d'accès n'a rien a voir avec la TIC ?
  -Tu n'avais pas le code source pour on installation ?

Bonjour à tous,

J'ai tenté d'approfondir la question malgré la valeur de ADECO qui est toujours fausse.

1. Avec ma trame de test (captée à mon domicile en tarif BASE) j'obtiens ceci au démarrage :

TIC RX=GPIO33 Mode:Historique

ADCO 031762023755 => @ // checksum recalculé = OK ainsi que les autres.

{"_UPTIME":0, "ADCO":2147483647, "OPTARIF":"BASE", "ISOUSC":30, "BASE":15572906, "PTEC":"TH..", "IINST":2, "IMAX":90, "PAPP":480, "HHPHC":"A", "MOTDETAT":0}
{"_UPTIME":60, "ADCO":2147483647, "OPTARIF":"BASE", "ISOUSC":30, "BASE":15572906, "PTEC":"TH..", "IINST":2, "IMAX":90, "PAPP":480, "HHPHC":"A", "MOTDETAT":0}

2. Avec la trame de test (fournie par Charles en tarif HC.. , voir mon 1er post) j'obtiens ceci au démarrage :

TIC RX=GPIO33 Mode:Historique

ADCO 031428067147 => B // checksum recalculé = OK ainsi que les autres.

{"_UPTIME":60, "MOTDETAT":0}
{"_UPTIME":120, "MOTDETAT":0}
{"_UPTIME":180, "MOTDETAT":0}

Question : Pourquoi je n'ai pas l'affichage de la trame complète ? Est-ce normal ?
Exactement dans les mêmes conditions, il n'y a que la trame de test qui change !
On peut voir qu'il n'y a pas de " {"_UPTIME":0, etc ...} " et impossible de l'afficher alors qu'avec ma trame, je peux l'afficher à tout moment.

Merci pour vos retours.

Bonjour à tous

Actuellement j'ai un abonnement EDF de base, monophasé, TIC historique.

J'ai donc les trames de ce type : (LibTeleinfo V1.01 2021-04-18 de Charles-Henri Hallard)
stx
ADCO 031762023755 @
OPTARIF BASE 0
ISOUSC 30 9
BASE 000076645 '
PTEC TH.. $
IINST 012 Z
IMAX 090 H
PAPP 02800 +
HHPHC A ,
MOTDETAT 000000 B
etx
Je souhaiterais tester des trames réelles avec tarif HP-HC et aussi pour un compteur triphasé.

Question :
Quelqu'un pourrait-il me fournir une trame réelle, historique, mono, avec HP-HC ? (comme ci dessus)
Quelqu'un pourrait-il me fournir une trame réelle, historique, triphasé, (avec HP-HC ou sans, voire les 2) ?
Si nécessaire, masquer ADCO avec des X. je recalculerai le checksum.

Si j'ai bien compris, la bibliothèque gère tous les cas et s'adapte ?
Mais "Attacher les callback dont nous avons besoin" doit-il changer pour le triphasé ?
En clair, pour un compteur triphasé, faut-il modifier le setup ?

Merci.
.........................................................................................
PS : en cherchant sur le site j'ai trouvé ça pour un compteur HP-HC semble t-il ? (de charles)
stx
ADCO 031428067147 B
OPTARIF HC.. <
ISOUSC 15 <
HCHC 000246575 #
HCHP 000000000 S
PTEC HC.. S
IINST 001 X
IMAX 001 @
PAPP 00150 ' // apostrophe ?
HHPHC A , // virgule ?
MOTDETAT 000000 B
etx

Bonjour Nicolas Bernaerts,
et merci pour ta réponse.

Mais comme je l'ai écrit, c'est un problème de la bibliothèque LibTeleinfo que je ne sais pas traiter.
Pour l'instant je n'ai rien programmé. L'anomalie est présente avec les exemples fournis.
je ne suis pas assez "performant". en programmation.

Je vais quand même y jeter un oeil sur les déclarations mais ???
En clair, que faudrait-il modifier ?

PS : à priori, toutes les données sont des "char".

Bonjour à tous,

@ Barbu Dor,

Je crois que tu as tout compris.
En 2021, j'avais essayé d'utiliser l'alimentation fournie par le compteur (pour le fun) mais je me suis vite rendu compte du manque de puissance disponible.

La solution que j'avais envisagée est bien celle que tu proposes mais je ne l'ai jamais testée car je n'ai pas de problème pour alimenter.

• Un ESP en utilisant le mode Deepsleep pour ne faire qu'une mesure toute les 1 minutes (ne consomme que des uA en veille)
• Des super cap pour accumuler de l'énergie entre les mesures.
• je pense pas que les diodes Schottky changeront quelque chose (insignifiant)

Bonjour,

Remarques :

1. Un indice : 2147483647 (dec) = 7fffffff (hex) "Comme c'est bizarre !"
   Je ne suis pas assez connaisseur pour trouver la cause du problème.

2. Sans rapport avec le problème principal.
   Lorsque je créer un faux checksum sur une des étiquettes, l'affichage de cette étiquette ne se fait pas OK, mais je n'ai aucun signalement !
   Comment faire pour afficher les problèmes sur le moniteur ?
   genre ligne 901 du .cpp : TI_Debugf(PSTR("LibTeleinfo::checkLine Err checksum 0x%02X != 0x%02X"), calc_checksum, checksum);

Merci à vous.