@ben33880 avec le diag, c'était assez simple

La beta10 devrait corriger.

@ben33880 oups ... Merci

@Laurent6012

RTC Watch dog reset digital core

signale qu'il y a eu un reset anormal.
Cela peut venir d'un wifi pourri ... Il faudrait vérifier votre paramétrage wifi et valider qu'il soit compatible avec les esp32.

@EliasMM j'ai publié une V12.5beta9.
Règle t'elle le soucis ?

@EliasMM je vais regarder côté winky. De mémoire j'avais désactiver l'interface série et je l'ai réactivée il y a peu. Si nécessaire je publierai une nouvelle version.

@kolia une autre explication pourrait être que la gpio36 ait été cramée lors des différents tests. Avez vous essayé avec une autre Olimex POE ?

@kolia donc au final tout est opérationnel ?

@rvx merci

@rvx bonsoir,
Si l' ESP est stressé, il peut ne pas envoyer certains messages MQTT qui seront perdus.
Il faut veiller a ce que la charge CPU reste en dessous de 70% en moyenne.

Effectivement, la documentation est sur le GitHub
https://github.com/NicolasBernaerts/tasmota/tree/master/teleinfo
Tous les paramètres ne sont pas expliqués dans le détail ... mais presque.
Si quelque chose n'est pas clair, je compléterai la page.

@kolia relier 2 gpio entre elles me semble très dangereux ... Si les 2 sont configurées en sortie et à des niveaux différents ... l'une des 2 va griller.

@rvx Bonjour,
Tout d'abord, vous avez dans doute coché trop de cases. Contentez vous de consommation et production au départ.
Évitez de publier à chaque message car c'est très stressant pour l' esp. Choisissez plutôt toutes les +- 200 w par exemple.
Mais le problème semble être autre car vous n'avez aucune réception.
Qu' affiche la page Messages ?
Si elle est vide, vous ne recevez rien ...
Essayez alors le mode standard.

@kolia le schéma de olimex poe annonce une diode 1n5819s4 sur gpio36. C'est peut être la source du problème dans le cadre d'une réception série à 9600 bps.

@EliasMM une led bleu qui clignote et des données qui arrivent est un très bon signe ...
Si le winky est auto alimenté, il est normal qu'il mette du temps à se réveiller, le temps de recharger la super capa.

@Laurent6012 quelle version de firmware utilisez vous ?
Vous parlez de skip, vous utilisez le topic TIC ?

@FH35
Pour suivre la conso quotidienne, il ne faut pas choisir Conso Aujourd'hui car la valeur revient à 0 à minuit. Il faut suivre la valeur Total Conso qui ne fait qu'augmenter. HA gèrera la bascule à minuit.

Hello @Kisifrot

La barre horizontale sert à definir l'intensité de la LED du DenkyD4.

Il est possible de publier toutes les 10sec. Il faut le paramétrer dans le menu Configuration / Journal / Période de télémétrie. Mais le plus efficace est de choisir +/- 100W par exemple dans la configuration teleinfo.

Pour la moyenne CPU, à 31%, aucun soucis. Pas besoin d'ajustement.
Sinon, la commande webload 1 permet de le visualiser en temps réel.

La commande full permet de publier les étiquettes brutes. skip permet de définir le nombre de messages à ignorer entre 2 publications. La plupart du temps ces commandes ne sont pas nécessaire.

@Gilles15001 Sur mon GitHub j'ai publié un firmware qui devrait répondre a votre besoin. Il s'appelle offload et gère le délestage. Il s'abonne au linky et fait du délestage dès qu'une puissance max est atteinte. Il gère des priorités pour avoir plusieurs délestage actifs.

@Gilles15001 bonsoir,
Attention, vous devez prendre en compte deux éléments :

• Il faut moyenner la valeur sinon vous risquez de switcher à chaque message en cas de valeur aux limites
• vous devez intégrer que lors du switch du relai la puissance linky va être modifié de la valeur de la charge et que c'est normal. Il faut prendre en compte cette différence.

@frkb Prenez 3 denkyD4 ou équivalent, qui publierons chacun sur un topic MQTT différent. Vous agrégez ensuite cela sur une base de donnée unique et le tour est joué. Si vous utilisez une base influxdb, le firmware du denky permet de l'alimenter directement !