Plus d'accès aux données de la passerelle Enphase Envoy

[cmichel]

Salut à tous,

Je vais apporter quelques précisions sur ce que je constate. La version avec laquelle j'ai fait des tests et qui me pose des problèmes d'affichage graphique et data du tableau de la page d'accueil, est la version faite par tsabran qui a fait un super boulot pour optimiser la connexion avec Enphase et la récupérations des données. Cela produit aussi des statistiques interessantes pour comprendre ce qu'il se passe avec la connexion Enphase. Le problème n'est pas au niveau de la connexion avec Enphase, mais que cette version 17.25(tsabran) me donne des affichages erronés sur la page d'accueil. Ce n'est pas un raffraichissement avec CTRL+F5 du navigateur, c'est vraiement un problème de code.

Depuis la 17.22, André à repris le code que j'avais produit pour la connexion à l'Enphase. et depuis les datas remontent bien, mais ce code ralenti l'affichage de la page d'accueil, car il est trop consommateur de temps à mon avis. Il fait le job correctement pour lire les données Enphase et les envoyer en MQTT à un serveur comme HomeAssistant par exemple.

J'ai du coup travaillé à comprendre tout ça ce week-end. J'ai réussi à faire une nouvelle version un peu plus optimisé qui du coup ne présente pas de bugs d'affichage (data du tableau + graphique non affichés ou erronés (sans data)) avec une page Accueil beaucoup plus fluide et comme d'habituellement. Grace au super boulot de tsabran, j'ai récupéré certaine partie de son code qui optimise la récupération des données de l'Enphase. Cela produit donc une version plus saine encore pour le source code "Source_EnphaseEnvoy.ino".

Mes différents tests m'ont fait comprendre certaines choses importante que j'ai comfirmé sur 2 versions complètements différente de code.
La version de tsabran m'a permis de voir que le temps de connexion avec l'Enphase est de 1100ms environ sur ma configuration lorsque la connexion a été rompue et doit être établie (je parle du clientSecu.connect(), pas de la prise connexion complète avec récupération de la session ID et token). Lorsque la connexion est établie, il est possible d'avoir des lecture assez rapide d'environ 100ms en moyenne, mais cela fait en sorte que la connexion avec l'Enphase reste "ouverte" et c'est ça qui perturbe la page d'accueil !!!!

Le clientWifi local à la lecture de l'enphase n'est aussi pas une bonne chose pour la consommation de la mémoire RAM. Ce dernier point est aussi critique, car j'ai constaté aussi que lorsque la mémoire libre tombe en dessous d'environ 35000 octets, la page d'accueil commence à déconner et tout se coince .....

J'ai actuellement fait une version qui fonctionne très bien avec les points suivants:
- Une lecture de l'Enphase avec une ouverture et fermeture de la connexion à chaque lecture, ce qui limite à une lecture toutes les 1.2s environ, mais largement suffisant pour réguler la surproduction.
- Une lecture de l'Enphase avec le clientWifi (clientSecu) général à l'application pour établir des connexions Wifi et non pas une variable client Wifi locale à la fonction de lecture de l'Enphase.
- J'ai volontairement supprimer la fonction Telnet et toutes ses variables associées pour libérer de la consommation mémoire, ainsi que la gestion des compteurs Linky, qui consomme aussi beaucoup de mémoire. Du coup j'ai une consommation mémoire bien plus limitée que les dernières version actuelles (17.25 & 17.26) avec un mémoire libre qui se moyenne autour de 96000 et au plus bas à 55000.

Pour moi en conclusion de tout ça, il faut absolument, ouvrir et fermer la connexion du client Wifi en faisant "clientSecu.stop()" à la fin de la récupération des datas Enphase à chaque lecture et faire en sorte de maintenir une mémoire RAM disponible toujours au dessus de 40000 50000 octets pour que les pages Web n'aient pas de soucis.

Voilà si d'autres personnes ont des idées .....

Je peux aussi faire un code pour partager ces améliorations si vous n'utilisez pas Telnet et Linky.
Je ferrais aussi le test de prendre la dernière version 17.26 et mettre les améliorations nécessaires sans supprimer Telnet et Linky pour voir.

Quelle version vous intéresserait?

A+

Bonjour rdsoft30,
Il vaudrait mieux repartir de la version 17.26 puisque André à rajouter juste la partie OTA non accessible quand il y a pas d'internet, comme cela on suit toutes les dernières évolutions.
Quand tu parles de gestion Linky mais quand on est sur la source Enphase, la partie Linky n'est pas utilisé donc pas en mémoire.

[rdsoft30]

Salut à tous,

Je vais apporter quelques précisions sur ce que je constate. La version avec laquelle j'ai fait des tests et qui me pose des problèmes d'affichage graphique et data du tableau de la page d'accueil, est la version faite par tsabran qui a fait un super boulot pour optimiser la connexion avec Enphase et la récupérations des données. Cela produit aussi des statistiques interessantes pour comprendre ce qu'il se passe avec la connexion Enphase. Le problème n'est pas au niveau de la connexion avec Enphase, mais que cette version 17.25(tsabran) me donne des affichages erronés sur la page d'accueil. Ce n'est pas un raffraichissement avec CTRL+F5 du navigateur, c'est vraiement un problème de code.

Depuis la 17.22, André à repris le code que j'avais produit pour la connexion à l'Enphase. et depuis les datas remontent bien, mais ce code ralenti l'affichage de la page d'accueil, car il est trop consommateur de temps à mon avis. Il fait le job correctement pour lire les données Enphase et les envoyer en MQTT à un serveur comme HomeAssistant par exemple.

J'ai du coup travaillé à comprendre tout ça ce week-end. J'ai réussi à faire une nouvelle version un peu plus optimisé qui du coup ne présente pas de bugs d'affichage (data du tableau + graphique non affichés ou erronés (sans data)) avec une page Accueil beaucoup plus fluide et comme d'habituellement. Grace au super boulot de tsabran, j'ai récupéré certaine partie de son code qui optimise la récupération des données de l'Enphase. Cela produit donc une version plus saine encore pour le source code "Source_EnphaseEnvoy.ino".

Mes différents tests m'ont fait comprendre certaines choses importante que j'ai comfirmé sur 2 versions complètements différente de code.
La version de tsabran m'a permis de voir que le temps de connexion avec l'Enphase est de 1100ms environ sur ma configuration lorsque la connexion a été rompue et doit être établie (je parle du clientSecu.connect(), pas de la prise connexion complète avec récupération de la session ID et token). Lorsque la connexion est établie, il est possible d'avoir des lecture assez rapide d'environ 100ms en moyenne, mais cela fait en sorte que la connexion avec l'Enphase reste "ouverte" et c'est ça qui perturbe la page d'accueil !!!!

Le clientWifi local à la lecture de l'enphase n'est aussi pas une bonne chose pour la consommation de la mémoire RAM. Ce dernier point est aussi critique, car j'ai constaté aussi que lorsque la mémoire libre tombe en dessous d'environ 35000 octets, la page d'accueil commence à déconner et tout se coince .....

J'ai actuellement fait une version qui fonctionne très bien avec les points suivants:
- Une lecture de l'Enphase avec une ouverture et fermeture de la connexion à chaque lecture, ce qui limite à une lecture toutes les 1.2s environ, mais largement suffisant pour réguler la surproduction.
- Une lecture de l'Enphase avec le clientWifi (clientSecu) général à l'application pour établir des connexions Wifi et non pas une variable client Wifi locale à la fonction de lecture de l'Enphase.
- J'ai volontairement supprimer la fonction Telnet et toutes ses variables associées pour libérer de la consommation mémoire, ainsi que la gestion des compteurs Linky, qui consomme aussi beaucoup de mémoire. Du coup j'ai une consommation mémoire bien plus limitée que les dernières version actuelles (17.25 & 17.26) avec un mémoire libre qui se moyenne autour de 96000 et au plus bas à 55000.

Pour moi en conclusion de tout ça, il faut absolument, ouvrir et fermer la connexion du client Wifi en faisant "clientSecu.stop()" à la fin de la récupération des datas Enphase à chaque lecture et faire en sorte de maintenir une mémoire RAM disponible toujours au dessus de 40000 50000 octets pour que les pages Web n'aient pas de soucis.

Voilà si d'autres personnes ont des idées .....

Je peux aussi faire un code pour partager ces améliorations si vous n'utilisez pas Telnet et Linky.
Je ferrais aussi le test de prendre la dernière version 17.26 et mettre les améliorations nécessaires sans supprimer Telnet et Linky pour voir.

Quelle version vous intéresserait?

A+

Bonjour rdsoft30,
Il vaudrait mieux repartir de la version 17.26 puisque André à rajouter juste la partie OTA non accessible quand il y a pas d'internet, comme cela on suit toutes les dernières évolutions.
Quand tu parles de gestion Linky mais quand on est sur la source Enphase, la partie Linky n'est pas utilisé donc pas en mémoire.

Salut chichel 

Juste pour ton infos quand on n'utilise pas le compteur Linky il y a des variables en mémoire qui son quand meme la et initialisee pour le linky.
Je t'assure que c’est bien le cas et tu gagnes jusqu'à un peu plus de 10000 octets en supprimant complètement le Linky.

Sinon pour la version avec laquelle je vais proposer une amélioration je vais partir de la 17.26

A plus

[cmichel]

Salut à tous,

Je vais apporter quelques précisions sur ce que je constate. La version avec laquelle j'ai fait des tests et qui me pose des problèmes d'affichage graphique et data du tableau de la page d'accueil, est la version faite par tsabran qui a fait un super boulot pour optimiser la connexion avec Enphase et la récupérations des données. Cela produit aussi des statistiques interessantes pour comprendre ce qu'il se passe avec la connexion Enphase. Le problème n'est pas au niveau de la connexion avec Enphase, mais que cette version 17.25(tsabran) me donne des affichages erronés sur la page d'accueil. Ce n'est pas un raffraichissement avec CTRL+F5 du navigateur, c'est vraiement un problème de code.

Depuis la 17.22, André à repris le code que j'avais produit pour la connexion à l'Enphase. et depuis les datas remontent bien, mais ce code ralenti l'affichage de la page d'accueil, car il est trop consommateur de temps à mon avis. Il fait le job correctement pour lire les données Enphase et les envoyer en MQTT à un serveur comme HomeAssistant par exemple.

J'ai du coup travaillé à comprendre tout ça ce week-end. J'ai réussi à faire une nouvelle version un peu plus optimisé qui du coup ne présente pas de bugs d'affichage (data du tableau + graphique non affichés ou erronés (sans data)) avec une page Accueil beaucoup plus fluide et comme d'habituellement. Grace au super boulot de tsabran, j'ai récupéré certaine partie de son code qui optimise la récupération des données de l'Enphase. Cela produit donc une version plus saine encore pour le source code "Source_EnphaseEnvoy.ino".

Mes différents tests m'ont fait comprendre certaines choses importante que j'ai comfirmé sur 2 versions complètements différente de code.
La version de tsabran m'a permis de voir que le temps de connexion avec l'Enphase est de 1100ms environ sur ma configuration lorsque la connexion a été rompue et doit être établie (je parle du clientSecu.connect(), pas de la prise connexion complète avec récupération de la session ID et token). Lorsque la connexion est établie, il est possible d'avoir des lecture assez rapide d'environ 100ms en moyenne, mais cela fait en sorte que la connexion avec l'Enphase reste "ouverte" et c'est ça qui perturbe la page d'accueil !!!!

Le clientWifi local à la lecture de l'enphase n'est aussi pas une bonne chose pour la consommation de la mémoire RAM. Ce dernier point est aussi critique, car j'ai constaté aussi que lorsque la mémoire libre tombe en dessous d'environ 35000 octets, la page d'accueil commence à déconner et tout se coince .....

J'ai actuellement fait une version qui fonctionne très bien avec les points suivants:
- Une lecture de l'Enphase avec une ouverture et fermeture de la connexion à chaque lecture, ce qui limite à une lecture toutes les 1.2s environ, mais largement suffisant pour réguler la surproduction.
- Une lecture de l'Enphase avec le clientWifi (clientSecu) général à l'application pour établir des connexions Wifi et non pas une variable client Wifi locale à la fonction de lecture de l'Enphase.
- J'ai volontairement supprimer la fonction Telnet et toutes ses variables associées pour libérer de la consommation mémoire, ainsi que la gestion des compteurs Linky, qui consomme aussi beaucoup de mémoire. Du coup j'ai une consommation mémoire bien plus limitée que les dernières version actuelles (17.25 & 17.26) avec un mémoire libre qui se moyenne autour de 96000 et au plus bas à 55000.

Pour moi en conclusion de tout ça, il faut absolument, ouvrir et fermer la connexion du client Wifi en faisant "clientSecu.stop()" à la fin de la récupération des datas Enphase à chaque lecture et faire en sorte de maintenir une mémoire RAM disponible toujours au dessus de 40000 50000 octets pour que les pages Web n'aient pas de soucis.

Voilà si d'autres personnes ont des idées .....

Je peux aussi faire un code pour partager ces améliorations si vous n'utilisez pas Telnet et Linky.
Je ferrais aussi le test de prendre la dernière version 17.26 et mettre les améliorations nécessaires sans supprimer Telnet et Linky pour voir.

Quelle version vous intéresserait?

A+

Bonjour rdsoft30,
Il vaudrait mieux repartir de la version 17.26 puisque André à rajouter juste la partie OTA non accessible quand il y a pas d'internet, comme cela on suit toutes les dernières évolutions.
Quand tu parles de gestion Linky mais quand on est sur la source Enphase, la partie Linky n'est pas utilisé donc pas en mémoire.

Salut chichel 

Juste pour ton infos quand on n'utilise pas le compteur Linky il y a des variables en mémoire qui son quand meme la et initialisee pour le linky.
Je t'assure que c’est bien le cas et tu gagnes jusqu'à un peu plus de 10000 octets en supprimant complètement le Linky.

Sinon pour la version avec laquelle je vais proposer une amélioration je vais partir de la 17.26

A plus

Je comprends  rdsoft30 mais il faut garder la compatibilité avec les différentes sources et André y tient et je le comprends, donc si en modifiant comme tu le propose déjà on arrive à améliorer les choses et le fait de ne pas faire un clientwifi local devrait aussi faire gagner de la place

Moi avec la version de tsabran j'ai pas de souci d'affichage des pages web mais par contre je les ai minimiser avec un utilitaire minify que j'ai fait et j'ai un gain de place d'occupation de ces pages, s'était le cas avec la gestion de la borne VE. J'ai traité tous les fichiers .h

[rdsoft30]

Salut à tous,

Je vais apporter quelques précisions sur ce que je constate. La version avec laquelle j'ai fait des tests et qui me pose des problèmes d'affichage graphique et data du tableau de la page d'accueil, est la version faite par tsabran qui a fait un super boulot pour optimiser la connexion avec Enphase et la récupérations des données. Cela produit aussi des statistiques interessantes pour comprendre ce qu'il se passe avec la connexion Enphase. Le problème n'est pas au niveau de la connexion avec Enphase, mais que cette version 17.25(tsabran) me donne des affichages erronés sur la page d'accueil. Ce n'est pas un raffraichissement avec CTRL+F5 du navigateur, c'est vraiement un problème de code.

Depuis la 17.22, André à repris le code que j'avais produit pour la connexion à l'Enphase. et depuis les datas remontent bien, mais ce code ralenti l'affichage de la page d'accueil, car il est trop consommateur de temps à mon avis. Il fait le job correctement pour lire les données Enphase et les envoyer en MQTT à un serveur comme HomeAssistant par exemple.

J'ai du coup travaillé à comprendre tout ça ce week-end. J'ai réussi à faire une nouvelle version un peu plus optimisé qui du coup ne présente pas de bugs d'affichage (data du tableau + graphique non affichés ou erronés (sans data)) avec une page Accueil beaucoup plus fluide et comme d'habituellement. Grace au super boulot de tsabran, j'ai récupéré certaine partie de son code qui optimise la récupération des données de l'Enphase. Cela produit donc une version plus saine encore pour le source code "Source_EnphaseEnvoy.ino".

Mes différents tests m'ont fait comprendre certaines choses importante que j'ai comfirmé sur 2 versions complètements différente de code.
La version de tsabran m'a permis de voir que le temps de connexion avec l'Enphase est de 1100ms environ sur ma configuration lorsque la connexion a été rompue et doit être établie (je parle du clientSecu.connect(), pas de la prise connexion complète avec récupération de la session ID et token). Lorsque la connexion est établie, il est possible d'avoir des lecture assez rapide d'environ 100ms en moyenne, mais cela fait en sorte que la connexion avec l'Enphase reste "ouverte" et c'est ça qui perturbe la page d'accueil !!!!

Le clientWifi local à la lecture de l'enphase n'est aussi pas une bonne chose pour la consommation de la mémoire RAM. Ce dernier point est aussi critique, car j'ai constaté aussi que lorsque la mémoire libre tombe en dessous d'environ 35000 octets, la page d'accueil commence à déconner et tout se coince .....

J'ai actuellement fait une version qui fonctionne très bien avec les points suivants:
- Une lecture de l'Enphase avec une ouverture et fermeture de la connexion à chaque lecture, ce qui limite à une lecture toutes les 1.2s environ, mais largement suffisant pour réguler la surproduction.
- Une lecture de l'Enphase avec le clientWifi (clientSecu) général à l'application pour établir des connexions Wifi et non pas une variable client Wifi locale à la fonction de lecture de l'Enphase.
- J'ai volontairement supprimer la fonction Telnet et toutes ses variables associées pour libérer de la consommation mémoire, ainsi que la gestion des compteurs Linky, qui consomme aussi beaucoup de mémoire. Du coup j'ai une consommation mémoire bien plus limitée que les dernières version actuelles (17.25 & 17.26) avec un mémoire libre qui se moyenne autour de 96000 et au plus bas à 55000.

Pour moi en conclusion de tout ça, il faut absolument, ouvrir et fermer la connexion du client Wifi en faisant "clientSecu.stop()" à la fin de la récupération des datas Enphase à chaque lecture et faire en sorte de maintenir une mémoire RAM disponible toujours au dessus de 40000 50000 octets pour que les pages Web n'aient pas de soucis.

Voilà si d'autres personnes ont des idées .....

Je peux aussi faire un code pour partager ces améliorations si vous n'utilisez pas Telnet et Linky.
Je ferrais aussi le test de prendre la dernière version 17.26 et mettre les améliorations nécessaires sans supprimer Telnet et Linky pour voir.

Quelle version vous intéresserait?

A+

Bonjour rdsoft30,
Il vaudrait mieux repartir de la version 17.26 puisque André à rajouter juste la partie OTA non accessible quand il y a pas d'internet, comme cela on suit toutes les dernières évolutions.
Quand tu parles de gestion Linky mais quand on est sur la source Enphase, la partie Linky n'est pas utilisé donc pas en mémoire.

Salut chichel 

Juste pour ton infos quand on n'utilise pas le compteur Linky il y a des variables en mémoire qui son quand meme la et initialisee pour le linky.
Je t'assure que c’est bien le cas et tu gagnes jusqu'à un peu plus de 10000 octets en supprimant complètement le Linky.

Sinon pour la version avec laquelle je vais proposer une amélioration je vais partir de la 17.26

A plus

Je comprends  rdsoft30 mais il faut garder la compatibilité avec les différentes sources et André y tient et je le comprends, donc si en modifiant comme tu le propose déjà on arrive à améliorer les choses et le fait de ne pas faire un clientwifi local devrait aussi faire gagner de la place

Je vais préparer une version 17.26 sans supprimer le Linky ni le Telnet pour voir ce que ca donne et si ca fonctionne bien je partagerai le code.
A plus

[cmichel]

Je vais préparer une version 17.26 sans supprimer le Linky ni le Telnet pour voir ce que ca donne et si ca fonctionne bien je partagerai le code.
A plus

Moi avec la version de tsabran j'ai pas de souci d'affichage des pages web mais par contre je les ai minimiser avec un utilitaire minify que j'ai fait et j'ai un gain de place d'occupation de ces pages, c'était le cas avec la gestion de la borne VE. 
J'ai traité tous les fichiers .h

[F1ATB]

Bonjour RdSoft30

Je suis intéressé par votre version si vous partez de la V17.26 en conservant le Linky et Telnet. Je pourrai la diffuser officiellement en 17.27.

André / F1ATB

[Alain_C38]

Moi non plus avec la version de tsabran, je n'ai aucun problème d'affichage.

Comme évoqué dans une autre discussion, ne serait ce pas plutôt un pb d'initialisation de certaines variables et qui impacterait le navigateurs autres que Firefox et Safari (les navigateurs que j'utilise) ?

[Luc1]

Moi non plus avec la version de tsabran, je n'ai aucun problème d'affichage.

Comme évoqué dans une autre discussion, ne serait ce pas plutôt un pb d'initialisation de certaines variables et qui impacterait le navigateurs autres que Firefox et Safari (les navigateurs que j'utilise) ?

Bjr à tous,
version "Tsabran" en test depuis 19H sans pb autre que rafraichissement des affichages erratique sous Firefox/W11  Edge/W11 Chrome/W11 ainsi que Chrome/android;
Mais version non redémarrée (et donc variables non reinitialisées) entre les tests. Faut il retester après un redémarrage/reset ?
Et aussi aspect comparé des courbes (entre 17.25 "officielle" et "tsabran") un petit peu différentes en forme et en valeurs absolues (lié à fréquence échantillonnage? ) avec P apparente en signaux "carrés" comme PWM entre + et - 1200 VA lors des phases de régulation.
Je note Ram libre mini 372 octets (shorty ?)

[rdsoft30]

Bonjour RdSoft30

Je suis intéressé par votre version si vous partez de la V17.26 en conservant le Linky et Telnet. Je pourrai la diffuser officiellement en 17.27.

André / F1ATB

Bonsoir André,

Je prépare tout ça sous peu de temps.
Je posterai un message ici dès que j'aurai fait quelques tests avec pour m'assurer que tout va bien.

A très bientôt.

David

[michy]

Bonjour, 

  avant de commencer à sacrifier des modules (peut être que certain n'apprécierons pas / je n'ai rien contre les belges, mais il y a certainement en service plus de Source Linky que Smartgateway et HomeWizard réunis, si vraiment, il fallait choisir ...)  :

  => pas la peine de supprimer le module linky pour gagner les 10k de ram utilisés par la variable DataRawLinky,

  il suffit de transformer DataRawLinky en pointeur (ça ne consomme que 4 octets quand ce n'est pas utilisé) 

Code :

//volatile char DataRawLinky[10000];  //Buffer entrée données Linky
#define SIZEBUFFCIRC  10000 // taille du buffer pour trame linky  (utiliser cette constante partout où le 10000 fait référence à la taille du buffer)
volatile char* DataRawLinky = NULL;  // Utilisation d'un pointeur, allocation de RAM uniquement si la source est Linky

  et allouer la mémoire uniquement si Source est "Linky", dans la fonction Setup_Linky() qui n'est appelé qu'une fois lors du boot

Code :

  if (DataRawLinky == NULL) {
    DataRawLinky = (volatile char*)malloc(SIZEBUFFCIRC);
    if (DataRawLinky != NULL) {
      memset((void*)DataRawLinky, 0, SIZEBUFFCIRC);
    } else {
      Serial.println("Erreur : Mémoire insuffisante pour Linky !");
      return;
    }
  }

+ une vérification avant usage dans server.ino

Code :

    //if (Source_data == "Linky") {
    if (Source_data == "Linky" && DataRawLinky != NULL ) {

Si on veut continuer dans cette voie : 
* quand il n'y a pas de sonde de température, c'est tabTemperature_5mn qui consomme 4800 octets
* quand on n'utilise pas le module UxI, il y a les tableaux volt[100], amp[100], voltM[100] et ampM[100]  qui consomme 1600 octets en permanence (usage ou pas de UxI)
* affecté la mémoire en fonction du nombre d'actions effectivement en place 
* pas de triac .... c'est encore quelques d'octets qu'on peut rendre disponible

* Une fusion des modules Shelly qui font sensiblement la même chose
* Pas mal de variable globale qui pourrait être déporté en static dans la fonction qui l'utilise (le RAM ne sera alloué que si on exécute la fonction au moins une fois)



  Dans toutes les variantes de version pour la source Enphase (depuis la mise à jour du firmware qui pose problème), vous avez tous continué dans la voie de la gestion du client réseau à la main, alors qu'il y a des fonctions éprouvées, optimisées, native dans l'environnement Espressif [=> httpClient, les timeouts sont parfaitement maitrisés en arrière plan, pas la peine se compliquer l'histoire soit même]

de même, vous gérez du json à la main alors qu'on embarque déjà le code de ArduinoJson, (on peut gagner sur plusieurs tableaux : on supprime le code qui gère des String à n'en plus finir, on enlève le code redéveloppé (qui prend de la place, alors que ArduinoJson est déjà dispo et beaucoup plus conforme aux spécifications 'json.org'), couplé avec httpClient et du filtrage direct sur le flux réseau, ça optimise l'usage de RAM et la vitesse d'exécution




un des plus gros gain possible c'est de supprimer les fonctions qui crée et traite moulte copies des chaines en RAM : 

un simple String avec un '+' c'est la taille de la chaine d'origine + la taille de la chaine a ajouter  qui se retrouve dupliqué en RAM et pour faire ça, il faut un bloc de ram continu suffisamment grand (et malheureusement les String, ça semble facile à utiliser mais, ça fragmente la mémoire en multiple bloc jusqu'à ce qu'il n'y ai plus de bloc d'un seul tenant assez grand)  ... entre temps, c'est des plantages ou choses pas attendu qui se produisent et difficile à comprendre (quand je vois 372 octets dispo, ça ne peut que mal finir à court terme)

ajoutons que le passage de String en paramètres de fonction (sans usage de const String &  ), ça duplique encore une fois