Bonsoir André, à tous,
J'ai porté les améliorations que j'ai décrite dans un post précédent dans le fichier Source_EnphaseEnvoy.ino.
Cette amélioration qui porte uniquement sur la récupération des données Enphase marche très bien et provique beaucoup moins de reconnexion ou perte de données.
Je partage donc les fichiers sources modifiés ainsi que le binaire (base de v17.26 André + mes modifications).
Je précise que j'ai laissé tout ce qu'il y a dans la version 17.26 sur le site d'André ( donc pas de suppression de la gestion du Linky, ni du Telnet).
En revanche j'ai des problèmes assez fréquents d'affichage de la page d'accueil, rien ne se bloque, mais il manque des informations de temps en temps, ..... je n'ai pas la preuve, mais cela fait plusieurs fois que je prends des bases de code différentes et j'obtient toujours les mêmes problèmes si trop de RAM est consommé. pour l'instant je n'ai pas trouvé d'autre solution que de libérer de l'emprunte mémoire pour résoudre le problème.
Si certain veulent d'aventurer dans la recherche du problème, je suis preneur de solutions ;-) pour tester.
Aussi si d'autres peuvent tester cette version pour faire un retour ici, de si ils ont un soucis d'affichage de la page d'accueil dans son intégralité (aucunes datas manquantes).
@André, si tu le souhaites comme tu me l'as demandé, tu peux en faire une version 17.27 telle que j'ai poussé l'ensemble des sources, car je n'ai modifié que:
- Source_EnphaseEnvoy.ino
- Solar_router.ino
https://drive.google.com/drive/folders/1...drive_link
Bonne soirée à tous,
David
Merci à tous.
Salut michy,
Les améliorations que tu proposes pour la mémoire occupée par la gestion du Linky, j'y ai déjà pensé, penses tu ...., c'est une bonne solution.
Pour l'histoire de l'API ArduinoJson, je ne partage pas ton point de vue ..... le travail fait par tsabran mixés au travail que j'avais déjà fait pour optimiser les temps de lecture des datas Enphase ainsi que leur décodage sont bien plus optimiser en utilisant le moins possible la classe String ainsi que les lib Json ..... J'avais fait les mesures de conso de temps, et la gestion des tableaux (qui sont en statique) ainsi que la loop de lecture des data Enphase fonctionne bien mieux sans les String et la librairie AduinoJson.
Ensuite, je pense que tu n'as pas toute la subtilité de ce qu'est une variable statique locale. Elle sera de toutes les façon déclarée et utilisera la mémoire dés le démarrage du programme, même si la fonction qui contient la variable statique locale n'est jamais appelée !! C'est équivalent à une variable globale, mais étant statique elle ne sera accessible que dans la fonction en local. C'est la pile mémoire qui s'en trouve soulagée, rien d'autre !!
Dernier point qui peut-être pourrait t'échapper, le fait que tsabran ait réecrit la fonction de lecture d'un clientWifi, avec une boucle de lecture octet par octet permet de soulager les autres threads de l'application pendant la boucle de lecture par l'appel à la fonction yield() dans la boucle. A moins que la fonction readStringUntil() rende correctement la main aux autres threads, j'ai constaté une nette amélioration de la réactivité de l'application dans les pages Web en ayant intégrer ces modifications de tsabran.
Bref, à suivre. Mais la consommation de RAM semble un point critique à l'heure actuelle dans le code avec toutes les fonctionnalités qu'il contient (Merci André ;-) pour tout ce travail produit qui est énorme !!).
A+
David
J'ai porté les améliorations que j'ai décrite dans un post précédent dans le fichier Source_EnphaseEnvoy.ino.
Cette amélioration qui porte uniquement sur la récupération des données Enphase marche très bien et provique beaucoup moins de reconnexion ou perte de données.
Je partage donc les fichiers sources modifiés ainsi que le binaire (base de v17.26 André + mes modifications).
Je précise que j'ai laissé tout ce qu'il y a dans la version 17.26 sur le site d'André ( donc pas de suppression de la gestion du Linky, ni du Telnet).
En revanche j'ai des problèmes assez fréquents d'affichage de la page d'accueil, rien ne se bloque, mais il manque des informations de temps en temps, ..... je n'ai pas la preuve, mais cela fait plusieurs fois que je prends des bases de code différentes et j'obtient toujours les mêmes problèmes si trop de RAM est consommé. pour l'instant je n'ai pas trouvé d'autre solution que de libérer de l'emprunte mémoire pour résoudre le problème.
Si certain veulent d'aventurer dans la recherche du problème, je suis preneur de solutions ;-) pour tester.
Aussi si d'autres peuvent tester cette version pour faire un retour ici, de si ils ont un soucis d'affichage de la page d'accueil dans son intégralité (aucunes datas manquantes).
@André, si tu le souhaites comme tu me l'as demandé, tu peux en faire une version 17.27 telle que j'ai poussé l'ensemble des sources, car je n'ai modifié que:
- Source_EnphaseEnvoy.ino
- Solar_router.ino
https://drive.google.com/drive/folders/1...drive_link
Bonne soirée à tous,
David
Merci à tous.
(Il y a 2 heures)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
Salut michy,
Les améliorations que tu proposes pour la mémoire occupée par la gestion du Linky, j'y ai déjà pensé, penses tu ...., c'est une bonne solution.
Pour l'histoire de l'API ArduinoJson, je ne partage pas ton point de vue ..... le travail fait par tsabran mixés au travail que j'avais déjà fait pour optimiser les temps de lecture des datas Enphase ainsi que leur décodage sont bien plus optimiser en utilisant le moins possible la classe String ainsi que les lib Json ..... J'avais fait les mesures de conso de temps, et la gestion des tableaux (qui sont en statique) ainsi que la loop de lecture des data Enphase fonctionne bien mieux sans les String et la librairie AduinoJson.
Ensuite, je pense que tu n'as pas toute la subtilité de ce qu'est une variable statique locale. Elle sera de toutes les façon déclarée et utilisera la mémoire dés le démarrage du programme, même si la fonction qui contient la variable statique locale n'est jamais appelée !! C'est équivalent à une variable globale, mais étant statique elle ne sera accessible que dans la fonction en local. C'est la pile mémoire qui s'en trouve soulagée, rien d'autre !!
Dernier point qui peut-être pourrait t'échapper, le fait que tsabran ait réecrit la fonction de lecture d'un clientWifi, avec une boucle de lecture octet par octet permet de soulager les autres threads de l'application pendant la boucle de lecture par l'appel à la fonction yield() dans la boucle. A moins que la fonction readStringUntil() rende correctement la main aux autres threads, j'ai constaté une nette amélioration de la réactivité de l'application dans les pages Web en ayant intégrer ces modifications de tsabran.
Bref, à suivre. Mais la consommation de RAM semble un point critique à l'heure actuelle dans le code avec toutes les fonctionnalités qu'il contient (Merci André ;-) pour tout ce travail produit qui est énorme !!).
A+
David