(06-07-2026, 09:18 PM)michy a écrit : 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

(07-07-2026, 03:58 PM)cmichel a écrit : Bonjour rdsoft30,
Version en test et pour le moment ça fonctionne pas mal, j'ai quelques messages:
07/07/2026 15:21:38 : Envoy error while reading HTTP response status, status= TIMEOUT, partialLen=0
07/07/2026 15:33:14 : Envoy error while reading HTTP response status, status= TIMEOUT, partialLen=0

Mais peu et les graphiques et les pages sont correctes, je laisse en // le fonctionnement pour comparer, à voir la suite

• En V17.27:
  

• En V ”tsabran”
  

(08-07-2026, 04:45 PM)aero a écrit : Bonjour a tous,

Je suis passé en 17.27 hier en fin d'après midi.

Tout a l'air de fonctionner après quasiment 1 jour de fonctionnement.
J'ai encore en Ram libre minimum 3700 octets

Mais j'ai pas mal d'erreur de type :
08/07/2026 16:35:26 : JSON Loading failed
08/07/2026 16:37:00 : Envoy JSON Reading 3 failed, status= TIMEOUT, partialLen=430
08/07/2026 16:37:00 : JSON Loading failed
08/07/2026 16:38:04 : Envoy JSON Reading 3 failed, status= TIMEOUT, partialLen=432
08/07/2026 16:38:04 : JSON Loading failed
08/07/2026 16:38:54 : Envoy error while reading HTTP response status, status= TIMEOUT, partialLen=0
08/07/2026 16:39:56 : Envoy JSON Reading 3 failed, status= TIMEOUT, partialLen=434
08/07/2026 16:39:56 : JSON Loading failed
08/07/2026 16:41:02 : Envoy JSON Reading 3 failed, status= TIMEOUT, partialLen=424
08/07/2026 16:41:02 : JSON Loading failed

Je précise également que j'ai l'appli sur mon téléphone (pas ouverte de la journée) et que j'ai également le plugin enphase dans mon HA (qui lui doit communiquer toutes les 15 ou 20 secondes de mémoire)

Un grand merci a tous pour vos recherches/développements de ce magnifique projet.