(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/1J23dICyALJ6dYDteBXl9d-gds2DKD38U/view?usp=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/1J23dICyALJ6dYDteBXl9d-gds2DKD38U/view?usp=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

(28-06-2026, 08:29 AM)PabloR a écrit : Bonjour à tous.

Tout d'abord bravo pour le gros travail réalisé. C'est impressionnant. Je voudrais vous expliquer mon cas.

J'ai une installation en triphasé et une passerelle en version 5528. Avec les dernières versions du routeur j'arrive à obtenir le token et je vois aussi les mêmes messages d'erreur de la passerelle que d'autres membres. J'observe de valeurs de consommation mais aucune valeur d'injection ce qui fait que le routage ne démarre jamais.

J'ai testé les versions 23, 24 et la version de tsabran mais toujours pas d'injection. C'est étrange car sur la page de données brutes je vois l'injection et les mesures correspondent à ce qui est affiché par l'application d'Enphase mais sur la page d'accueil les valeurs sont à zero et dans les graphes seulement il y a de l’énergie soutirée.

Dans la page de données brutes, la puissance consommée correspond à la somme de la puissance réseau public et puissance produite alors que je pense que avant cette valeur était la différence.

Je suis preneur de vos suggestions. Je vais redémarrer la passerelle pour voir si ça change quelque chose car c'est seulement ce qui me reste à faire.

(28-06-2026, 08:47 AM)Alain_C38 a écrit : Première idée qui ùe vient à l'idée (j'ai eu la même chose ) : Tes actions sont t-elles bien actives ?
Dans mon cas, je les avaient désactivées le temps de trouver cette nouvelle version, et oublié de les réactiver avec cette nouvelle version.

(28-06-2026, 09:41 AM)PabloR a écrit :

(28-06-2026, 08:47 AM)Alain_C38 a écrit : Première idée qui ùe vient à l'idée (j'ai eu la même chose ) : Tes actions sont t-elles bien actives ?
Dans mon cas, je les avaient désactivées le temps de trouver cette nouvelle version, et oublié de les réactiver avec cette nouvelle version.

Maintenant je pilote le SSR avec la fonction on/off et selon l'heure du jour. Je limite aussi la puissance envoyée pour avoir de la marge pour les autres appareils mais c'est clair que ce n'est pas optimal comme avant ?. On a la chance que ça est tombé pendant ces jours où il n'y a pas un seul nuage. 

Si je met un action de routage le relais passe à zero car il détecte pas d'injecton.

@Pablor Oups,