(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 @rdsoft30partagé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.
27-06-2026, 03:07 PM (Modification du message : 27-06-2026, 03:29 PM par Pliz72.)
(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 @rdsoft30partagé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.
@Alex11 pour le pb d'affichage, ca pourrait etre soit un problème de hard refresh à faire vu que le code javascript a un peu changé (en effet le screenshot n'affiche pas les nouvelles lignes du tableau), soit c'est lié au bug de chargement des JS que j'ai corrigé entre-temps (lien édité hier à 23h, certaines resources JS etaient tronquées par le serveur).
En tout cas, les lignes de log sont celles attendues, il faut que je les nettoie pour les rendre plus explicites
@Pliz72 le pb d'accès a la page parametre est vraissemblablement ce bug de resource JS vide (content-length=0). C'est un pb aleatoire lié à une pénurie de mémoire silencieux au moment du Send(), et amplifié sur ma version car je gardais plus de buffer en mémoire. Je crois l'avoir corrigé avec la version compilée à 23h: le fichier ...20260626-225251.ino.bin sur le meme lien.
L'url /OTA n'est pas impactée (moins de JS), ce qui permet qd meme d'uploader une nouvelle version.
Pour rappel, cette version essaie de conserver la connexion TCP avec l'Envoy le plus longtemps possible, au lieu de la réouvrir toutes les 500ms. Inévitablement, cette connection se retrouve fermée de temps en temps et il faut la rouvrir.
-> ca logge la detection de la connection fermée et sa réouverture, qui est une chose normale lorsque c'est detecté au début de la lecture
- Envoy connection is closed. (Re)connecting...
- Connected to Envoy-S server HTTPS!
-> ca logge une erreur quand on arrive pas à obtenir tout le JSON attendu, au milieu du decoding de payload, après avoir recu un début de réponse...
- Envoy ... reading failed ... -> permettent d'identifier le type d'erreur (essentiellement timeout ou connection closed) et à quel moment dans le code ca se produit. Ces erreurs correspondent à priori aux "Envoy refused request" des précédentes version
De mon point de vue, les connection closed/reopened ne sont pas un pb, vu qu'elles sont detectées rapidement, et tant que leur fréquence reste assez faible pour ne pas trop impacter le temps de reponse moyen -> je vais probablement cacher ces logs, les metriques suffisent.
Je suis plus embêté par les erreurs de timeout... on ne les detecte qu'après avoir attendu 500ms sans réponse, donc ca retarde fortement le prochain retry ! Et je trouve suspect d'avoir ces timeouts de l'Envoy qui s'arrete d'emettre au milieu d'une réponse
Pourrais-tu mettre les sources également ?
Cela permettrait de pouvoir d'avoir également des retours de membres qui codent et de mieux maitriser ces tests.
-------------------------------------------------------------- ESP32 (v117,20 et IP fixe) + sonde température + SSR -- Cumulus/Chauffe-Eau
Source données serveur Enphase 7.
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.
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.
-------------------------------------------------------------- ESP32 (v117,20 et IP fixe) + sonde température + SSR -- Cumulus/Chauffe-Eau
Source données serveur Enphase 7.
Hier, 09:08 AM (Modification du message : Hier, 09:09 AM par cmichel.)
(Hier, 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.
Bonjour,
Moi je suis en triphasé mais en version 5169 et j'ai bien l'injection et tout fonctionne trés bien, à confirmer par d'autres qui auraient aussi une version 5528.
J'ai bien sur les mêmes messages que d'autres avec l'accès à la passerelle..
Routeur v12 / routage cumulus 1.9kW triphasé avec 2 x SSR40A H
Source : Envoy Metered en V8
PV : 3Kw triphasé, 8 panneaux LONGI 375w, 8 x IRQ7+, en autoconsommation avec CACSI
RMS Station de charge VE-RMS, version ESP32 ou ESP32 & Arduino Uno
(Hier, 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.
Hier, 10:02 AM (Modification du message : Hier, 10:25 AM par Alain_C38.)
(Hier, 09:41 AM)PabloR a écrit :
(Hier, 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.
On ne se comprends peut-être pas. Si tu es en fonctionnement On/Off, il n'y a pas de routage possible.
Il faut que tu sois en Demi-sinus, Multi-sinus, Train de sinus ou PWM pour que le routage se fasse (et avoir sauvegarder les config pour que cela soit pris en compte). @Pablor Oups, je n'avais pas vu ta dernière phrase. Pas de solution. Ce que je sais c'est que plusieurs personnes en tri on reporté que le routage marchait et il me semble dans ta config (version Envoy) Une autre idée : ton cablage ESP n'a pas été modifié ? Une erreur est vite arrivée
-------------------------------------------------------------- ESP32 (v117,20 et IP fixe) + sonde température + SSR -- Cumulus/Chauffe-Eau
Source données serveur Enphase 7.
) : Tes actions sont t-elles bien actives ?
Une autre idée : ton cablage ESP n'a pas été modifié ? Une erreur est vite arrivée