@Gilles15001 Nous avons testé avec succès la connection d'un denky D4 à un ace6000. Il faut un adaptateur rs232 -TTL. Connecter la sortie du compteur sur le Tx Rs232. Connecter la sortie TTL sur une GPIO du connecteur I2C. Il reste alors a modifier la config du denky pour migrer TeleinfoRx sur la GPIO.
Je pense décrire le schéma sur ma page GitHub d'ici quelques jours.

Nous venons de tester positivement l'interface entre un denky D4 et un compteur ace6000.
Il faut un simple adaptateur rs232 tel que décrit par @Charles plus haut et connecter la sortie TTL de l'adaptateur sur l'une des gpio du connecteur I2C du denky. Après reconfiguration du menu module pour migrer TeleinfoRx sur cette GPIO, tout fonctionne nickel avec la dernière version du firmware.

@kimsti de mémoire j'ai fait un factory reset du denky directement depuis le port USB

@kimsti Logiquement pas besoin d'adaptateur USB série. Un simple câble USB-USB (avec data) devrait faire le job.

@admin je dirai même plus : beau, bien conçu et innovant

@raoul l'exploitation des relais virtuels peut être désactivée très simplement via configuration / Teleinfo. Il faut décocher l'utilisation des relais.

@EliasMM Je confirme que le winky est un très très bon choix

@raoul Good shot !
Effectivement je n'avais pas porté l'appel de TeleinfoDriverEvery250ms dans le refactoring. Je viens de publier une version esp8266 4M intégrant la correction.
Concernant HASS, c'est logique car la déclaration n'est faite qu'une seule fois au boot en mode persistant. Ce sont ensuite les étiquettes "Consommation & Production" qui sont exploitées par HASS.
Le refactoring étant en cours, vous êtes en fait un beta testeur

@raoul Un esp8266 ne peut pas tenir la charge de publication à chaque trame en mode standard (c'est quasiment toutes les secondes). Decochez toutes les options de publication et sélectionnez "à chaque télémétrie" en sélectionnant une période de télémétrie supérieure à 10s. Vous devriez retrouver un esp réactif.

Même pour un esp32, la publication à chaque trame est très stressante. Je le précise et le déconseille fortement sur ma page github.

De mémoire, le build officiel impose une publication toutes les 10 s maximum ...

@raoul C'est très etonnant car j'ai juste fait un refactoring du code pour éviter les modules multiples. Coté performances, cela devrait être totalement neutre.

Voici un ping réalisé ce matin sur un module esp8266 16M avec une alimentation Triphasé standard. Le ping répond plutôt très bien malgré un wifi moyen.
Il doit sans doute y avoir un autre problème.

Vous avez bien activé uniquement l'émission tous les +/- xxx W ?

@raoul Mon fork demande beaucoup plus au CPU que la version d'origine. En effet, toutes les fonctions et intégrations sont demandeuses en particulier en terme réseau. C'est d'autant plus le cas si la réception wifi n'est pas nickel.
L'esp8266 étant un mono coeur, la gestion réseau et la réception teleinfo sont partagées sur le même coeur. Vous êtes clairement aux limites des possibilités du CPU. Il est normal qu'une sollicitation réseau externe soit dépriorisée. Essayez un esp32 et vous verrez que tout devient fluide.

@raoul Comment avez vous déterminé qu'il y a des pertes de paquets ?
(sur un D1 mini Pro 16 Mb je n'ai aucune erreur de réception en mode standard)
Si l'interface Web de tasmota se met à jour sans erreur cela signifie que la réception est stable. Le problème est sans doute ailleurs.
Il est à noter que l'intégration Home Assistant de mon fork n'est pas basée sur l'auto-discovery Tasmota mais sur un auto-discovery MQTT natif. Il faut donc rechercher le device dans les devices MQTT. Vous aurez beaucoup plus de données publiées que les données standard de Tasmota.

@raoul J'ai uploadé une version esp8266 4M basée sur Tasmota 15 qui intègre le correctif.
Pourriez-vous tester pour confirmer que c'est réglé ?

@raoul Excellente nouvelle !
En allant voir le code de @Charles, il a effectivement détecté un problème en fonction de la GPIO utilisée sur l'esp8266. Je vais m'aligner sur son code pour gérer les différentes implémentations.
Merci pour le retour.

@raoul Cela ressemble à une vitesse mal configurée.
Avez vous fait un reset complet de la configuration lors du flash de mon fork ?
Est-ce que la vitesse est bien configurée à Mode Standard dans Configuration / Teleinfo ?

@Eric44 la courbe de conso ne passe jamais en négatif. Si vous reinjectez du courant sur le réseau Enedis, la courbe de production apparaitra en jaune. Mais il faut que le contrat le permette pour que le linky publie la production.

@Eric44 je ne suis pas très familier de berry.
Mais je pense que
tasmota.add_rule("TIC", rule_tic)
attend la clé TIC mais uniquement dans le topic SENSOR.
Est ce que la donnée cherchée est disponible sous SENSOR ?
Sinon, pour récupérer les données publiées sous le topic TIC, une solution serait mqtt_subscribe. Vous pourrez alors parser le JSON récupéré.

@Geoffrey est ce que ce ne serait pas la source du problème ?

https://github.com/serialport/node-serialport/issues/1747

@Eric44 En monophasé et en triphasé les étiquettes teleinfo ne sont pas les mêmes. C'est sans doute pour cela que le soft ne fonctionne plus directement et qu'il nécessite une adaptation.
Concernant la base de donnée, vous avez à disposition un connecteur InfluxDb qui est une base de donnée temporelle très utilisée.

@Gilles15001 les erreurs sont liées au fait que le serveur MQTT n'est pas configuré.
La vitesse est à 1200 bauds. Il faudrait tester le mode standard pour voir si c'est mieux