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]

intéressant (voir le message suivant)