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

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

+- F1ATB forum (https://f1atb.fr/forum_f1atb)
+-- Forum : Forum de F1ATB (https://f1atb.fr/forum_f1atb/forum-3.html)
+--- Forum : Routeur Photovoltaïque (https://f1atb.fr/forum_f1atb/forum-4.html)
+--- Sujet : Plus d'accès aux données de la passerelle Enphase Envoy (/thread-2795.html)

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

RE: Plus d'accès aux données de la passerelle Enphase Envoy - F1ATB - 12-07-2026

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é

RE: Plus d'accès aux données de la passerelle Enphase Envoy - rdsoft30 - 12-07-2026

(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 pécher dessus de toutes façons, car je pense quil y a un truc bizarre.

Aurais tu une idée ?

Je peux faire une capture d'écran si besoin.

Merci a toi André et A+

David

RE: Plus d'accès aux données de la passerelle Enphase Envoy - F1ATB - 12-07-2026

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é

RE: Plus d'accès aux données de la passerelle Enphase Envoy - Luc1 - 12-07-2026

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

RE: Plus d'accès aux données de la passerelle Enphase Envoy - rdsoft30 - 12-07-2026

(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-post-25438.html#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.

RE: Plus d'accès aux données de la passerelle Enphase Envoy - Alain_C38 - 12-07-2026

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 !

RE: Plus d'accès aux données de la passerelle Enphase Envoy - michy - 13-07-2026

Bonjour,

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

Code :
    if (Source_data == "UxI" && voltM != nullptr && ampM != nullptr) {

RE: Plus d'accès aux données de la passerelle Enphase Envoy - F1ATB - 13-07-2026

(12-07-2026, 07:21 PM)rdsoft30 a écrit :
(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-post-25438.html#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.

André

RE: Plus d'accès aux données de la passerelle Enphase Envoy - cmichel - 13-07-2026

(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 ?

Merci à vous.

On avance .... dans l'optimisation.

Voilà ou télécharger les sources et le binaire:
https://drive.google.com/drive/folders/1QjxebdRgetn2uR-xglWgiAgOvnJW59M6?usp=drive_link

David

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é ?

RE: Plus d'accès aux données de la passerelle Enphase Envoy - rdsoft30 - 13-07-2026

(13-07-2026, 09:16 PM)cmichel a écrit :
(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 ?

Merci à vous.

On avance .... dans l'optimisation.

Voilà ou télécharger les sources et le binaire:
https://drive.google.com/drive/folders/1QjxebdRgetn2uR-xglWgiAgOvnJW59M6?usp=drive_link

David
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 laté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

Bonne soirée et A+

David