Salut a tous,

De mon cote j’ai mon routeur et l’enphase qui sont opérationnels depuis dimanche dernier.

J'ai un signal wifi de -47db
Au regard des différents problèmes rencontrés par certaine personnes je pense que les délais d'attente de connexion et lecture des données en provenance de la passerelle dépendent beaucoup de la qualité de la connexion wifi.
Ce n’est pas étonnant et certainement que les délais que j’ai expérimenté avec les 3 valeurs que j'ai mise dans le code ne sont pas assez grande pour fonctionner avec toutes les qualités de reception wifi......

Il faudrait peut etre rallonger certain délais pour éviter des non connexions ou mauvaises réceptions des données de la passerelle.

Est ce que ceux qui sont en filaire ont aussi des soucis avec les dernières versions?

David

Bonsoir,
J'ai fait une demande pour avoir un monitoring à 1 mn au lieu de 3
Cela aidera peut être ?

Qu'en pensez vous ??

(25-06-2026, 06:45 PM)Gillou31700 a écrit : Bonjour 

je viens de faire un nouveau test avec on routeur Nomade , dans lequel je viens de mettre mon esp 17.24 qui ne faisait un restart toutes les 3mm.
il refonctionne.

le seul changement c'est mon réseaux wifi j'ai mon wifi a -43db  a la place de -58db.

je viens de remettre mon esp dans son routeur avec une autre réseau wifi puissance -60Db. il reboot toutes les 3mm avec le message json loading faidel.

le puissance du réseau wifi a de l'incidence sur la communication de l'esp certainement du au changement de firmware de enphase


je viens de mettre mon esp nomade sur le routeur a probleme puissance wifi -60db meme souci ... reboot toutes les 3mm

Bonsoir,

Comme vous êtes en firmware Enphase 5169, qui est la dernière version stable avant les mises à jour Enphase 5289, 5422 et 5528, je vous conseille de repartir sur la dernière version du routeur validée par la communauté avec les firmwares 5167 et 5169, à savoir la version du routeur 17.21.

Il faudrait donc effectuer un test avec un seul routeur en 17.21, puis en configuration multi-routeurs en 17.21, afin de vérifier si votre installation fonctionne correctement avec votre firmware Enphase actuel  en 5169.

Tant que ce test n'est pas concluant, il est inutile d'essayer les versions plus récentes du routeur (17.22 ou 17.24).

Enfin, en configuration multi-routeurs, il est très important que tous les routeurs utilisent la même version logicielle. Il ne faut surtout pas mélanger les versions.

Bonsoir,

Enphase 5169 mono routeur 17.22 ok

Enphase 5169 mono routeur 17.23 énormément de "Envoy refused request" 

@+

Bonjour à tous.
Pour ma part mon routeur s'est remis en fonctionnement hier tout seul sans que je ne fasse rien de particulier.
Tant mieux mais sans explication.

bonjour à tous,

chez moi je suis passé en 17.23 et ca fonctionne meme avec quelques messages d'erreurs.

depuis la mise a jour j'ai enormement de redemarrage de l'ESP, vous aussi? normal?

est ce que l'on peut faire en OTA un downgrade en 17.22?

upgrade en
17.24..
la 17.23 et buggé et supprimée.

(26-06-2026, 02:37 PM)Pecheur021 a écrit : bonjour à tous,

chez moi je suis passé en 17.23 et ca fonctionne meme avec quelques messages d'erreurs.

depuis la mise a jour j'ai enormement de redemarrage de l'ESP, vous aussi? normal?

est ce que l'on peut faire en OTA un downgrade en 17.22?

Salut,
Oui en OTA tu peux faire un downgrade comme tu veux.

Par contre cest bizarre les redémarrages.......

De mon côté aucuns soucis par contre jai mis un reset de l’esp32 si il n’y a plus de communication apres 30min et pas 3 min comme par defaut....

Bonjour tout le monde !

De mon coté, j'ai testé quelques ameliorations supplémentaires, et j'arrive à un temps de lecture moyen de 150ms, et un taux d'erreur timeout de 0.75%.


C'est basé sur la version Source_EnphaseEnvoy.ino de @rdsoft30 partagée dans le post  #291

1) Authentification via SessionID cookie instead of AuthBearer.
La gateway Envoy semble etre plus rapide à valider le sessionID que the Enphase token (peut-etre parce que la validation du token enphase necessite un call au server Enphase?). Ca permet d'economiser entre 25ms et 50ms.
-> Concretement, on recupere le cookie depuis un appel avec le token. Si on a un cookie valide, on essaie de l'utiliser, et on fait un fallback sur le token si on recoit un 401.

2) Reutilisation des connections TLS avec keepalive
J'ai constaté que l'ouverture de la session TLS prenait la majorité du temps de chaque requête. Ca génère de la charge a la fois coté ESP et coté Envoy, ce qui devait contribuer à la saturation de la gateway.
Très gros gain, vu qu'on economise près d'1s par rapport aux reutilisations de connections.
Je constate un ratio de reconnections TLS de l'ordre de 1.5%. Ca implique que certaines lectures prennent 1.2sec au lieu des 150ms de moyenne.

3) Optimisation CPU/memoire du JSON retrieval/parsing
j'ai retiré les allocations memoires de String en passant sur des buffers char[] (dans JSONReadingEnphase et ValJson), essayé de distinguer les timeouts des autres erreurs au moment de l'ouverture de la connexion, de l'authentification (jusqu'au HTTP/1.1 200), et du read+parsing de la payload, pour mieux comprendre les Envoy refused connection.
(je voulais eliminer le risque d'instabilités de connexions à cause d'une charge cpu ou fragmentation memoire trop importante).
J'arrive à un temps de payload retrieval/parsing <30ms

=> Au final, ca donne un temps de lecture <150ms en moyenne (avec des pics à 1.5s dans 1.5% des cas lorsqu'il faut réouvrir une nouvelle connexion ou en cas de timeout)

J'ai pu alors augmenter la fréquence de lecture à 500ms en moyenne (en configurant une pause de 300ms au lieu de 2000ms) pour plus de réactivité.
Et plus aucun problème de données manquantes sur HomeAssistant (integration Enphase officielle, 1 point par minute).


Et un taux d'erreur de 0.75%, donc toujours de l'ordre de 1 échec par minute en moyenne avec le rafraichissement à 500ms.
Mais je n'ai pas trouvé si ca vient de nous ou de la gateway Envoy, et si on peut y faire qqchose.
Pas d'échecs contigus donc le premier retry qui suit fonctionne en général, donc l'impact me semble raisonnable.

Voici le .bin pour ceux qui veulent tester et donner des feedbacks: https://drive.google.com/file/d/1J23dICy...sp=sharing

Je partagerais le code tout a l'heure quand j'aurais le temps de cleaner un peu...

edit: j'ai corrigé un pb concernant les JS qui se chargeaient mal à cause d'un pb memoire

(26-06-2026, 05:50 PM)tsabran a écrit : Bonjour tout le monde !

De mon coté, j'ai testé quelques ameliorations supplémentaires, et j'arrive à un temps de lecture moyen de 150ms, et un taux d'erreur timeout de 0.75%.


C'est basé sur la version Source_EnphaseEnvoy.ino de @rdsoft30 partagée dans le post  #291

1) Authentification via SessionID cookie instead of AuthBearer.
La gateway Envoy semble etre plus rapide à valider le sessionID que the Enphase token (peut-etre parce que la validation du token enphase necessite un call au server Enphase?). Ca permet d'economiser entre 25ms et 50ms.
-> Concretement, on recupere le cookie depuis un appel avec le token. Si on a un cookie valide, on essaie de l'utiliser, et on fait un fallback sur le token si on recoit un 401.

2) Reutilisation des connections TLS avec keepalive
J'ai constaté que l'ouverture de la session TLS prenait la majorité du temps de chaque requête. Ca génère de la charge a la fois coté ESP et coté Envoy, ce qui devait contribuer à la saturation de la gateway.
Très gros gain, vu qu'on economise près d'1s par rapport aux reutilisations de connections.
Je constate un ratio de reconnections TLS de l'ordre de 1.5%. Ca implique que certaines lectures prennent 1.2sec au lieu des 150ms de moyenne.

3) Optimisation CPU/memoire du JSON retrieval/parsing
j'ai retiré les allocations memoires de String en passant sur des buffers char[] (dans JSONReadingEnphase et ValJson), essayé de distinguer les timeouts des autres erreurs au moment de l'ouverture de la connexion, de l'authentification (jusqu'au HTTP/1.1 200), et du read+parsing de la payload, pour mieux comprendre les Envoy refused connection.
(je voulais eliminer le risque d'instabilités de connexions à cause d'une charge cpu ou fragmentation memoire trop importante).
J'arrive à un temps de payload retrieval/parsing <30ms

=> Au final, ca donne un temps de lecture <150ms en moyenne (avec des pics à 1.5s dans 1.5% des cas lorsqu'il faut réouvrir une nouvelle connexion ou en cas de timeout)

J'ai pu alors augmenter la fréquence de lecture à 500ms en moyenne (en configurant une pause de 300ms au lieu de 2000ms) pour plus de réactivité.
Et plus aucun problème de données manquantes sur HomeAssistant (integration Enphase officielle, 1 point par minute).


Et un taux d'erreur de 0.75%, donc toujours de l'ordre de 1 échec par minute en moyenne avec le rafraichissement à 500ms.
Mais je n'ai pas trouvé si ca vient de nous ou de la gateway Envoy, et si on peut y faire qqchose.
Pas d'échecs contigus donc le premier retry qui suit fonctionne en général, donc l'impact me semble raisonnable.

Voici le .bin pour ceux qui veulent tester et donner des feedbacks: https://drive.google.com/file/d/1DWRf4eD...sp=sharing

Je partagerais le code tout a l'heure quand j'aurais le temps de cleaner un peu...

Salut tsabran,

Super boulot !!
Cest effectivement ce qu'il fallait faire pour mieux cerner les temps de connexion et optimiser tout ca.
Je suis preneur de tes améliorations quand tu diffusera le source.
Merci pour ce beau travail d'analyse.
A suivre