@Comperta un composant hs est peut être bien la cause, je viens de l’expérimenter, sur 5 optocoupleurq, 2 seulement de ok, tout les autres éléments étant par ailleurs identiques. Bon a 0.2€ la pièce pas grave, faut juste penser à en prendre un peu plus, et monter sur une breadboard avant de sortir le fer…
Pas de question bête @jrvrcd , je suis bien sur le 16. @SebCaps Vu que dans mon ancienne ancienne maison tout était ok, je penche vraiment pour le composant HS…faut juste que je retrouve dans les cartons celui qui contient les pièces de remplacement et la breadboard
Bonjour, je vous remrcie déjà pour toutes les informations disponibles dans ce fil ! cela m’a permis d’aboutir à une solution fonctionnelle avec mon compteur Linky. Cependant et malgré une liaison parfaitement intègre j’obtenais toujours une erreur CRC sur le même TAG téléinfo !
Après un certains nombre d’essais et quelques heures d’investigation, j’ai réussi à les faire disparaitre avec deux modifications:
Dans le fichier yaml de mon ESP32 dans le bloc uart j’ai ajouté rx_buffer_size: 2048 pour augmenter la taille du buffer de réception qui est par défaut de 256 octets (865 octets pour une trame de téléinfo en mode standard),
Dans une version personnalisée du module « teleinfo » de Esphome en ajoutant un « flush » du buffer de réception dans la fonction « update() ». Cela permet de garantir que l’analyse des données reçue au moment du réveil du module soit faite sur une trame complète.
J’ai tenté une « pull request » 3855 sur le git d’Esphome
Je ne sais pas si je suis le seul à avoir expérimenté ce genre de problématique ?
Au passage j’ai tenté d’implémenter un calcul du « Cos PHI », je vous ferai part de ma méthode dans une autre réponse.
Salut
il existe plusieurs interfaces entre le compteur et l’ESP mais en general le principe est le meme
en fonction du type d’ESP ( 8266 ou 32) et du mode du compteur ( historique ou pas )
la valeur de la resistance qui est entre la masse et la grille du mosfet est souvent diminuée a 4.7k voir moins.
Bonjour
Attention ce schéma n’est pas bon . L’entrée RX doit aller sur le drain du FET.
Sur ce schéma ça ne peut pas fonctionner car l’entrée Rx est toujours au 3,3 V.
Et en ce qui concerne les erreurs de CRC j’ai ça aussi mais ce n’est finalement pas très grave car les valseurs remontées sont absolues . Donc si il en manque peu importe
En fait l’idéal serait de voir la forme du signal de sortie sur un oscilloscope .
Un truc empirique : du 3,3 V a l’entrée de l’optocoupleur ne ferme pas le drain source du FET. Une tension de 5 V fonctionne .
C’est cohérent avec les specify du Linky. Mais si ça déclenche seulement à 4,8 V c’est juste et ça doit générer des erreurs
Depuis 1 semaine j’essaie de connecter mon Linky mode Historique à HA via Esphome.
J’ai d’abord suivi le tuto de la video de GammaTroniques, en particulier le test avec un FTDI branché sur PC et je vois bien les infos envoyées par Linky sur un terminal.
Je me suis ensuite attaqué au circuit avec le D1 mini et Esphome, mais je n’arrive pas à le faire marcher.
Mon circuit proto et le schéma utilisé est celui par @jrvrcd. J’ai également essayé de remplacer la résistance de 10kOhm par une de 4.7kOhm entre grille et masse du MOSFET ainsi que de remplacer tous les composants, mais sans succès.
Mon code sur Esphome - pour un premier test, je ne demande que l’adresse du compteur :
esphome:
name: linky
platform: ESP8266
board: d1_mini
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Linky Fallback Hotspot"
password: "9XKEPAUByyp2"
web_server:
port: 80
captive_portal:
# Enable logging
logger:
baud_rate: 0 # disable logging via UART, help to avoid numerous crash with ESP_LOGD
level: VERY_VERBOSE # INFO for less log, put DEBUG to view all the linky's "étiquettes" received in the logs
esp8266_store_log_strings_in_flash: False # recommanded for ESP8266 https://esphome.io/components/sensor/custom.html
# Enable Home Assistant API
api:
ota:
# ajout du composant uart pour la communication série avec la sortie TIC du compteur
# GPIO3 = Pin Rx sur Wemos D1
uart:
id: uart_bus
# tx_pin: GPIO15
rx_pin: GPIO3
baud_rate: 1200
parity: EVEN
data_bits: 7
# déclaration des sensors numérique
# les sensors doivent être déclarés dans l'ordre de la fonction lambda
teleinfo:
id: myteleinfo
update_interval: 60s
historical_mode: true
uart_id: uart_bus
sensor:
- platform: teleinfo
tag_name: "ADCO"
name: "Adresse du compteur"
unit_of_measurement: ""
icon: mdi:eye
Enfin, le log - juste avec quelques lignes supprimées - indiquant un « state : nan » et « state_missing : YES », comme si l’info sur l’adresse du compteur n’était pas trouvé par le D1 mini :
@dosreism , de mon expérience les montages sur breadboard peuvent être hasardeux et/ou les composants eux même (cf ici.
Je te conseillerai
de mettre les logs sur le composant uart, pour voir si des trames sont reçues.
-de vérifier le montage,
vérifier/changer de composants si tu en as en plus
J’ai fini par y arriver (sur ESP32), en faisant, refaisant le montage des dizaines de fois, et pourtant à chaque fois j’étais sur que c’était le bon…
Bon ce n’est que mon XP.
Je vais alors souder les éléments sur un board proto pour être sûr des connexions. Vous êtes parti sur quelles résistances ? 1kOhm en entrée et 10kOhm x2 entre les éléments ?
Enfin, pour les logs, comment faire ce que vous proposez ?
de mettre les logs sur le composant uart, pour voir si des trames sont reçues.
Quand on passe en proto soudé, la vérif concernant le montage est encore plus important
J’ai pris les valeurs proposé par gamma tronique, quelques erreurs CRC, mais ça passe de mon côté.
Pour le log c’est Ici
Hello @Pbranly !
Je confirme, j’ai moi aussi bien les données dans Home Assistant.
Par contre, même si ça fonctionne, ça me gêne d’un point de vue intellectuel de ne pas savoir d’où vient le souci.
De ce que je lis, la probabilité pour que ça vienne de ma shield est élevée, c’est ça ?
J’utilise Wemos Teleinfo sur une S2 mini.
Oui je suis d’accord avec toi. C’est pour ça que pour bien comprendre il faudrait regarder le signal en entrée de l’optocoupleur, en sortie ,et en sortie du FET de Facon à voir quel est l’étage qui écrase le signal et génère des erreurs.
La modification des résistances est totalement empirique mais fonctionnelle
Pour que ce soit intellectuellement satisfaisant il faut un oscilloscope …. Pas évident !
pour info, j’ai réussi à trouver du temps pour me remettre à ce projet. J’ai passé du temps pour tester chaque composant et j’ai fini par trouver que les pins de mon transistor ne correspondaient pas à la spéc classique du BS170 ! Acheté sur AliExpress, c’est peut-être pas étonnant.
Une fois le branchement refait, tout marche à merveille !