Certes les différentes variables globales sont coûteuses, mais il faut remarquer que lorsque l'on travaille avec des sources comme UxI, UxIx2,Linky,Externe le la RAM libre minimum est au-dessus de 30k en V17.27.
Avec un Shelly 3em je suis au-dessus de 20k de libre minimum.
On peut en conclure que la communication Enphase grève le plus l'espace mémoire si certains descendent à quelques Ko. Je ne peux pas faire le test chez moi. Je n'ai plus d'accès à un système Enphase.
(12-07-2026, 11:45 AM)F1ATB a écrit : Certes les différentes variables globales sont coûteuses, mais il faut remarquer que lorsque l'on travaille avec des sources comme UxI, UxIx2,Linky,Externe le la RAM libre minimum est au-dessus de 30k en V17.27.
Avec un Shelly 3em je suis au-dessus de 20k de libre minimum.
On peut en conclure que la communication Enphase grève le plus l'espace mémoire si certains descendent à quelques Ko. Je ne peux pas faire le test chez moi. Je n'ai plus d'accès à un système Enphase.
Cordialement
André
Salut André,
Pas certain que tout soit dû au code Enphase....
Je m’explique:
Lorsque l’application se lance et qu’on va directement sur la page des infos Brute avec un système enphase configuré, la mémoire minimum est entre 25 a 35 ko.
A ce moment la si tu vas sur la page d'accueil et que tu reviens sur la page Brute, ben la mémoire s’est effondrée au mieux a 1.5ko et des fois bien en dessous......
Si tu ne vas jamais sur la page d'accueil il n’y a pas de soucis de mémoire......
Faudrait détourner un graphique pour quil affiche l'évolution de la mémoire mini et maxi.....
Je ne sais pas ce quil se passe vraiment.
Je vais creuser ca, mais ca demande du temps......
Je vais me pécher dessus de toutes façons, car je pense quil y a un truc bizarre.
Je n'ai pas d'explication de ce phénomène. Je viens de faire sur un Shelly et un Linky, la même mamip. Accueil, Brute, Accueil, Brute. Il n'y a pas de changement d'espace libre.
12-07-2026, 07:16 PM (Modification du message : 12-07-2026, 07:17 PM par Luc1.)
Ma contribution pour enphase tendrait à valider l'observation de David puisque après un redémarrage sur page brute : Ram min 35788, puis appel page accueil et 2 ou 3 rafraîchissement de celle ci plus tard elle s'effondre à 1840.
J’avais déjà attiré votre attention sur des valeurs à peine 276 lors d’un post précédent du 4 juillet.
Je renforce l'hypothèse d’un pb gestion mémoire tout en étant strictement incapable d'y donner une explication ni solution...
Je compte sur cette sympathique communauté autour d'André ! Merci à tous
Francis
(12-07-2026, 06:32 PM)F1ATB a écrit : Je n'ai pas d'explication de ce phénomène. Je viens de faire sur un Shelly et un Linky, la même mamip. Accueil, Brute, Accueil, Brute. Il n'y a pas de changement d'espace libre.
Cdlt
André
Salut André,
Très interressant comme infos de savoir que ça ne bouge pas avec Shelly et Linky.
Est ce que tu peux tester la version que j'ai faite sur la base de ta 17.27 avec allocation dynamique de la mémoire pour le Linky ? (voir mon dernier post #431 avec le partage des fichiers source et binaire : https://f1atb.fr/forum_f1atb/thread-2795...l#pid25438)
Si tu as un linky ça m'interresse de savoir si ça fonctionne correctement. Normalement oui mais, je ne peux pas tester.
Mini retour sur la 17.27-rdsoft30 après 30 h de fonctionnement.
RAM mini stable à 3632 octets.
La moyenne du coeur 0 est un peu plus haute que sur la version standard, autour de 10/11.
Le basculement en cascade de la page d'accueil <--> Brute n'entraine plus de baisse particulière (tjrs après 30 h de fonctionnement).
Bravo !
-------------------------------------------------------------- ESP32 (v17.27 et IP fixe) + sonde température + SSR -- Cumulus/Chauffe-Eau
Source données serveur Enphase.
une explication possible sur l'effondrement de mémoire lors du passage sur la page d'accueil pourrait être l'usage d'un "+" entre String et row string litteral
Code :
server.send(200, "text/javascript", S + MainJS1); // Javascript code
a faire évoluer en une opération en plusieurs fois qui traite les variables différemment, le S String en RAM, le reste est obtenu de la flash sans passage par une copie en RAM
Code :
server.setContentLength(CONTENT_LENGTH_UNKNOWN);
server.send(200, "application/javascript", S); // on profite pour changer le code MIME adapté a du javascript !
server.sendContent(MainJS1);
on a la même situation a traiter avec
Code :
server.send(200, "text/css", S + CommunCSS);
aussi pour gagner encore facilement une dizaine de ko de ram, remplacer
Code :
oled.setTextFont(1); // la font n°1 n'existe pas (on retombe sur la Font0), l'usage de cette fonction force le system à charger le tableau des fonts 0,2,4,6,7 et 8
par
Code :
oled.setFont(&fonts::Font0); // remplace la fonction setTextFont (déprécié?) en chargeant que la Font0 utilisée
+ quelques autres octets a gagner (~1.5ko) en faisant cette manip (utile pour ceux qui n'utilise pas UxI):
Dans le paquet de déclaration du main on supprime les variables global + déclaration pointeur pour voltM et ampM
Code :
//int volt[100]; // supprimé de la déclaration globale (déplacé dans LectureUxI) + remplacement par variable sur 2 octets
//int amp[100]; // supprimé de la déclaration globale
//float voltM[100]; //remplacé par un pointer initialisé dans setup_UxI
//float ampM[100]; //remplacé par un pointer initialisé dans setup_UxI
float* voltM = nullptr; //Voltage Mean value
float* ampM = nullptr;
Dans Setup_UxI, on ajoute 3 lignes
Code :
void Setup_UxI() {
if (voltM == nullptr) voltM = (float*)malloc(100*sizeof(float)); // alloue un peu de mémoire si ce n'est pas déjà fait
if (ampM == nullptr) ampM = (float*)malloc(100*sizeof(float)); // alloue un peu de mémoire
if (voltM == nullptr || ampM == nullptr) return; // il y a eu un probleme dans l'allocation mémoire, on sort
On supprime les fonctions MeasurePower et ComputePower en fusionnant le tout dans LectureUxI()
Code :
void LectureUxI() {
// MeasurePower(); // la fonction MeasurePower n'existe plus
// ComputePower(); // la fonction ComputePower n'existe plus
//} // continu le traitement des 2 fonctions précédentes avec l'appel de LectureUxI()
//void MeasurePower() {
//Lecture Tension et courants pendant 20ms
int iStore;
value0 = analogRead(AnalogIn0); //Mean value. Should be at 3.3v/2 /35
static unsigned long OverflowOffset = 0;
static unsigned long PrevMicros = 0;
unsigned long NowMicros;
unsigned long MeasureMillis = millis();
//int volt[100]; // bascule en pointeur a portée local
//int amp[100]; // bascule en pointeur a portée local
static int16_t *volt = nullptr; // int16_t est suffisant pour stocker des valeurs entre -2048 et +2048
static int16_t *amp = nullptr;
if (volt == nullptr) volt = (int16_t*)malloc(100*sizeof(int16_t)); // alloue un peu de mémoire seulement si c'est une source UxI
if (amp == nullptr) amp = (int16_t*)malloc(100*sizeof(int16_t)); // alloue un peu de mémoire seulement si c'est une source UxI
if (volt == nullptr || amp == nullptr || voltM == nullptr || ampM == nullptr) return; // il y a eu un probleme dans l'allocation mémoire
// inutile de chercher a libérer la RAM allouée, un reboot est obligatoire si on change de source de mesure
.
.
.
PrevMicros = NowMicros;
}
//} // la fonction MeasurePower n'existe plus
//
//void ComputePower() { // la fonction ComputePower n'existe plus
float PWcal = 0; //Computation Power in Watt
+ un garde fou dans server.ino, fonction handleAjaxRMS() qui uilise voltM et ampM quand la source est UxI
Si les réponses que je propose bénévolement sur ce forum ne vous plaisent pas, ignorez-les simplement sans me jeter la pierre ! (Ou ne posez pas de question)
(12-07-2026, 06:32 PM)F1ATB a écrit : Je n'ai pas d'explication de ce phénomène. Je viens de faire sur un Shelly et un Linky, la même mamip. Accueil, Brute, Accueil, Brute. Il n'y a pas de changement d'espace libre.
Cdlt
André
Salut André,
Très interressant comme infos de savoir que ça ne bouge pas avec Shelly et Linky.
Est ce que tu peux tester la version que j'ai faite sur la base de ta 17.27 avec allocation dynamique de la mémoire pour le Linky ? (voir mon dernier post #431 avec le partage des fichiers source et binaire : https://f1atb.fr/forum_f1atb/thread-2795...l#pid25438)
Si tu as un linky ça m'interresse de savoir si ça fonctionne correctement. Normalement oui mais, je ne peux pas tester.
Merci à toi.
Avec la version rdsoft qui met un pointeur sur l'allocation mémoire pour le Linky, cela fonctionne bien sur mon routeur connecté au Linky. Après 3h de fonctionnement, je suis à 43k de mémoire libre minimum.
(09-07-2026, 06:38 PM)rdsoft30 a écrit : Salut à tous,
Comme promis je poste ce message pour vous partager une amélioration que j'ai faite sur la base de la version 17.27 publié par André.
J'ai optimiser un peu l'emprunte mémoire en faisant une allocation dynamique de la mémoire si le module Linky est utilisé.
De ce fait si pas d'utilisation du Linky, on sauvegarde donc 4000 octets de mémoire.
Egalement, j'ai utilisé la connexion clientSecu globale à l'application, pour interroger le TempoRTE. Du coup pas besoin d'instancier une nouvelle instance de client.
De mon côté l'application fonctionne mieux encore.
Est ce que quelqu'un qui utilise la lecture du module Linky, peut me confirmer que tout fonctionne correctement encore ?
Est ce que quelqu'un qui utilise la lecture du module TempoRTE, peut me confirmer que tout fonctionne correctement encore ?
Bonjour David,
Je viens de tester ta version sous enphase et je suis en triphasé et le RMS reboote et me le plante, pas d'affichage de données quand j'ai pu afficher la page données brutes, pour le moment j'ai pas eu le temps d'approfondir, pas trop le temps en ce moment.
J'ai pour le moment remis la version 17.27 d'André aprés quelques problèmes pour remettre en route mon RMS.
Est-ce que quelqu'un à tester cette version de David avec enphase et en triphasé ?
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
(09-07-2026, 06:38 PM)rdsoft30 a écrit : Salut à tous,
Comme promis je poste ce message pour vous partager une amélioration que j'ai faite sur la base de la version 17.27 publié par André.
J'ai optimiser un peu l'emprunte mémoire en faisant une allocation dynamique de la mémoire si le module Linky est utilisé.
De ce fait si pas d'utilisation du Linky, on sauvegarde donc 4000 octets de mémoire.
Egalement, j'ai utilisé la connexion clientSecu globale à l'application, pour interroger le TempoRTE. Du coup pas besoin d'instancier une nouvelle instance de client.
De mon côté l'application fonctionne mieux encore.
Est ce que quelqu'un qui utilise la lecture du module Linky, peut me confirmer que tout fonctionne correctement encore ?
Est ce que quelqu'un qui utilise la lecture du module TempoRTE, peut me confirmer que tout fonctionne correctement encore ?
Bonjour David,
Je viens de tester ta version sous enphase et je suis en triphasé et le RMS reboote et me le plante, pas d'affichage de données quand j'ai pu afficher la page données brutes, pour le moment j'ai pas eu le temps d'approfondir, pas trop le temps en ce moment.
J'ai pour le moment remis la version 17.27 d'André aprés quelques problèmes pour remettre en route mon RMS.
Est-ce que quelqu'un à tester cette version de David avec enphase et en triphasé ?
Salut Michel,
J’ai eu un cas ce week end avec ma version ou quand j’avais une grosse charge d'échange sur mon réseau wifi et box, les temps de récupération de données sur l’enphase s'allonge considérablement et cela peu meme jusqu'à bloquer ou fortement ralentir le code et provoquer un reboot.
Je vais travailler sur le sujet.
Alors les personnes qui ont beaucoup de déconnexions ou messages voire meme des reboot, c’est peut etre lié a la charge sur votre réseau internet maison très certainement.
De mon côté chez moi rien n’est en wifi a part les modules esp32. Box pc et autres systèmes sont en filaires.....
Du coup chez des personnes qui sont beaucoup en wifi ca peut provoquer des latence de communication plus lentes que 1.1s chez moi.
Ce matin quand j’ai découvert le comportement en grosses charge j’avais des latéces de 3 a 5 voir plus secondes.
Apres il faut que je regarde si cest pas le coupleur CPL qui perturbe le boitier esp32...... a cause des modulations sur les fils d'alimentation.
Me faut faire des tests encore et je reviendrai vers vous
,