Offline
@krissam44 quelques remarques :
Dans votre contrat, heure semaine correspond aux heures pleines et heures weekend aux heures creuses ?
Un taux d'erreur à 3.1% est très élevé. Ce n'est pas normal. Vos étiquettes manquantes peuvent venir de là.
Pour les totaux hier et aujourd'hui, il y avait un bug de calcul pour les contrats non référencés (ce qui est votre cas) en cas de redémarrage. Cela devrait être corrigé dans la prochaine version qui stockera les données entre les reboots.
@krissam44 Effectivement vous avez des trames beaucoup plus complètes que d'autres. Certaines contiennent ces étiquettes et d'autres non :
"SINSTS":"00563","SMAXSN":"E251007011607 01001","SMAXSN-1":"E251006171846 04006","CCASN":"E251007010000 00450","CCASN-1":"E251007003000 00498",
J'ai noté que vous avez un contrat de type weekend. Je n'ai jamais eu ce contrat sous la main. Pourriez vous m'indiquer les périodes du contrat ?
S'était-il possible d'enregistrer le flux TIC sur 5 ou 10 mn afin de me permettre de le rejouer pour tests ?
Merci
@krissam44 c'est très étonnant ... Je publie les données TIC telles quelles sans les retravailler du tout. Je droppe uniquement les étiquettes avec checksum en erreur. SINSTS apparaît dans la fenêtre "Messages" ?
Voici le schéma d'interface pour connecter le compteur PME PMI à un ESP.
Le connecteur I2C du denky peut être utilisé moyennant une modification de la configuration du module pour déclarer TinfoRx sur la bonne GPIO.
@krissam44 je pense avoir trouvé la source du problème : un mauvais copier/coller pour la mise a jour d'un flag. Je vais publier une version qui devrait corriger le problème.
@krissam44 bonjour,
Ayant réorganisé toute la politique de publication des données et n'utilisant jamais la publication des données TIC, il y a peut être eu une régression sur cette publication.Je vais regarder.
@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é ?