Note de ce sujet :
  • Moyenne : 4.67 (6 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Plus d'accès aux données de la passerelle Enphase Envoy
(28-07-2026, 05:25 PM)rdsoft30 a écrit : Salut à tous,

De mon côté la dernière version que j'ai proposée fonctionne à merveille chez moi. Aucuns messages d'erreur depuis plus de 296h de fonctionnement non stop et jamais aucuns problèmes d'affichage de la page d'accueil ni des autres d'ailleurs.
Tout est opérationnel de façon optimale de mon côté.
Malgrès un niveau mémoire minimum assez bas atteint, certainement qu'une seule fois aussi bas, je n'ai aucuns soucis.

Cette dernière version est de loin la plus fiable et stable que j'ai utilisé.

@cmichel,

Merci pour ton retour, et de rien, si le travail profite à tout le monde c'est top !

A+

David
Bonjour,
David je soulève un problème que je rencontre avec la version pour la borne VE que je teste cela mets en évidence en tout cas puisque jusque là je ne l'avais eu que une fois en test ce problème de reboot et en réfléchissant on a sur le coeur 0 de l'esp32 LectureEnphase() et sur le coeur 1 on a Call_RTE_data().

LectureEnphase() et Call_RTE_data() utilise le même objet global clientSecu, j'avais de temps en temps des reboots et j'ai remis avec 2 objets différents et j'ai depuis 0 reboot.
Où il faut sécuriser pour éviter ce risque que j'ai eu soit en revenant à la variable clientSecuRTE ou en utilisant un mutex.

Je suis revenu à la 2ème variable mais j'ai une RAM qui descend actuellement à 5284 et la ça tourne depuis 1h.
Par contre un autre test avec la 2ème variable locale à void Call_RTE_data() et là j'ai la ram mini à 12800 et ne semble pas bouger depuis un bon moment à suivre.

Tu as pas eu de reboot surement pas de coïncidence mais en plus mon envoy a déjà une autre appli qui fait des requettes et c'est aussi la coïncidence de l'appel de l'heure RTE, mais on l'aura forcément à des moments.
A+
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
Répondre

(29-07-2026, 04:38 PM)cmichel a écrit :
(28-07-2026, 05:25 PM)rdsoft30 a écrit : Salut à tous,

De mon côté la dernière version que j'ai proposée fonctionne à merveille chez moi. Aucuns messages d'erreur depuis plus de 296h de fonctionnement non stop et jamais aucuns problèmes d'affichage de la page d'accueil ni des autres d'ailleurs.
Tout est opérationnel de façon optimale de mon côté.
Malgrès un niveau mémoire minimum assez bas atteint, certainement qu'une seule fois aussi bas, je n'ai aucuns soucis.

Cette dernière version est de loin la plus fiable et stable que j'ai utilisé.

@cmichel,

Merci pour ton retour, et de rien, si le travail profite à tout le monde c'est top !

A+

David
Bonjour,
David je soulève un problème que je rencontre avec la version pour la borne VE que je teste cela mets en évidence en tout cas puisque jusque là je ne l'avais eu que une fois en test ce problème de reboot et en réfléchissant on a sur le coeur 0 de l'esp32 LectureEnphase() et sur le coeur 1 on a Call_RTE_data().

LectureEnphase() et Call_RTE_data() utilise le même objet global clientSecu, j'avais de temps en temps des reboots et j'ai remis avec 2 objets différents et j'ai depuis 0 reboot.
Où il faut sécuriser pour éviter ce risque que j'ai eu soit en revenant à la variable clientSecuRTE ou en utilisant un mutex.

Je suis revenu à la 2ème variable mais j'ai une RAM qui descend actuellement à 5284 et la ça tourne depuis 1h.
Par contre un autre test avec la 2ème variable locale à void Call_RTE_data() et là j'ai la ram mini à 12800 et ne semble pas bouger depuis un bon moment à suivre.

Tu as pas eu de reboot surement pas de coïncidence mais en plus mon envoy a déjà une autre appli qui fait des requettes et c'est aussi la coïncidence de l'appel de l'heure RTE, mais on l'aura forcément à des moments.
A+
Salut,

Merci pour tes remarques. En effet j'ai pas fait attention que si les 2 coeur accèdent à l'objet ClientSecu, il faut protéger par un mutex ou bien séparer les 2 clients.
Je vais regarder s'il est préférable de faire une ou l'autre solution de mon côté. Je n'ai pas eu de soucis depuis plus de 300h de fonctionnement car je n'utilise pas le RTE qui utilise la fonction Call_RTE_data() ....

Je regarde ça et propose une nouvelle version que je partagerai.
Le soucis c'est que je ne peux pas tester la fonction RTE .....

Je te tiens au courant

A+

David
Répondre

(29-07-2026, 07:12 PM)rdsoft30 a écrit :
(29-07-2026, 04:38 PM)cmichel a écrit :
(28-07-2026, 05:25 PM)rdsoft30 a écrit : Salut à tous,

De mon côté la dernière version que j'ai proposée fonctionne à merveille chez moi. Aucuns messages d'erreur depuis plus de 296h de fonctionnement non stop et jamais aucuns problèmes d'affichage de la page d'accueil ni des autres d'ailleurs.
Tout est opérationnel de façon optimale de mon côté.
Malgrès un niveau mémoire minimum assez bas atteint, certainement qu'une seule fois aussi bas, je n'ai aucuns soucis.

Cette dernière version est de loin la plus fiable et stable que j'ai utilisé.

@cmichel,

Merci pour ton retour, et de rien, si le travail profite à tout le monde c'est top !

A+

David
Bonjour,
David je soulève un problème que je rencontre avec la version pour la borne VE que je teste cela mets en évidence en tout cas puisque jusque là je ne l'avais eu que une fois en test ce problème de reboot et en réfléchissant on a sur le coeur 0 de l'esp32 LectureEnphase() et sur le coeur 1 on a Call_RTE_data().

LectureEnphase() et Call_RTE_data() utilise le même objet global clientSecu, j'avais de temps en temps des reboots et j'ai remis avec 2 objets différents et j'ai depuis 0 reboot.
Où il faut sécuriser pour éviter ce risque que j'ai eu soit en revenant à la variable clientSecuRTE ou en utilisant un mutex.

Je suis revenu à la 2ème variable mais j'ai une RAM qui descend actuellement à 5284 et la ça tourne depuis 1h.
Par contre un autre test avec la 2ème variable locale à void Call_RTE_data() et là j'ai la ram mini à 12800 et ne semble pas bouger depuis un bon moment à suivre.

Tu as pas eu de reboot surement pas de coïncidence mais en plus mon envoy a déjà une autre appli qui fait des requettes et c'est aussi la coïncidence de l'appel de l'heure RTE, mais on l'aura forcément à des moments.
A+
Salut,

Merci pour tes remarques. En effet j'ai pas fait attention que si les 2 coeur accèdent à l'objet ClientSecu, il faut protéger par un mutex ou bien séparer les 2 clients.
Je vais regarder s'il est préférable de faire une ou l'autre solution de mon côté. Je n'ai pas eu de soucis depuis plus de 300h de fonctionnement car je n'utilise pas le RTE qui utilise la fonction Call_RTE_data() ....

Je regarde ça et propose une nouvelle version que je partagerai.
Le soucis c'est que je ne peux pas tester la fonction RTE .....

Je te tiens au courant

A+

David
David,
Je t'ai mis en message privé les sources avec une solution en séparant les 2 clients qui sera la meilleure solution pour moi que de mettre un mutex, en plus le RTE est appelé peu par rapport au client enphase.
Mon test actuellement depuis la correction que je t'ai envoyé pas de reboot et cela donne aprés presque 4h la Mémoire RAM libre actuellement : 99352 octet
Mémoire RAM libre minimum : 10396 octet
A+
Michel
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
Répondre

(29-07-2026, 08:45 PM)cmichel a écrit :
(29-07-2026, 07:12 PM)rdsoft30 a écrit :
(29-07-2026, 04:38 PM)cmichel a écrit :
(28-07-2026, 05:25 PM)rdsoft30 a écrit : Salut à tous,

De mon côté la dernière version que j'ai proposée fonctionne à merveille chez moi. Aucuns messages d'erreur depuis plus de 296h de fonctionnement non stop et jamais aucuns problèmes d'affichage de la page d'accueil ni des autres d'ailleurs.
Tout est opérationnel de façon optimale de mon côté.
Malgrès un niveau mémoire minimum assez bas atteint, certainement qu'une seule fois aussi bas, je n'ai aucuns soucis.

Cette dernière version est de loin la plus fiable et stable que j'ai utilisé.

@cmichel,

Merci pour ton retour, et de rien, si le travail profite à tout le monde c'est top !

A+

David
Bonjour,
David je soulève un problème que je rencontre avec la version pour la borne VE que je teste cela mets en évidence en tout cas puisque jusque là je ne l'avais eu que une fois en test ce problème de reboot et en réfléchissant on a sur le coeur 0 de l'esp32 LectureEnphase() et sur le coeur 1 on a Call_RTE_data().

LectureEnphase() et Call_RTE_data() utilise le même objet global clientSecu, j'avais de temps en temps des reboots et j'ai remis avec 2 objets différents et j'ai depuis 0 reboot.
Où il faut sécuriser pour éviter ce risque que j'ai eu soit en revenant à la variable clientSecuRTE ou en utilisant un mutex.

Je suis revenu à la 2ème variable mais j'ai une RAM qui descend actuellement à 5284 et la ça tourne depuis 1h.
Par contre un autre test avec la 2ème variable locale à void Call_RTE_data() et là j'ai la ram mini à 12800 et ne semble pas bouger depuis un bon moment à suivre.

Tu as pas eu de reboot surement pas de coïncidence mais en plus mon envoy a déjà une autre appli qui fait des requettes et c'est aussi la coïncidence de l'appel de l'heure RTE, mais on l'aura forcément à des moments.
A+
Salut,

Merci pour tes remarques. En effet j'ai pas fait attention que si les 2 coeur accèdent à l'objet ClientSecu, il faut protéger par un mutex ou bien séparer les 2 clients.
Je vais regarder s'il est préférable de faire une ou l'autre solution de mon côté. Je n'ai pas eu de soucis depuis plus de 300h de fonctionnement car je n'utilise pas le RTE qui utilise la fonction Call_RTE_data() ....

Je regarde ça et propose une nouvelle version que je partagerai.
Le soucis c'est que je ne peux pas tester la fonction RTE .....

Je te tiens au courant

A+

David
David,
Je t'ai mis en message privé les sources avec une solution en séparant les 2 clients qui sera la meilleure solution pour moi que de mettre un mutex, en plus le RTE est appelé peu par rapport au client enphase.
Mon test actuellement depuis la correction que je t'ai envoyé pas de reboot et cela donne aprés presque 4h la Mémoire RAM libre actuellement : 99352 octet
Mémoire RAM libre minimum : 10396 octet
A+
Michel

Salut Michael,

J'ai fait la même modification que toi, c'est à dire mettre un 2eme Client en local. Comme tu dis c'est pas appellé souvent et ça ne consomme pas la mémoire en permanence, contrairement à avant ou c'était en global.
C'est aussi en court de test de mon côté mais je ne vais pas voir plus de changements car je n'utilise pas le RTE.

Merci à toi on se tiens au courant ;-)

David
Répondre

Citation :Salut Michel,

J'ai fait la même modification que toi, c'est à dire mettre un 2eme Client en local. Comme tu dis c'est pas appellé souvent et ça ne consomme pas la mémoire en permanence, contrairement à avant ou c'était en global.
C'est aussi en court de test de mon côté mais je ne vais pas voir plus de changements car je n'utilise pas le RTE.

Merci à toi on se tiens au courant ;-)

David
Bonjour David,
Aprés plusieurs jours de fonctionnement on touche au bout de cette version pas de reboot et trés peu de messages pour ma part donc je pense qu'André va pouvoir passer à la version 17.28 si bien sur tu valides aussi suite à ces dernières modifications et j'utilise le RTE dans ma version.
Les pages restent fluides.

Peut-être mettre à disposition cette dernière version avec les modifications que l'on a fait peut être d'autres testerons et André pourra la rendre officielle pour la partie Enphase.

Merci encore.
Michel
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
Répondre



Atteindre :


Utilisateur(s) parcourant ce sujet :
3 visiteur(s)

Moteur MyBB, © 2002-2026 Melroy van den Berg.